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

[Aaron Parecki]

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  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  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  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  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  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 

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

[Dick Hardt]

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  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  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  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  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  wrote:
>>
>>> I haven't 

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

[Jim Manico]

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  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  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  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  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  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 
> 

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

[Dick Hardt]

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  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  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  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 > > 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 

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

[Jim Manico]

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  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  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  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?
 
 
 
 
 
 Warren Parad
 Founder, CTO
 

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

[Warren Parad]

>
> 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  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  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: image.png]
>>
>> Warren Parad
>>
>> Founder, CTO
>> Secure your user data and complete your authorization architecture.
>> Implement Authress .
>>
>> ___
>> OAuth mailing 

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

[Aaron Parecki]

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  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: image.png]
>
> Warren Parad
>
> Founder, CTO
> Secure your user data and complete your authorization architecture.
> Implement Authress .
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Jim Manico]

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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Authorization Code Grant diagram Improvement OAuth 2.1 draft-ietf-oauth-v2-1

[Aaron Parecki]

These numbers in the diagram correspond to the numbered steps in the
paragraphs below the diagram. Perhaps using non-duplicated numbers would
help, such as "1a" and "1b" instead of two instances of "1"? Although I'm
not sure how that would work exactly because the "1/2/3" are really just a
single action as described by the "Note" below the diagram in your
screenshot.

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

On Thu, Jul 30, 2020 at 8:43 AM Warren Parad  wrote:

>
> https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-authorization-code-grant
>
> Can we avoid using (1, 2, 3) on the left side of the diagram to describe,
> I'm not even sure what they are supposed to represent, not to mention the
> RO in the diagram doesn't really provide value (for me) relevant to the
> code grant flow. It's confusing to see these numerical identifiers twice in
> the same picture. But maybe there is something hidden in this that I'm
> missing, still 3a and 3b could be used to identify different legs of the
> same code path.
> [image: image.png]
>
>
> *Warren Parad*
> Secure your user data and complete your authorization architecture.
> Implement Authress .
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

[Warren Parad]

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: image.png]

Warren Parad

Founder, CTO
Secure your user data and complete your authorization architecture.
Implement Authress .
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Authorization Code Grant diagram Improvement OAuth 2.1 draft-ietf-oauth-v2-1

[Warren Parad]

https://www.ietf.org/id/draft-ietf-oauth-v2-1-00.html#name-authorization-code-grant

Can we avoid using (1, 2, 3) on the left side of the diagram to describe,
I'm not even sure what they are supposed to represent, not to mention the
RO in the diagram doesn't really provide value (for me) relevant to the
code grant flow. It's confusing to see these numerical identifiers twice in
the same picture. But maybe there is something hidden in this that I'm
missing, still 3a and 3b could be used to identify different legs of the
same code path.
[image: image.png]


*Warren Parad*
Secure your user data and complete your authorization architecture.
Implement Authress .

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-1-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : The OAuth 2.1 Authorization Framework
Authors : Dick Hardt
  Aaron Parecki
  Torsten Lodderstedt
Filename: draft-ietf-oauth-v2-1-00.txt
Pages   : 85
Date: 2020-07-30

Abstract:
   The OAuth 2.1 authorization framework enables a third-party
   application to obtain limited access to an HTTP service, either on
   behalf of a resource owner by orchestrating an approval interaction
   between the resource owner and the HTTP service, or by allowing the
   third-party application to obtain access on its own behalf.  This
   specification replaces and obsoletes the OAuth 2.0 Authorization
   Framework described in RFC 6749.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

[Sascha Preibisch]

+1

On Thu, 16 Jul 2020 at 23:57, Vladimir Dzhuvinov
 wrote:
>
> +1
>
> Vladimir
>
> On 15/07/2020 20:54, Dick Hardt wrote:
>
> +1
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef  
> wrote:
>>
>> All,
>>
>> This is a call for adoption for the following OAuth 2.1 document as a WG 
>> document:
>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>
>> Please, provide your feedback on the mailing list by July 29th.
>>
>> Regards,
>>  Rifaat & Hannes
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document

[Rifaat Shekh-Yusef]

All,

This concludes our call for adoption for this document.
The WG has decided to adopt this draft as a WG document.


*Authors,*

Feel free to submit a WG version of the document.

Regards,
 Rifaat


On Fri, Jul 17, 2020 at 9:29 AM Nat Sakimura  wrote:

