Support for multiple configurations within same process (Duende.AccessTokenManagement)

[mortenlokensr]

When using client credentials token management with more than one client, it seems hard to implement isolated configurations.
Ie. AddClientCredentialsTokenManagement() only allows for one set of ClientCredentialTokenManagementOptions to be registered as well as all services registered in the DI-container allows only one implementation.

As an example, I use token management with two separate authorization servers, both requiring individual ClientCredentialTokenManagementOptions and custom implementations of IClientCredentialsTokenEndpoint. I can replace the default implementation for this interface in the DI-container, but it is hard with individual implementations for authorization servers.

I have solved this for now by implementing custom token managers, each decorating the token manager provided by the framework and injecting custom IClientCredentialsTokenEndpoint and ClientCredentialTokenManagementOptions by reflection.

This seems a bit hacky - does anyone have a better idea ?

[wcabus]

Could you elaborate a bit more where exactly you would need more control in order to connect to the different authorization servers?

The ClientCredentialsTokenManagementOptions only control caching settings intended to be shared for all client credential clients. And the default implementation of IClientCredentialsTokenEndpoint implements the logic to retrieve a token for OAuth 2.0 client credentials flow, while supporting client assertions and DPoP.

Duende.AccessTokenManagement is structured so that you can leverage the default, spec-compliant way of retrieving access tokens, and configure named token clients using the shared logic while setting client-specific options like the token endpoint URI etc.

I've marked your question as a feature request, so that others can chime in and provide feedback on this as well.

[mortenlokensr]

It seems like token caching strategies could vary between authorization servers, such that if I implement token management for two different authorization servers in the same process, I might like to have two different sets of ClientCredentialsTokenManagementOptions. For instance, I might like to use CacheAutoTuning for one, but not the other.

Since you specifically mention client assertions, I have a flow using client assertions (RFC 7523: https://www.rfc-editor.org/rfc/rfc7523) implemented using a AccessTokenRequestHandler.ITokenRetriever. However, the ClientCredentialsTokenClient, through calls to HttpClientTokenRequestExtensions.RequestClientCredentialsTokenAsync() hard-codes the grant_type to "client_credentials", whereas the correct grant type for RFC 7523 should be "urn:ietf:params:oauth:grant-type:jwt-bearer". I solved this using a message handler to modify the outbound request after the framework has prepared it. I realize the client credentials token manager might not be supposed to support RFC 7523, but with this modification I am able to leverage all the features of the token manager, ie. caching.