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]
