The bearer token protocol described in the document referenced in the
subject line is vulnerable to the following attack by a malicious
resource server.

There are two resource servers S1 and S2, S1 hosting a resource R1,
and S2 hosting a resource R2.  Servers are not entitled to access
resources that they do not host.  S1 is malicious.  The client obtains
a broadly scoped access token that allows access to both resources.
The client uses the access token to obtain resource R1 from server S1.
Malicious server S1 then presents the access token received from the
client to server S2 and gains access to resource R2, which it is not
entitled to access.

Including the identity of the intended recipients in the token, as
recommended in Section 4.2, does not help, since the intended
recipients of the broadly scoped token include both R1 and R2.

Francisco

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