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