Hi all, The OAuth spec recommends the use of TLS when sending requests to the end-user authorization endpoint and requires it when sending requests to the token endpoint. It says nothing about using TLS when redirecting the browser back to the client, which implies that it is not needed for that purpose.
In fact, TLS is needed just as much when redirecting back to the client as when sending requests to the token endpoint. If TLS is not used when redirecting back, the following attack, which is easy to implement, allows the attacker to impersonate a resource owner and gain access to protected resources. The resource owner goes to an airport or a coffee house with a laptop. The attacker is sitting at the airport or coffee house with a loptop that implements a rogue Wifi access point. (Using a laptop as a rogue access point has always been easy to do, and it may have become easier with the soft access point feature of Windows 7.) The resource owner connects to the Internet through the rogue access point. The attacker can observe all traffic that is not encrypted by TLS. The resource owner tries to use a client application to access a protected resource. The client application, which implements the web server client profile, has registered with an authorization server, and has been issued a client identifier and client password credentials by the authorization server. The resource owner accesses the client application. The client application redirects the resource owner to the authorization server. The authorization server authenticates the resource owner and redirects the resource owner's browser to the redirection URI of the client application. The scheme of the redirection URI is http rather than https. The redirected request conveys the authorization code to the client application. The client application uses the authorization code and its client password credentials to obtain an access token from the authorization server. When it obtains the access token, the client application logs in the resource owner (as applications typically do) creating a session record where it stores the access token, so that it can use it later to access protected resources as requested by the resource owner. The client application sets an authentication cookie in the resource owner's browser (as applications typically do) which refers to the session record and is used to authenticate subsequent requests to the client application from the resource owner. The authentication cookie is set by the http response to the request that conveyed the authorization code to the client application. That request was sent to the redirection URI, and was not encrypted by TLS. Therefore the attacker can observe the authentication cookie. As soon as the attacker observes the cookie, it terminates the wireless connection of the resource owner, and starts using the cookie to impersonate the resource owner. The attacker uses the cookie to make requests to the application for protected resources, and the application accesses those protected resources using the access token stored in the browser record referenced by the cookie. There is a variation of the attack that uses DNS spoofing. DNS spoofing is easy to set up on a laptop that implements a rogue access point. The attacker spoofs the DNS vis-a-vis the resource-owner's laptop, mapping the domain name of the client application to the LAN-side IP address of the rogue address point. The attacker's laptop then proxies the connection from the resource owner's laptop to the client, which is possible because the connection is not protected by TLS. The attacker has thus easy access to the authentication cookie. Besides OAuth, the attack works against OpenID, which fails to recommend the use of TLS for the redirection from the OpenID Provider back to the Relying party. The attack also affected my own little PKAuth protocol (discussed in the unregistered applications thread), which also uses a double redirection mechanism. PKAuth uses TLS throughout, but I was implicitly making the claim that it provided protection even if the user ignored an invalid-certificate warning from the browser. I've now removed that claim. Francisco
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
