For OAuth/OIDC specifically, I'm worried about the amount of churn on RPs' having to adopt Redirect-Query.
The 2 problems highlighted are parameter leakage and poor origin verification. For the latter, you can keep Redirect-Origin as a new header for sites that care about security enough to inspect it. For parameter leakage, can it be addressed by better first-class browser support for post redirects in a way that doesn't require RPs to change? e.g. idp.com sends Location: rp.com and Form-Encoded: code=cred&state=stuff which the browser handles directly (without going through the DOM/JS) and sends to rp.com in the same way normal form-post looks today? (I'm not sure but maybe you could even allow this with SameSite=Lax cookies?) On Tue, Dec 16, 2025 at 8:39 AM Dick Hardt <[email protected]> wrote: > Hey Nico, I'll drop you a note separately to discuss! > > On Tue, Dec 16, 2025 at 4:09 PM Nico Williams <[email protected]> > wrote: > >> On Tue, Dec 16, 2025 at 09:47:16AM +0100, Dick Hardt wrote: >> > That’s what this proposal changes! >> >> Right, and oddly my timing is similar :) I had the same idea in a >> slightly different way because I was attacking the 401/407 case which.. >> still needs fixing. >> >> 401 is the case that afflicts curl: you have to know a priori that curl >> will need a Bearer token and then you must provide it to it. >> >> Sure, teaching curl to do the extra header shuffle on redirects will fix >> that, except that there is a problem: libcurl terminates processing of >> redirect responses immediately upon seeing a `Location:` header, and >> fixing that is tricky. (And we can't count on the order in which >> headers are put in the response because middle boxes can re-order them.) >> Also curl does not chase redirects by default (maybe it should though). >> >> 407 is more severe because it's the only way we can really do >> authentication to proxies -- curl could be taught to do the redirect >> thing, but that's not really an option for proxies. (Well, it is an >> option for MITMing proxies, but it's quite cumbersome.) 407 is very >> similar to 401, so fixing the 401 workflow fixes the 407 workflow. >> >> I'd be interested in melding your and my approaches, given how similar >> they are, because while browsers rely on the redirect workflow, other >> things rely on 401/407. >> >> At $WORK we have libraries that fetch tokens and insert `Authorization:` >> headers into requests for non-browser HTTP user-agents, including >> curl/libcurl, and we use Kerberos for proxy auth. We want to move away >> from Kerberos for anything for many reasons, not the least of which >> being how easy it is to add claims to JWTs and how hard it is to add >> claims to (and extract them from) Kerberos tickets. This means we need >> a solution for the 407 case, and we'd like a solution for the 401 case. >> >> Nico >> -- >> > _______________________________________________ > 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]
