Re: [OAUTH-WG] HTTPS requirement for using an Access Token without signatures

Thu, 08 Apr 2010 13:58:58 -0700

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" :) 

--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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/oauth
>




_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth


_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to