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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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