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.
+1 > > A bearer token is far less powerful than the user’s password. s/is/should be/ and I agree ;) > 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. Yes, so we need security considerations that encourage "reasonable" implementations. > 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. More will do it if we construct text to encourage them to do so. > > 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 Right, apply the principle of least authority (http://en.wikipedia.org/wiki/Principle_of_least_privilege). The scope of an issued token should be limited to that necessary to complete the requested task. > • Use signatures > • Issue access tokens with a short lifetime, and use the Refresh > workflow These would be fine security considerations for the specification, if they aren't already documented in the security considerations document? Regards, - johnk > > 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
