The confusion may be that at least some of the quoted guidance is around using cookies as local storage for state including the access token, rather than for conveying parameters between a client and protected resource eg for API usage. OAuth 2.1 section 7.1.1.2 may be a typo and means to say access tokens in that context, rather than bearer tokens. There is the CSRF caveat for sure - headers and parameter inclusion is an explicit action, while a client would not necessarily have visibility or control over when and where such a token was sent in a cookie. I would suggest that such cookie usage would be fine if leveraging DPoP as that would indicate client intent, but you would need an explicit way of conveying the access token hash to the client since it would not have visibility to the token itself. -DW
|
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
