Hey Dick, Sam, A few comments:
1. To introduce headers that are only set by the browser in a way that's compatible with Fetch, they need to be Sec- or Proxy- prefixed. I filed Use of unsafe/unsecure headers (under Fetch) · Issue #2 · dickhardt/redirect-headers<https://github.com/dickhardt/redirect-headers/issues/2> for this. 1. Imho, the transition mechanism is not really useable at scale. Sending responses both ways (query+header) invalidates most of the security benefits. But big OAuth providers (such as Entra, where I work) will never get 100% of clients to upgrade. So, it would need to be client metadata, which then requires coordination, not just simple library upgrades. 1. The back button semantics are (imho) unclear. The spec says, for example, that moving the client parameters to headers "provides consistency and reduces URL clutter" - implying that moving these parameters to headers is desirable. However, most users expect the back button to work in browser, including going back to an authentication request. Then... won't browser just start including these headers in the browser history data structure? If so, it does not mitigate the "browser history leakage" threat. I guess my overall reaction is that I don't understand the benefits compared to just using response_mode=form_post. Form posts provide a reliable Origin header (as long as you don't care about pre-Chromium Edge) and already have well defined behavior around history. It seems like the goal here is at least partially around threading a needle with SameSite=Lax - there's a sentiment that auth cookies should be SameSite=Lax, but auth responses should include auth cookies to permit session continuity, thus GET is required. But - in some sense, that doesn't go far enough - login should also be CSRF-protected, and that CSRF protection should take the form of a SameSite=Strict cookie, like all CSRF protection cookies. I wonder if it makes more sense to tackle it from the other end. That is, instead of saying that the login response must be GET to include cookies, and we want to secure the login response, say that the login response must be POST to be secure, and we need to find a mechanism to include cookies. E.g. maybe a cookie attribute, Set-Cookie: __Host-AuthState=FooBar; SameSite=Strict; CrossOriginList=sts.example, that says that the SameSite cookie will be included in cross-origin requests if the initiating origin is one of the origins that appears on an allow list. Such a framing would also mitigate the mix-up attack, because the CSRF cookie would only be present if the response was coming from the expected origin. Or maybe a response header - Sec-Relax-Same-Site-Rules-For-Origins: sts.example. Thanks, Will ________________________________ From: Dick Hardt <[email protected]> Sent: Friday, December 12, 2025 4:43 AM To: [email protected] <[email protected]> Subject: [EXTERNAL] [OAUTH-WG] Redirect Headers - browser mediated passing of protocol parameters Hey Authentication and authorization protocols (OAuth, OpenID Connect, SAML) use browser redirects to navigate users between applications and authorization servers. These redirects must carry protocol parameters, which historically appear in URLs or POSTed forms. Problem: URLs leak sensitive data through browser history, Referer headers, server logs, analytics, and JavaScript access. Solution: Redirect Headers move parameters into browser-controlled HTTP headers that aren't exposed in URLs or the DOM. Rollout: Redirect Headers support can be independently adopted by client, browser, and AS. When all three have adopted, the authorization response, in particular the `code` parameter, will be passed only in the HTTP header and will not be visible to the page DOM / JS. Here is an explainer: https://github.com/dickhardt/redirect-headers I'm posting this to the OAuth WG as this is the area to confirm this mechanism is of interest. If it is, then I will propose doing the work in the httpapi WG. Sam Goto has expressed interest in adding this functionality to Chrome. I expect there will be bike-shedding on the header names and values -- so that aside, what do people think?
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
