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

[Dick Hardt <[e-mail]>]

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