Hey Will FYI: I expect this draft to be worked on in httpbis rather than OAuth, so I worry that we are fragmenting the conversation discussing it here -- but here goes!
Thanks for filing an issue on the header name. Early feedback from browser people was that Sec- headers should only be set by the browser -- IE they are only request headers, and not response headers -- so we picked a new prefix. I have no strong opinion myself. I don't understand your point on the transition at scale. I don't expect 100% of clients will change. The AS will only change what it sends if it receives the Redirect headers. If it does, the AS will ONLY send the query as a Redirect-Query header -- it will not send both -- hiding the authorization code from any malicious code that has access to either the URL or the DOM. A user clicking the back button during an OAuth flow is problematic for the protocol as it is, and are not defined as far as I know. For example, the authorization code should only be used once. It is a valid critique of the current draft that back button semantics are not defined. There are a few issues with your suggestion of form_post: 1. As you noted, only SameSite=none cookies are sent 2. The parameters are visible to any malicious code that has access to the DOM as the parameters are in the 3. The default response type for most libraries is query. Some libraries are buggy with form_post. Changing the default of libraries to form_post seems more invasive than having them send Redirect-Query in addition to the URL, and to accept Redirect-Query if present over the URL query. I asked Claude Code what it would take to update the popular node libraries and it concluded it was 10 lines of code. Changing the default to form_post would change how infrastructure is deployed that is expecting GET rather than POST. On Thu, Jan 8, 2026 at 11:43 PM Will Bartlett <[email protected]> wrote: > 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. > > > > 2. 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. > > > > 3. 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]
