On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote: > On 13 July 2010 20:31, John Kemp <j...@jkemp.net> wrote: >> Where is that specified? Is that required for all implementations? > > It's not specified - I was referring to your earlier comments: > >> In the "bearer token" case (and even over SSL unless client certs are used), >> the >> token clearly SHOULD NOT be used as a password. Rather, authentication should >> be performed by some other mechanism, unrelated to the token itself (such as >> an >> HMAC, or via client-certificate SSL/TLS, or even via an actual >> username/password) > >> I would be very unhappy if we equated access tokens with passwords. > > The token is never used as the authentication mechanism (i.e., the > mechanism to authenticate the user), except in schemes where it > explicitly makes sense (e.g., UMA as I understand it, Twitter's OAuth > Echo, etc). So there's no concern about that. > > What I was trying to say, and I'm just re-iterating Eran's comments > here, is that once issued [in the context of a request made by an > authenticated user that grants authorization to the OAuth client], the > token will be used de-facto as a password, passphrase, shared secret, > or whatever we want to call it. By calling it a "capability", we don't > signal to implementors what the security implications are, and what > they can do to avoid disappointment.
By using the word "password" to apply to the token itself you are suggesting that the token is the authenticator for the request, which may or may not be true. And you are tying in to a rich history of what a "password" means, which is not necessarily how the token will be used, particularly if some other means of authenticating the requester is used _in addition to_ the bearer token being used to authorize the request. > >> A capability, basically, is a reference to an object and the permission to >> use it, bound together. Possession of the capability is enough to authorize >> the use of the reference. Bearer tokens follow roughly that model. They are >> about authorization and MAY be used alone for authentication, but may also >> be used with (specified, or not, in OAuth) other mechanisms for >> authentication. At least I hope that is the model (not to *require* servers >> to authenticate using the bearer token alone even if *some* implementations >> do that)? > > It's unclear what you mean is being authenticated by the server – do > you mean the user, or the client, or something else? Which thing do you think the bearer token is a password for? I think the bearer token is used by the server to authorize access by the requester. It MAY be used as an authenticator for the requester.... but it may not (or not alone) > This question is > persistent and points to exactly the kind of confusion I think Eran is > correct to try to avoid by simply calling the token password-like. "Password-like", in some circumstances, but not a password. In OAuth, as I understand it, the token is used to authorize the request. Authenticating the request is then out of scope for OAuth proper, but various authentication methods for the client may be used in conjunction with the use of the token, including allowing the token to act as a "password" for the client. > If > we use language that clearly indicates to developers that "with the > clear-text token, requests can be made [modulo reduced permissions] as > though they were made by someone in possession of the user's username > and password. Don't leak it, and treat it as though it were a > password", then we avoid having to explain (embarrassingly) that the > "capability" actually meant something like "password". You see the bearer token as being a password for the user? Or should it simply be protected in the same ways that one would protect a user's password -- in other words, document the security considerations of tokens in detail (stored securely, not passed in cleartext etc.) rather than using a single word to indicate something which may or may not be accurate, and is certainly not wholly descriptive. - johnk _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