> +1
>
> On Fri, Jul 17, 2020 at 3:57 PM Vladimir Dzhuvinov <
> vladi...@connect2id.com> wrote:
>
>> +1
>>
>> Vladimir
>> On 15/07/2020 20:54, Dick Hardt wrote:
>>
>> +1
>>
>> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef <
>> rifaat.s.i...@gmail.com> wrote:
>>
>>> All,
>>>
>>> This is a *call for adoption* for the following *OAuth 2.1* document as
>>> a WG document:
>>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.html
>>>
>>> Please, provide your feedback on the mailing list by *July 29th.*
>>>
>>> Regards,
>>>  Rifaat & Hannes
>>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: PAR: pushed requests must become JWTs

[Justin Richer]

Aaron,

The “request_uri” comes from OIDC originally, and is redefined in JAR. The 
original idea was to have a URL that the AS/IdP would be able to fetch to get a 
Request Object from, which is why JAR used to have language about “it MUST be 
fetchable and resolve to a JWT” (or something like that). JAR has backed off 
that requirement now (I believe), but those roots are still in the name. RAR 
opts to re-use that mechanism instead of inventing either a new parameter or 
returning a full Redirection URI.

 — Justin

> On Jul 24, 2020, at 3:12 AM, Torsten Lodderstedt 
>  wrote:
> 
> Hi Aaron, 
> 
> that’s a very good point. I was also in favour of just providing the client 
> with the URL it needs to send the user to (like XYZ and OAuth do). 
> 
> In the end, we decided to stay with the current approach since it fits with 
> the rest of the existing ecosystem, namely JAR and authorization endpoint 
> discovery. 
> 
> best regards,
> Torsten. 
> 
>> On 24. Jul 2020, at 00:49, Aaron Parecki  wrote:
>> 
>> I know this is a bit of an old thread to dig up, but as I'm working through 
>> this draft again, something is sticking out to me about this.
>> 
>> In every other instance of "*_uri" in OAuth and extensions, the value is a 
>> URI (usually https) which will be visited by the user's browser or be sent a 
>> POST request from a client. In the case of PAR, this "request_uri" is 
>> actually just an identifier that is *added* to an existing URL, the 
>> authorization endpoint, not a URL that will be visited itself. This 
>> discrepancy is bothering me.
>> 
>> I would have expected that either:
>> 
>> * The PAR response includes a "request_uri" which is the full URL that the 
>> client would redirect the user's browser to, OR
>> * The PAR response includes a "request_id" which it adds in the query string 
>> to the authorization endpoint and then redirects the browser to
>> 
>> For example:
>> 
>> POST /as/par HTTP/1.1
>> ...
>> response:
>> {
>>  "request_uri": 
>> "https://as.example.com/auth?request=bwc4JK-ESC0w8acc191e-Y1LTC2;,
>>  "expires_in": 60
>> }
>> 
>> then the user's browser is sent to whatever the value of "request_uri" is
>> 
>> OR
>> 
>> POST /as/par HTTP/1..1
>> ...
>> response:
>> {
>>  "request_id": 
>> "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
>>  "expires_in": 60
>> }
>> 
>> then the "request_id" is added to the authorization endpoint (as currently 
>> described by PAR)
>> 
>> https://as.example.com/auth?client_id=s6BhdRkqt3_uri=urn%3Aietf%3Aparams%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2
>> 
>> My personal preference is the first option, keeping the term "request_uri" 
>> but having it actually be the full URI, to simplify the job of the client. 
>> In that model, the client doesn't have to mess with building URLs, and 
>> actually provides additional flexibility for the AS as well since that 
>> endpoint no longer needs to be the exact same URL as the authorization 
>> endpoint.. 
>> 
>> ---
>> Aaron Parecki
>> https://aaronparecki.com
>> 
>> 
>> On Thu, Jan 16, 2020 at 8:25 AM Torsten Lodderstedt 
>>  wrote:
>> I just thought about another option. What if we change PAR to not use the 
>> request_uri parameter but a new parameter, e.g. request_id?
>> 
>> That would decouple both specs. The reason why we use request_uri was to 
>> make the life of clients easier since they can use the standard library 
>> function for request objects to pass the PAR reference to the AS. Is this 
>> worth the trouble?
>> 
>>> Am 16.01.2020 um 16:48 schrieb Justin Richer :
>>> 
>>> +1 to this approach, and it sounds like JAR might need to come back to go 
>>> through another round anyway thanks to the breaking changes the IESG pushed 
>>> into it after it left WGLC.
>>> 
>>> I’d rather see us get this right than publish something many of us think is 
>>> broken. 
>>> 
>>> Maybe PAR and JAR (and JARM?) end up going out as a bundle of specs.
>>> 
>>> — Justin
>>> 
 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth