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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
