Re: [OAUTH-WG] "shared symmetric secret"

[Eran Hammer-Lahav <[e-mail]>]

This is how OAuth works: The client wants to access a protected resource. The resource requires authentication (that's the definition of protected). The client presents the access token to authenticate (using an HTTP authentication header). The access token has all the security characteristics of a password:

- Opaque to the client - just a string
- Client must store it in a way that provides access to the clear-text token
- Anyone holding the token can access - the bearer of the token is considered its rightful owner
- The token can be leaked or phished - which is sufficient for full access

I don't care much about the philosophical debate (authentication vs authorization) as I don't think it adds much value here. When it comes to using an access token, the client uses it just like a password, it serves as the authentication construct, and it has all the same problems passwords have.

I do recognize that unlike users' passwords, the tokens are not bound to a person's memory and therefore can be longer, short-lived, and client-specific which is an improvement over users' passwords. But that's just an implementation detail. There is little in the protocol today that enforces this.

My assumption is that for the most part, OAuth 2.0 will be used without any additional authentication. For example, my employer (whom I do not represents here in any way) intends to use access tokens over plain HTTP without SSL/TLS (current BBAuth deployment).

As soon as we add discovery, bearer token phishing will become an issue - mark my words. This is why I find bearer tokens so offensive (I consider discovery a required feature) - but I have lost that battle. All I can do now is use my editorial capacity to warn readers of what they are dealing with *in practice*, and in practice, bearer tokens are used just like passwords.

--

Either way, this is the new text:

        Clients access protected resources by presenting an access token to the resource server.
        Access tokens are bearer authentication tokens, such as passwords or capabilities (as
        defined by RFC2828). This requires treating the access token with the
        same care as other passwords. Access tokens SHOULD NOT be sent in the clear over an
        insecure channel.


EHL