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 protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected] >> <[email protected]>> 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 [email protected]https://www.ietf.org/mailman/listinfo/oauth >>> >>> -- >>> Jim Manico >>> Manicode Securityhttps://www.manicode.com >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
