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

[Aaron Parecki <[e-mail]>]

I have a draft from a coworker that defines a cookie response mode and
cookie bearer token usage. It's something we've considered bringing to the
working group but haven't actually proposed yet. Is this the kind of thing
you're talking about?

https://github.com/jaredhanson/draft-oauth-cookie-response-mode/blob/master/spec.txt

This looks like a good starting point and I am happy to work with Jared on
refining this.

---
Aaron Parecki
https://aaronparecki.com
https://oauth2simplified.com

On Thu, Jul 30, 2020 at 1:55 PM Dick Hardt <[e-mail]> wrote:

> I hear you Jim, but it is not so much rules, as expectations and
> expediency.
>
> There may be significant debate on how to do the feature. You would not
> want to hold up the OAuth 2.1 document for that would you? There are other
> documents already in flight -- which other ones should OAuth 2.1 wait for?
>
> Reducing the "20 standards" to one document was the goal of OAuth 2.1.
>
> Having said that, if members of the working group want to get working on
> this feature, and if it is completed quickly, it could be referenced or
> included in OAuth 2.1 depending on the relative timing.
>
> /Dick
>
>
>
>
> ᐧ
>
> On Thu, Jul 30, 2020 at 1:47 PM Jim Manico <[e-mail]> wrote:
>
>> 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
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>   The authorization
>>>> server issues an access token and optional refresh
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>   token, and
>>>> constructs the response by
>>>> *adding the following parameters*
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>*   to the
>>>> entity-body of the HTTP response* with a 200 (OK) status code:
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>
>>>
>>>
>>> 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 <https://bit.ly/37SSO1p>.
>>>
>>>
>>> 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]
>>>> <jim@manicode..com>> 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
>>>>> <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#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 <https://bit.ly/37SSO1p>.
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> --
>>>>> Jim Manico
>>>>> Manicode Securityhttps://www.manicode..com <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
>>>
>> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>