> > 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 <aa...@parecki.com> 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 <j...@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: image.png] >> >> Warren Parad >> >> Founder, CTO >> Secure your user data and complete your authorization architecture. >> Implement Authress <https://bit.ly/37SSO1p>. >> >> _______________________________________________ >> 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
