My take is there is interest from the OAuth community in this work. I've chatted with the httpbis and httpapi chairs -- and the respective AD -- and the conclusion is this work fits best in httpbis.
I'll be posting an ID there. I'll respond to this thread when I have done that. /Dick On Fri, Dec 12, 2025 at 7:50 PM Thomas Broyer <[email protected]> wrote: > > > Le ven. 12 déc. 2025, 19:15, Aaron Parecki <[email protected]> a écrit : > >> > 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 point is that OAuth's use of query string parameters is *not* >> resource identification. Arguably OAuth should never have overloaded the >> usage of query strings in the first place, but obviously that was the only >> way to make things work. >> > > The problem is less resource identification (really, seeing > /callback?code=xxx&state=xxx you can describe what it represents: the > application state for some code and state, which will likely be a redirect > or an error) than using GET for something that's *meant* to have > side-effects (getting it once changes its state forever). But we're heading > towards "theoretical purity" territory and it's generally a waste if time. > > The main difference is that OAuth used what was available (and within the > limits of what was usable in a browser) and didn't try to invent something > new (like that Request-Query header and its attached behaviors), which is a > whole different story with way more implications. > > >> On Fri, Dec 12, 2025 at 10:11 AM Thomas Broyer <[email protected]> >> wrote: >> >>> 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] >>> >>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
