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 <dick.ha...@gmail.com> 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 <j...@manicode.com> 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 <wpa...@rhosys.ch> 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 <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 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 >> _______________________________________________ >> 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
