I agree with both of you - a redirect was not the most appropriate HTTP mechanism to make a non-idempotent, non-cacheable, cross-domain call - even if was the ergonomically best browser mechanism. SameSite cookie restrictions are another often-forgotten complexity that I’d call out with these sorts of cross-domain invocations.
I suspect this sort of mechanism (a way to invoke a method which is not normally recorded in access logs or accessible to javascript) would also be more generally useful outside OIDC, so this may be better served starting as a high level discussion with domain experts in the HTTP WG (e.g. goals and use cases rather than mechanisms). I’m unsure if HTTPAPI would be the more appropriate place - I always have been a bit fuzzy on the line drawn between the two, but I thought HTTPAPI was focused on M2M use cases, while it sounds like the goal here would be something which would eventually have browser support. -DW > On Dec 12, 2025, at 11:15 AM, Aaron Parecki > <[email protected]> wrote: > > > 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. > > > On Fri, Dec 12, 2025 at 10:11 AM Thomas Broyer <[email protected] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > 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]
