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: 1. Issue access tokens that are less powerful than the user¹s password 2. Use signatures 3. 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
