On 7/13/10 10:25 AM, "John Kemp" <j...@jkemp.net> wrote: > On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote: > >> I am ok replacing it with Oacts as a password¹. > > An access token is something used by the server to decide whether a request is > authorized. Although it may also be used for authenticating the request(er), > it's purpose is to authorize the request.
It is used to authenticate the *request*, it is used in the same manner other HTTP authentication schemes operate, and it has the same behavior as a password (security wise: plain-text storage on the client side, can be phished, usable by any bearer). > 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) OAuth only includes the "bearer token case". There are no other cases specified. > I would be very unhappy if we equated access tokens with passwords. > > I agree with Dirk that "capability" is a more expressive phrase than either > "shared secret" or "password". Expressive to you and people well-versed in security theory. It means nothing to a casual reader. The token definition includes the term, but in this section, it is referring to how an access token is used, and it is used just like a password. For better or worse, we turned the 1.0 access token into a 2.0 password. EHL > Regards, > > - johnk > >> >> EHL >> >> >> On 7/13/10 8:55 AM, "Dirk Balfanz" <balf...@google.com> wrote: >> >> >> >> On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >> From the client's perspective, they are 'shared symmetric secrets' because >> the client has to store them as-is and present them as-is. The act exactly >> like passwords. I added that text to make that stand out. >> >> When using passwords, the server doesn't need to store them in plain-text >> either (e.g. uses a way one hash). >> >> That's why we don't call passwords "shared symmetric secrets", either. The >> verifier of a passwords can verify it without knowing the secret. In that >> sense, it's not "shared" with the verifier. >> >> I would like the specification to make it clear that bearer tokens are only >> secure while they remain *secret* and that *anyone* holding them can gain >> full access to what their protect. >> >> I think the word "capability" expresses that better than the word "shared >> secret". >> >> Dirk. >> >> >> EHL >> >> On 7/12/10 10:39 PM, "Brian Eaton" <bea...@google.com> wrote: >> >>> Section 5: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5 >>> >>> Calling access tokens "shared symmetric secrets" is misleading, >>> because if they are implemented well the authorization server and >>> protected resource do not store a copy of the secret. >>> >>> Instead they store a one-way hash of the token. Or they verify the >>> token cryptographically. Under no circumstances do they need to store >>> a copy. >>> >>> I'd suggest the following language: >>> >>> "Access tokens are bearer authentication tokens or capabilities." >>> >>> Cheers, >>> Brian >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
