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]
