Combination of AccessTokenManagement and custom Pushed Authorization Request

[iseneirik]

Hi,

We are integrating with an OIDC-provider (HelseId) where we need to write custom logic for PAR, as we need to send multiple resources in the request, whereas the standard PAR-handling in Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler only handles a single resource.

To do this, we register our own handler on Events.OnPushAuthorization that wraps the inner handler and does our custom PAR-flow:

private static Func<PushedAuthorizationContext, Task> HandlePushAuthorization(Func<PushedAuthorizationContext, Task> innerHandler) =>
    async pushedAuthorizationContext =>
    {
        await innerHandler.Invoke(pushedAuthorizationContext);

        // ... Omitted for brevity

        var clientAssertion = await assertionService.GetClientAssertionAsync();
        var parRequest = new PushedAuthorizationRequest
        {
            Parameters = new Parameters(pushedAuthorizationContext.ProtocolMessage.Parameters),
            Address = $"{config.HelseId.Authority}/connect/par",
            ClientCredentialStyle = ClientCredentialStyle.PostBody,
            ClientAssertion = clientAssertion!,
            AcrValues = config.HelseId.GetAcrValues(amr),
            Resource = resource as ICollection<string> ?? [],
        };

        var response = await pushedAuthorizationContext.Options.Backchannel.PushAuthorizationAsync(parRequest);
        
        // ... Omitted for brevity

        pushedAuthorizationContext.HandlePush(response.RequestUri!);
    };

At the same time, we also use .AddOpenIdConnectAccessTokenManagement(...) from Duende.AccessTokenManagement.OpenIdConnect, which wires up its own handler for the PAR-flow, which in turn becomes the innerHandler of the above code.

The new version (4.2) of Duende.AccessTokenManagement.OpenIdConnect introduces a breaking change for us, more precisely the change found on lines 158-174 of access-token-management/src/AccessTokenManagement.OpenIdConnect/Internal/ConfigureOpenIdConnectOptions.cs.

What happens is this (with reference to the above snippet):

1. The inner handler we call in our custom PAR-handling ends up in the PAR-handler from Duende.AccessTokenManagement.OpenIdConnect, this sets ClientAssertionType and ClientAssertion and calls context.HandleClientAuthentication()
2. We create our PushedAuthorizationRequest and call PushAuthorizationAsync(...) (from Duende.IdentityModel)
3. The first problem: further down the call-chain ProtocolRequest.Prepare() is called, which attempts to write ClientAssertionType and ClientAssertion from our PushedAuthorizationRequest. This was already done in step 1, so it ends up with a "Duplicate parameter..." error (line 212 of ProtocolRequest)
4. We fix the first problem by not setting ClientAssertion in our PushedAuthorizationRequest, letting the inner handler do its job, which seems fine.
5. The second problem: now that we are able to do the PushAuthorizationAsync(...) we continue by calling pushedAuthorizationContext.HandlePush(...) so that OpenIdConnectHandler doesn't do the PAR for us. This results in: "Only one of HandlePush, SkipPush, and HandledClientAuthentication may be called in the OnPushAuthorization event." because of context.HandleClientAuthentication() being called in step 1.

The solution for us is to just omit calling the inner handler entirely, which seems to work fine. The reason I'm posting this is because we get a sense that we are doing something wrong since the libraries you provide don't play well together for this scenario.

Are we correct in handling it this way? Or is there a better way for handling PAR with multiple resources?

[wcabus]

PR 345 introduced regenerating client assertions to enable retrying DPoP nonce requests. In your use case, you need to take ownership of generating the PAR request yourself because of the requirement of sending multiple resource URIs. So I don't think you're doing anything wrong here.

I would agree that the best approach is to not call the inner handler from Duende.AccessTokenManagement.OpenIdConnect. Since you're also setting the client assertion retrieved from the IClientAssertionService, you're basically doing the same thing as the inner handler (and more).

[iseneirik]

Thanks for the quick response! We will stick to our solution.