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

From: Warren Parad <[email-masked]>
Date: Thu, 30 Jul 2020 17:43:51 +0200

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?

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress <https://bit.ly/37SSO1p>.

---

From: Jim Manico <[email-masked]>
Date: Thu, 30 Jul 2020 12:34:14 -0400

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

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 30 Jul 2020 09:46:35 -0700

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 <[email-masked]> wrote:

> 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
> RFC2119 <https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html#RFC2119> keywords
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>

---

From: Warren Parad <[email-masked]>
Date: Thu, 30 Jul 2020 19:13:16 +0200

> 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

On Thu, Jul 30, 2020 at 6:46 PM Aaron Parecki <[email-masked]> 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
>> 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

---

From: Jim Manico <[email-masked]>
Date: Thu, 30 Jul 2020 15:15:20 -0400

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 <[email-masked]> 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
>>    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.
>>    token issued by the authorization server.  Typically, it involves
>>    using the HTTP "Authorization" request header field [RFC2617] with an
> 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.
> 
> 
>> 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
>>> 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.
>>> 
>>> 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
>>> 
>>>> 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?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Warren Parad
>>>> Founder, CTO
>>>> Secure your user data and complete your authorization architecture. Implement Authress.
>>>> 
>>>>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jul 2020 12:20:58 -0700

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 <[email-masked]> wrote:

> 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.
>
> 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?)
>
>
>> <https://tools.ietf.org/html/rfc6749#section-5.1>   token, and
>> constructs the response by
>> On Thu, Jul 30, 2020 at 9:35 AM Jim Manico <[email-masked]
>> <jim@manicode..com>> wrote:
>>

---

From: Jim Manico <[email-masked]>
Date: Thu, 30 Jul 2020 16:47:52 -0400

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 <[email-masked]> wrote:
> 
> 
> One of the constraints of the OAuth 2.1 document that aligned the WG was it would have no new features.
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 30 Jul 2020 13:54:47 -0700

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 <[email-masked]> 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
>
>> 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.
>>
>> 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.
>>
>>
>> use a cookie at all*, even with* SameSite=Strict*. Although maybe that
>> is the point.
>>
>>>> (or other) token can be stored in a way where it *cannot be stolen
>>>> from XSS*.
>>>>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 30 Jul 2020 14:16:46 -0700

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

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

>> 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
>>
>>>> <https://tools.ietf.org/html/rfc6749#section-5.1>*   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
>>>> * Typically, it involves   using the HTTP "Authorization" request
>>>> header* field [RFC2617] with an
>>>>> 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*.
>>>>>
>>>>> some RS via a cookie, yet 7.2.1 says it defines two methods. I think we
>>>>> need some RFC2119
>>>>> Manicode Securityhttps://www.manicode..com <https://www.manicode.com>
>>>>>

---

From: Jim Manico <[email-masked]>
Date: Thu, 30 Jul 2020 18:09:38 -0400

Two thumbs up!

I would rather delay and get it right. Good things come to those who wait.

But; I am the least experienced standard author or advisor. I am an 
idealist and am ok stating my opinion and moving on so others with more 
experience in this area can make the decisions.

Aloha.

- Jim Manico

On 7/30/20 5:16 PM, Aaron Parecki wrote:
> 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?
>
> This looks like a good starting point and I am happy to work with 
> Jared on refining this.
>
> ---
> Aaron Parecki
> https://aaronparecki.com
> On Thu, Jul 30, 2020 at 1:55 PM Dick Hardt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     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?
>
>     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 <[email-masked]
>     <mailto:[email-masked]>> 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 <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>         
>>         One of the constraints of the OAuth 2.1 document that aligned
>>         the WG was it would have no new features.
>>
>>         On Thu, Jul 30, 2020 at 12:15 PM Jim Manico <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             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.
>>
>>>             On Jul 30, 2020, at 1:13 PM, Warren Parad
>>>             <[email-masked] <mailto:[email-masked]>> 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
>>>             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?
>>>
>>>                 <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:
>>>             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
>>>                    covers the requested resource. *The methods used
>>>                 by the resource
>>>                    authorization server*.
>>>                 * Typically, it involves
>>>                    using the HTTP "Authorization" request header*
>>>                 field [RFC2617] with an
>>>             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
>>>             <[email-masked] <mailto:[email-masked]>> 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
>>>                 On Thu, Jul 30, 2020 at 9:35 AM Jim Manico
>>>                 <[email-masked] <mailto: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*.
>>>
>>>                     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
>>>
>>>>                     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
>>>>                     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?
>>>>
>>>>
>>>>
>>>>                     	
>>>>
>>>>                     Warren Parad
>>>>
>>>>                     Founder, CTO
>>>>
>>>>                     Secure your user data and complete your
>>>>                     authorization architecture. Implement Authress
>>>>                     <https://bit.ly/37SSO1p>.
>>>>
>>>>                     [email-masked]  <mailto:[email-masked]>
>>>                     https://www.manicode..com  <https://www.manicode.com>
>>>
>>>                     [email-masked] <mailto:[email-masked]>
>>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
-- 
Jim Manico
Manicode Security
https://www.manicode.com