Is it possible to make "AddBff" indifferent to order?

[iseneirik]

Before summer we added DPoP to our auth-flow, and spent some time debugging when things didn't go as expected. What we found out is that our call to ConfigureOptions<ConfigureOpenIdConnectOptions>() would have to come before AddBff(), because inside AddBff() and subsequently AddOpenIdConnectAccessTokenManagement() there is a call to ConfigureOptions that wraps previously registered events on OpenIdConnectOptions with CreateCallback:

public void Configure(string? name, OpenIdConnectOptions options)
{
    if (_configScheme == name)
    {
        // add the event handling to enable DPoP for this OIDC client
        options.Events.OnRedirectToIdentityProvider = CreateCallback(options.Events.OnRedirectToIdentityProvider);
        options.Events.OnAuthorizationCodeReceived = CreateCallback(options.Events.OnAuthorizationCodeReceived);
        options.Events.OnTokenValidated = CreateCallback(options.Events.OnTokenValidated);
        options.BackchannelHttpHandler = new AuthorizationServerDPoPHandler(_dPoPProofService, _dPoPNonceStore, _httpContextAccessor, _loggerFactory)
        {
            InnerHandler = options.BackchannelHttpHandler ?? new HttpClientHandler()
        };
    }
}

Our solution to this was to change the order of where we add our ConfigureOptions<OpenIdConnectOptions> so that our configuration is run before the one registered by AddOpenIdConnectAccessTokenManagement(). This works, but if it is possible, I suspect changing it to IPostConfigureOptions (as you have done in AddBff() for PostConfigureOidcOptionsForSilentLogin) would make this more agnostic to the order in which the configuration is done.

My question is the following: are there more considerations to be made, or can the following change be made to AddOpenIdConnectAccessTokenManagement() making AddBff() more indifferent to the order in which it is added?

public static IServiceCollection AddOpenIdConnectAccessTokenManagement(this IServiceCollection services)
{
    // ...

-   services.ConfigureOptions<ConfigureOpenIdConnectOptions>();
+   services.AddSingleton<IPostConfigureOptions<OpenIdConnectOptions>, ConfigureOpenIdConnectOptions>();

    // ...
        
    return services;
}

[Erwinvandervalk]

Hi @iseneirik, Thank you for your question and sorry to hear you had issues applying DPOP to your flow.

We're investigating what the possibilities are here and will report back as soon as possible.

[iseneirik]

Great, thanks! 👍

[pgermishuys]

Hey @iseneirik, we've had a look at this and unfortunately we don't believe there is much we can do. You're correct that there is an ordering issue. However, moving to PostConfigureOptions also creates an ordering issue.

The underlying issue is that the AddOpenIdConnect call from Microsoft constructs an HTTP Client from the BackChannelHttpHandler. If we change our ConfigureOpenIdConnectOptions to also be post configure, the Microsoft AddOpenIdConnect invocation might construct the HttpClient using the BackChannelHttpHandler before we are able to set it.

So, this is an ordering problem which we don't believe we can elegantly resolve. We should be clearer in the documentation. We will also look if it's possible to raise a warning from the system if this is configured incorrectly.

[iseneirik]

I see the problem, thanks for looking into it.
Clarifying docs and/or a warning sounds like a great idea!