Re: [OAUTH-WG] Clarifying Bearer token usage OAuth 2.1 draft-ietf-oauth-v2-1-00

[Jim Manico <[e-mail]>]

I politely encourage the rules to be bent and to integrate this basic but fundamental security control into the core standard.

This is just basic security; we want as much basic security in the core of any standard. Dev’s now need to read 20 standards to get OAuth2 basics... and that’s a barrier to entry.

--
Jim Manico
@Manicode

> On Jul 30, 2020, at 3:21 PM, Dick Hardt <[e-mail]> wrote:
> 
> 
> One of the constraints of the OAuth 2.1 document that aligned the WG was it would have no new features.
> 
> I'd recommend a separate document for the cookie bearer token feature. 
> 
> ᐧ
> 
>> On Thu, Jul 30, 2020 at 12:15 PM Jim Manico <[e-mail]> wrote:
>> Yea to cookie configuration suggestions!
>> 
>> I suggest SameSite=LAX at least, which is actually the default behavior in chrome if you do not set the samesite value. LAX will not break links that originate from emails, STRICT will.
>> 
>> Point being is that CSRF defense is easy. XSS defense is brutally hard in apps with complex UI’s!
>> 
>> --
>> Jim Manico
>> @Manicode
>> 
>> 
>>>> On Jul 30, 2020, at 1:13 PM, Warren Parad <[e-mail]> wrote:
>>>> 
>>> 
>>>> Cookie storage of tokens does leave one open to CSRF attacks so it's certainly a trade-off. But CSRF is much easier to defense against that XSS and cookies are a better choice if the specific risk of having tokens stolen via XSS matters to your threat model.
>>> 
>>> I would assume if we included cookie language, it would explicitly specify Secure; HttpOnly; SameSite=Strict as the recommendation, and then neither XSS nor CSRF should be a problem (right?)
>>> 
>>> 
>>>> OAuth 2.1 isn't supposed to add new features that don't already exist, but this sounds like a good candidate to develop as an OAuth extension.
>>> 
>>> Is this really a new feature though?
>>> 
>>> Okay, I'll submit that RFC 6749 does state the cookie wouldn't be created by the AS.
>>>> 5.1.  Successful Response
>>>>    The authorization server issues an access token and optional refresh
>>>>    token, and constructs the response by adding the following parameters
>>>>    to the entity-body of the HTTP response with a 200 (OK) status code:
>>>  
>>> However that wouldn't prevent a client using the password grant (I know I said a bad word) or authorization code flow from creating the cookie to contain that. Specifically
>>>> 7.  Accessing Protected Resources
>>>>    The client accesses protected resources by presenting the access
>>>>    token to the resource server.  The resource server MUST validate the
>>>>    access token and ensure that it has not expired and that its scope
>>>>    covers the requested resource.  The methods used by the resource
>>>>    server to validate the access token (as well as any error responses)
>>>>    are beyond the scope of this specification but generally involve an
>>>>    interaction or coordination between the resource server and the
>>>>    authorization server.
>>>>    The method in which the client utilizes the access token to
>>>>    authenticate with the resource server depends on the type of access
>>>>    token issued by the authorization server.  Typically, it involves
>>>>    using the HTTP "Authorization" request header field [RFC2617] with an
>>>>    authentication scheme defined by the specification of the access
>>>>    token type used, such as [RFC6750].
>>> 
>>> So that's definitely some gray area. Although perhaps I'm missing a relevant section. If we are going to go so far to detail a list of possible RS bearer token possible locations (i.e. Header and Body), to what I assume is to implicitly say Don't use a query parameter. It also suggests Don't use a cookie at all, even with SameSite=Strict. Although maybe that is the point.
>>> 
>>> For my reference, what makes a new feature and what makes an OAuth extension?
>>> 
>>> 
>>> Warren Parad
>>> Founder, CTO
>>> Secure your user data and complete your authorization architecture. Implement Authress.
>>> 
>>> 
>>>> On Thu, Jul 30, 2020 at 6:46 PM Aaron Parecki <[e-mail]> wrote:
>>>> I haven't seen any OAuth drafts that talk about sending OAuth access tokens in HTTP cookies. OAuth 2.1 isn't supposed to add new features that don't already exist, but this sounds like a good candidate to develop as an OAuth extension.
>>>> 
>>>> ---
>>>> Aaron Parecki
>>>> https://aaronparecki.com
>>>> https://oauth2simplified.com 
>>>> 
>>>>> On Thu, Jul 30, 2020 at 9:35 AM Jim Manico <[e-mail]> wrote:
>>>>> In a browser, HTTPOnly cookies are the only location where an access (or other) token can be stored in a way where it cannot be stolen from XSS.
>>>>> 
>>>>> It's a very strong place to store tokens from a security point of view.
>>>>> 
>>>>> Cookie storage of tokens does leave one open to CSRF attacks so it's certainly a trade-off. But CSRF is much easier to defense against that XSS and cookies are a better choice if the specific risk of having tokens stolen via XSS matters to your threat model.
>>>>> 
>>>>> - Jim
>>>>> 
>>>>> On 7/30/20 11:43 AM, Warren Parad wrote:
>>>>>> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-bearer-tokens
>>>>>> 
>>>>>> It seems recently more and more common to pass the access_token to some RS via a cookie, yet 7.2.1 says it defines two methods. I think we need some RFC2119 keywords here, to suggest that either SHOULD use one of these two, or MUST. And then optionally state whether or not we recommend or reject the use of cookies as a place for access tokens. It's also possible that the language threw me off, because would an access token in a cookie be a bearer token, but no matter, if I'm having this thought, then surely others have it as well, right?
>>>>>> 
>>>>>> <image.png>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Warren Parad
>>>>>> Founder, CTO
>>>>>> Secure your user data and complete your authorization architecture. Implement Authress.
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> -- 
>>>>> Jim Manico
>>>>> Manicode Security
>>>>> https://www.manicode.com
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth