I think this would be very helpful in addressing some of the security considerations that have been part of recent discussions on this list. It's a long-term play, but the way this is written allows incremental adoption by all parties.
Aaron On Fri, Dec 12, 2025 at 4:45 AM Dick Hardt <[email protected]> wrote: > 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
