Using DPoP with IHttpClientFactory guidance needed

[blowdart]

As part of supporting proxies I have a library that configures its own named client and configures an appropriate handler for the proxy configuration and a little bit more.

If someone sets a proxy it's probably for a good reason, or for running everything through fiddler, and so I want to flow that down to the OIDC client. Which is fine, I can set the HttpClientFactory in OidcClientOptions but ... of course, if I do that the handler doesn't get wired up and DPoP fails.

If I remove the handler settings, DPoP works but nothing goes through the proxy. I went looking for a sample of the two working together but didn't find anything. How do I get them all to play nicely together?

[josephdecock]

When you're creating an HttpClient that will use DPoP with CreateDPoPHandler, there's an optional 3rd argument that allows you to pass an HttpMessageHandler. So, if your proxy library can give you a handler, I would pass that in:

var handler = _oidcClient.CreateDPoPHandler(proofKey, refreshToken, handlerFromYourProxy);

If your library is dealing entirely with an HttpClient that might be tricky though, as (at least afaik) the client encapsulates the underlying handlers and doesn't give you a way to get at them. However, you can wrap a client around an existing delegating handler. If your library can do that, you could create the dpop handler, cast it to DelegatingHandler, and then pass it into your proxy library. CreateDPoPHandler actually creates a DelegatingHandler, but its type is the less specific HttpMessageHandler - I'm really not sure why, and if that helps you maybe we would want to change that. Please let me know how it goes!

[blowdart]

My goal was to configure HttpClient used between _oidcClient.PrepareLoginAsync() and _oidcClient.ProcessResponseAsync()

Your comments did get me unblocked thought, but it's ugly as sin, passing around two different funcs, one to configure the HttpClient and one to create the right inner handler.

One thing to note this is not a proxy library. This is standard .NET Core HttpClient configuration and I'm surprised that proxy configuration has not come up before and been documented. As a library author I want to configure proxies using a handler, rather than HttpClient.DefaultProxy because I want to be a good citizen and limit it to clients within my library, and the clients in things it uses, rather than globally splat it.

To make it more interesting I use .NET's IHttpClientFactory approach to configure my HttpClients in a central service to avoid having to configure things in multiple places. Of course, you soon discover what you name in OidcClientOptions as an HttpClientFactory property, well, isn't the .NET HttpClientFactory, so there's that little bonus :)

[josephdecock]

Are you able to share a bit of the ugly code? I'd like to make this better :)

[blowdart]

Certainly can

https://github.com/blowdart/idunno.Bluesky/blob/feature/oauth/src/idunno.AtProto/Authentication/OAuthClient.cs

This is a horrible work in progress, so feel free to poke holes in my code, it'd be rather Brock 😂

[josephdecock]

Oh, this is what you've been posting about on Bluesky - cool!

It seems like the problem comes from the fact that we have 2 different ways to configure the backchannel http client - you can simply set a handler value (BackchannelHandler), or you can supply a function to build it (HttpClientFactory), with HttpClientFactory taking precedence.

Internally, oidcOptions.ConfigureDPoP(ProofKey); sets the BackchannelHandler, which means that you can't supply your own BackchannelHandler directly, and if you set an HttpClientFactory, then the setup done by the call to ConfigureDPoP is overridden.

And that forces ugly code like this:

OidcClientOptions oidcOptions = new()
            {
                // ...
                HttpClientFactory = (oidcOptions) =>
                {
                    var httpClient = new HttpClient(new ProofTokenMessageHandler(ProofKey, _innerFactoryHandler()), true);
                    return _clientConfigurationHandler(httpClient);
                }
            };

When you really just want to configure the HttpClient.

So ideally, oidcOptions.ConfigureDPoP(ProofKey); would just do the right thing, and somehow compose our dpop message handler with everything the user supplied to configure the backchannel.

I think it would be easy to make it respect the BackchannelHandler property, as we can pass that to the dpop handler we're building as its inner handler.

Dealing with the HttpClientFactory is harder - and probably would require a breaking change since we can't compose our handler with the already created clients that the factory will produce. If instead of the HttpClientFactory, we had a factory for producing the BackchannelHandler, then we could simply invoke the factory and then compose the resulting handler with our dpop handler. But, that's probably too big of a breaking change to ever do - I imagine there are lots of uses of the existing factory without DPoP.
Maybe we could have a HandlerFactory, but the API surface is already kind of tricky to understand with two different ways to control the backchannel http requests, and this would be a 3rd one, with subtle/surprising interactions with DPoP.
Another unsatisfying option would be to just decide that ConfigureDPoP only respects the BackChannelHandler.

[blowdart]

Dealing with the HttpClientFactory is harder - and probably would require a breaking change since we can't compose our handler with the already created clients that the factory will produce. If instead of the HttpClientFactory, we had a factory for producing the BackchannelHandler, then we could simply invoke the factory and then compose the resulting handler with our dpop handler. But, that's probably too big of a breaking change to ever do - I imagine there are lots of uses of the existing factory without DPoP.

And because that needs state the whole .NET IHttpClientFactory approach breaks down (I'm being very grumpy about this internally). This is where documentation would help :)

I'm just hoping the DPoP stuff will work on an HttpRequest and HttpResponse, because I really need to avoid all this mess when it comes to making signed requests, the factory is there to manage handler lifetimes and reduce the overhead of creating HttpClients each time.