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

[Jim Manico <[e-mail]>]

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:
> 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] 
> <mailto:[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]
>     <mailto:[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]
>>         <mailto:[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]
>>         <mailto:[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] <mailto:[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] <mailto:[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] <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*.
>>>
>>>                     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 list
>>>>                     [e-mail]  <mailto:[e-mail]>
>>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>                     -- 
>>>                     Jim Manico
>>>                     Manicode Security
>>>                     https://www.manicode..com  <https://www.manicode.com>
>>>
>>>                     _______________________________________________
>>>                     OAuth mailing list
>>>                     [e-mail] <mailto:[e-mail]>
>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>             _______________________________________________
>>             OAuth mailing list
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
-- 
Jim Manico
Manicode Security
https://www.manicode.com