Hi Dick, It looks to me like this is breaking the HTTP semantics by somehow splitting the resource identification between the request target and the Redirect-Query request header. The processing of the Redirect-Query content is not safe/idempotent, so one cannot really say that it's OK to treat the redirect URI (request target) alone as the resource; so effectively this means that the resource is target+Redirect-Query.
That "modified GET" request also looks quite a lot like the proposed QUERY method ( https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-safe-method-w-body-14), BUT that method requires that the processing is safe/idempotent, so in effect this is really more like a "modified POST" with the content in a request header rather than the request body. I don't really buy the concern that request bodies can be logged and analyzed: * this applies equally well to the login forms that are most probably used at the AS, as well as to all the other requests to the client application that exchange confidential data * why wouldn't it apply to request headers as well? I don't really buy the concern that request_mode=form_post (or form_post.jwt) putting the data in the DOM is a problem: if you're concerned that a malicious browser or browser extension could read and process them, then what about the rest of the AS interactions with the user? (e.g. the login form) Same for XSS. Wrt the Referer header leaking the URL, the Referrer-Policy could likely help, and it defaults to strict-origin-when-cross-origin which should already protect most cases we're interested in here. Anyway, feel free to propose this to the HTTP WG, but I have some doubts it would be accepted (and I feel there are other, less disruptive, ways of addressing the authorization code leak/theft case; e.g. doesn't dpop_jkt or mTLS binding already protect those?) On Fri, Dec 12, 2025 at 1:45 PM 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] > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
