I don’t know what’s behind OAuth 2.1’s guidance of only defining two acceptable transfer mechanisms, but allowing cookies in the way described here seem to be fine. They do however need the AS and API on the same domain to be effective.
FYI, the browser-based apps spec has a section on secure cookie configurations for the BFF: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps.html#name-cookie-security Philippe — Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com > On 22 Sep 2025, at 19:41, Dan Moore <dan=40fusionauth...@dmarc.ietf.org> > wrote: > > Hi folks, > > Was reviewing the OAuth 2.1 draft and saw a few notes about storing bearer > tokens in cookies. In fact, the guidance is a bit confusing. Section 5.1 ( > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#name-bearer-token-requests > ) says that sending the bearer token in the authorization header or as a > part of the form body are the only ways that are acceptable. > > If you take proper care of CSRF protections (which, granted, is a big if) and > if they are stored as HTTPOnly and Secure, cookies as bearer tokens are a > good option for first party APIs in browser based apps. Since cookies are > just another header, they share some of the characteristics of the > authorization header approach. > > The draft has two sections that discuss cookies: > > - > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-7.1.1.2 > - > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-7.1.3.4 > > Section 7.1.1.2 says: > > > Since cookies are by default transmitted in cleartext, any information > > contained in them is at risk of disclosure: Bearer tokens MUST NOT be > > stored in cookies that can be sent in the clear. See Section 7 and 8 of > > [RFC6265 > > <https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#RFC6265>] > > for security considerations about cookies. > > I looked at RFC 6265 and saw this section which seems to be relevant: > https://www.rfc-editor.org/rfc/rfc6265.html#section-8.3 which really focuses > on the danger of cookies being sent in clear text (over HTTP, not HTTPS/TLS). > There are other sections which discuss downsides of cookies, but not w/r/t > them being transmitted in cleartext. But section 7.1.3.3 ( > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-7.1.3.3 > ) says to always use TLS, which seems to remove the worries about cookies > being sent in cleartext. > > Section 7.1.3.4 says: > > > Implementations that do store bearer tokens in cookies MUST take > > precautions against cross-site request forgery. > > which contradicts section 5.1 mentioned above, because it implies that you > can store bearer tokens in cookies and still be in compliance with the draft. > > Would a modification to > https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#name-bearer-token-requests > adding cookies as an acceptable bearer token transmission mechanism > (including the limitations mentioned above) be accepted? > > (I did a quick search on the mailing list archive and didn't see any relevant > discussion.) > > Thanks, > Dan > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
