In my opinion the protocol has serious problems. The authorization code is a credential that provides access to protected resources via the client, as well as user authentication when OAuth is used for social login. If an attacker observes or intercepts the authorization code, the attacker can present the code to the client, use the client to gain access to the user's protected resources, and log in to the client impersonating the user. Therefore the authorization code cannot be sent to the client without TLS protection. The protocol must require the redirect_uri to use the https scheme. The redirect_uri is shown as an https URI in the examples, but examples are not enough. If TLS is not required, implementations may use http. At this time the Facebook developer documentation shows http rather than https in its examples, and implementations seem to use http, as can be seen by searching the Web for "oauth redirect_uri".
The protocol has the same well-known vulnerability to phishing attacks as OpenID. The attack on OpenID described by Ben Laurie in http://www.links.org/?p=187 is equally applicable to this protocol. The protocol should require the use of TLS at the authorization endpoint; without it, the user is defenseless against the attack. The protocol should also require the user to be already logged in at the authorization server, so that the server will not ask for credentials. If implementors take no precautions, the protocol is vulnerable to Login CSRF attacks. Adam Barth confirmed this in a message to the IETF websec mailing list: > Last time I looked into Login CSRF issues with > OAuth, the protocol had a large problem and every implementation I > experimented with was trivially vulnerable. A countermeasure against Login CSRF must be provided in the security considerations section. The security considerations section should also suggest countermeasures against DOS attacks. But the section is not written yet. I would think that the absence of a security considerations section in and of itself means that the protocol is not ready. I also must point out the danger to the Web posed by a protocol that is used for social login and requires registration. Millions of Web applications already use Facebook for social login. If social login becomes a de facto standard for user authentication, Web applications will have to support login with Facebook just to be able to authenticate their users. If that requires registration, then Facebook will have the power to disable any Web application by revoking its registration. That would be bad for all parties involved, including Facebook, which would then face regulation by the governments of many countries. Francisco --- On Wed, 3/2/11, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: From: Hannes Tschofenig <hannes.tschofe...@gmx.net> Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt To: "OAuth WG" <oauth@ietf.org> Date: Wednesday, March 2, 2011, 7:32 AM This is a Last Call for comments on http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt Please have your comments in no later than March 16. Do remember to send a note in if you have read the document and have no other comments other than "its ready to go" - we need those as much as we need "I found a problem". Thanks! Hannes & Blaine _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
