This document has the following issues: 1. Section 10.11, in connection with phishing attacks, notes that "wide deployment of this and similar protocols may cause end-users to become inured to the practice of being redirected to websites where they are asked to enter their passwords". That begs the question: why should this protocol be proposed as an Internet standard?
2. As observed by John Bradley in http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html if the implicit flow is used for third-party login (as in "Login with Facebook") and if access tokens are bearer tokens, a relying party can obtain an access token from a legitimate user and use it to impersonate the user by presenting it to another relying party. 3. In the authorization code flow, if the client's redirection endpoint is not protected by TLS, a man-in-the-middle attack allows the attacker to capture the authorization code and use it to impersonate the user by presenting it to the client, thus getting access to the protected resources, and to the user's account at the client if OAuth is used for third-party login. Section 3.1.2.1 does not require the use of TLS. On the other hand, section 10.5 requires TLS "if the client relies on the authorization code for its own resource owner authentication", i.e. in the third-party login case. The distinction between the third-party login case and the general case is a spurious one, whose practical result is to let social sites such as Facebook get away with telling client developers to use http rather than https, as Facebook does in its developer documentation at http://developers.facebook.com/docs/authentication/. Client developers will read the Facebook instructions rather than the OAuth specification, and will not even be aware of the need to use TLS, whether or not they are using OAuth for third-party login. 4. In the security considerations section, subsection 10.12 points out a vulnerability in the protocol that allows an attacker to cause a victim to unwittingly log in to the attacker's account instead of the victim's account. The third paragraph provides a countermeasure and requires clients to implement it. But client developers, if they read the security considerations at all, are unlikely to understand the countermeasure, which is barely sketched out. I don't see why the countermeasure is not incorporated into the protocol description to eliminate the vulnerability. 5. Without a secure registration method, the protocol can provide no security. Section 2 does not explain how registration can be made secure. It suggest the use of a self-issued assertion by the client, which of course would provide no security. It also suggests the use of a client description and logo. Even if the client uses a TLS certificate to authenticate during registration, the description and logo are likely to be self-asserted, since I don't know of any CA that certifies descriptions and logos. Then nothing prevents a malicious client from using during registration a valid certificate issued to itself, together with a description and logo of a different client that the malicious client will be able to impersonate. 6. This protocol has adverse privacy implications when used for third-party login, as the identity provider is informed of the user's logins. This is aggravated by the fact that, whereas with OpenID the user can choose an identity provider of her choice, with OAuth the user can only use identity providers that the relying party has preregistered with. Some relying parties only give the choice of signing in with Facebook. 7. The preregistration requirement reinforces the monopoly that Facebook currently has in social networking, since any competitors face the hurdle of convincing relying parties to register with them. 8. The preregistration requirement gives unprecedented power to Facebook over clients, since Facebook can revoke a client's registration at its sole discretion. 9. Indirectly, the preregistration requirement also gives unprecedented power to Facebook over Web users, by making it necessary to have a Facebook account for tasks such as logging in to clients or commenting on blogs. A user's registration, like a client registration, can be revoked by Facebook at any time at Facebook's sole discretion. Without the preregistration requirement, users would be free to log in or comment via OAuth using identity providers of their choice. Francisco
_______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
