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]
