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 <dick.ha...@gmail.com
<mailto:dick.ha...@gmail.com>> 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 <j...@manicode.com
<mailto:j...@manicode.com>> 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 <dick.ha...@gmail.com
<mailto: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
<mailto: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 <mailto: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
<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 <mailto: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 <mailto: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.png>
Warren Parad
Founder, CTO
Secure your user data and complete your
authorization architecture. Implement Authress
<https://bit.ly/37SSO1p>.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Jim Manico
Manicode Security
https://www.manicode..com <https://www.manicode.com>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
