On Apr 8, 2010, at 4:58 PM, Richard Barnes wrote: > The scope argument doesn't really hold any water, since OAuth isn't defining > the scope that tokens have -- authorization servers could issue tokens that > have the same power as passwords. Not all implementors are "reasonable" :)
Indeed, you can't ever stop people doing stupid things. But the "scope argument" (and expiration time) does certainly hold water. Bearer tokens that have appropriate limitations on usage are well-known to be useful (see one-time use, or time-limited URLs -- for confirming email subscriptions, for example). Such conditions on usage are useful irrespective of whether you believe that tokens should be sent only over SSL/TLS. Regards, - johnk > > --Richard > > > > On Apr 8, 2010, at 2:27 PM, Allen Tom wrote: > >> Using a bearer token without a signature over HTTP is not equivalent to HTTP >> Basic Auth in the clear. >> >> A bearer token is far less powerful than the user’s password. In most >> cases, a MITM who steals the user’s password would be able to change the >> user’s password, locking the user out his account. Passwords are not scoped >> and allow full access to the user’s account. >> >> A bearer token (for all reasonable implementations) would never let the >> holder change the user’s password. Although we have not standardized on the >> concept of scope, presumably, many implementers will issue Access Tokens >> that do not grant access to the entirety of the user’ account. >> >> Another important difference between OAuth2 Access Tokens and HTTP Basic >> Auth is that Access Tokens can have a limited lifetime, so a MITM would only >> be able to hijack an Access Token for a short duration. >> >> My recommendation is that the spec recommend that Service Providers use >> HTTPS for enhanced security, however in the cases where using HTTPS is not >> feasible or desirable, Services Providers should do one or more of the >> following: >> >> • Issue access tokens that are less powerful than the user’s password >> • Use signatures >> • Issue access tokens with a short lifetime, and use the Refresh >> workflow >> >> Allen >> >> >> >> >> On 4/7/10 11:06 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: >> >>> How about something like this: >>> >>> When accessing resources using the http URI scheme, clients SHOULD NOT use >>> and servers SHOULD NOT accept bearer token requests (unsigned requests) as >>> such a request is equal to sending unprotected credentials in the clear. >>> Instead, clients SHOULD obtain and utilize an access token with a matching >>> secret by sending a signed request. Servers MUST accept signed requests for >>> protected resources using the http URI scheme. >>> >>> EHL >>> >>> >>> >>> >>> On 4/7/10 6:42 PM, "Richard Barnes" <rbar...@bbn.com> wrote: >>> >>>> You guys are both right: The recommendation I made before is basically >>>> saying that you SHOULD only use tokens without signing on HTTPS >>>> resources. >>>> >>>> --Richard >>>> >>>> >>>> On Apr 7, 2010, at 9:24 PM, Dick Hardt wrote: >>>> >>>>> Eran >>>>> >>>>> Richard and Lief are describing the same point we had in the past >>>>> where Peter surmised the discussion that an *implementation* MUST >>>>> support TLS is required for bearer tokens to be compliant, and that >>>>> TLS is recommended for *deployment* >>>>> >>>>> -- Dick >>>>> >>>>> On 2010-04-07, at 4:21 PM, Eran Hammer-Lahav wrote: >>>>> >>>>>> We are looking at this all wrong. >>>>>> >>>>>> There are two kinds of protected resources OAuth supports: >>>>>> >>>>>> * http:// >>>>>> * https:// >>>>>> >>>>>> OAuth provides two kinds of token authentication modes: >>>>>> >>>>>> * bearer token >>>>>> * token + signature >>>>>> >>>>>> I don't know how to translate your statement below into text I can >>>>>> put in >>>>>> the draft to answer: >>>>>> >>>>>> When you access/serve an http:// protected resource you do what? >>>>>> When you access/serve an https:// protected resource you do what? >>>>>> >>>>>> It is not about requiring SSL for bearer token. It is about what you >>>>>> can/should do when accessing an http:// resource. >>>>>> >>>>>> EHL >>>>>> >>>>>> On 4/7/10 7:09 AM, "Richard Barnes" <rbar...@bbn.com> wrote: >>>>>> >>>>>>> To re-iterate and clarify Leif's second point, I would be in favor >>>>>>> of >>>>>>> making TLS: >>>>>>> >>>>>>> -- REQUIRED for implementations to support (== MUST) >>>>>>> -- RECOMMENDED for deployments to use (== SHOULD) >>>>>>> >>>>>>> This a pretty universal pattern in IETF protocols. >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> On Apr 7, 2010, at 7:20 AM, Leif Johansson wrote: >>>>>>> >>>>>>>> >>>>>>>>> Go implement whatever you want. But the spec should set the >>>>>>>>> highest >>>>>>>>> practical bar it can, and requiring HTTPS is trivial. >>>>>>>>> >>>>>>>>> As a practical note, if the WG reaches consensus to drop the MUST, >>>>>>>>> I would >>>>>>>>> ask the chairs to ask the security area and IESG to provide >>>>>>>>> guidance whether >>>>>>>>> they would approve such document. The IESG did not approve OAuth >>>>>>>>> 1.0a for >>>>>>>>> publication as an RFC until this was changed to a MUST (for >>>>>>>>> PLAINTEXT) among >>>>>>>>> other comments, and that with a strong warning. >>>>>>>>> >>>>>>>>> There is also an on going effort to improve cookie security. Do we >>>>>>>>> really >>>>>>>>> want OAuth to become the next weakest link? >>>>>>>> >>>>>>>> I emphatically agree. >>>>>>>> >>>>>>>> I suspect that a lot of confusion on this thread is caused by >>>>>>>> confusing implementation requirements with deployment requirements >>>>>>>> btw. >>>>>>>> >>>>>>>> Cheers Leif >>>>>>>> _______________________________________________ >>>>>>>> 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 > > _______________________________________________ > 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
