Duende.AccessTokenManagement.OpenIdConnect + Entra ID + Multiple APIs

[yigi-zz]

Hi, I'm trying to use the OIDC token management package, in the examples it looks pretty simple and straightforward, but I can't get it to properly work for me.

I am using Entra ID as IDP and my backend (bff) is forwarding calls to both Microsoft Graph and a custom api service.

• So in the initial authentication the scopes being asked are from graph + custom api.
• The issued access token includes only the graph scopes and even the subject is graph.

As I understand this is the expected behavior as Entra ID will not issues access tokens with multiple audiences.

I thought to configure the token management middleware with two named http clients, each with it's own scopes but I see both clients simply ignore the custom parameters and use the initial access token issued by the initial login.

What am I missing?

Here is how I register the named HTTP clients:

builder.Services.AddUserAccessTokenHttpClient("graph",
    new UserTokenRequestParameters
    {
        Scope = Duende.AccessTokenManagement.Scope.Parse("user.read.all")
    },
    configureClient: client =>
    {
        client.BaseAddress = new Uri("graphapi address..")
    });

The custom API HTTP client is registered the same way with custom scopes.

The behavior I get is that because the access token issued by Entra ID contains only graph scopes all graph calls work as expected but the custom API calls all end with 401 response.

What am I missing?

Thanks

[wcabus]

This might be a duplicate of https://github.com/orgs/DuendeSoftware/discussions/279.

In short, when your users need to access multiple scopes across different resources, you will need to request the initial access token for all resources / scopes. Then, for each of the named HTTP clients, you downscope to the scopes/resource needed for that specific API.

[yigi-zz]

Thanks for the reply, indeed its basically same issue.
I still don't fully understand:
If the "per request parameter" feature is used, but without force renewal, it is being ignored if the current access token is valid even the parameters specify different scopes? And if yes, how to avoid forcing renewal if the current access token matches the api being called? I thought the the whole point of the package is to handle such scenario automatically

[wcabus]

The Duende.AccessTokenManagement.OpenIdConnect library uses the cached access token by default. If you request a token with new parameters (e.g., different scopes) but an existing valid token is already cached, the cached token will be reused, even if it doesn't match the new parameters, unless ForceRenewal is enabled.

To ensure the correct token is used for each API, you should request tokens with the exact scopes needed for that API from the start. The package handles caching and renewal automatically, but it relies on the initial request parameters to determine which token to cache and reuse.

[yigi-zz]

I understand but getting this done is confusing and there are no code samples available.
For example, for openid connect configuration like this:
.AddOpenIdConnect(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
options.Authority = builder.Configuration["IdentityProvider:Authority"];
options.ClientId = builder.Configuration["IdentityProvider:ClientId"];
options.ClientSecret = builder.Configuration["IdentityProvider:ClientSecret"];
options.CallbackPath = builder.Configuration["IdentityProvider:CallbackPath"];
options.ResponseType = OpenIdConnectResponseType.Code;
options.ResponseMode = OpenIdConnectResponseMode.Query;
options.SaveTokens = true;
options.Scope.Add(OpenIdConnectScope.OfflineAccess);
options.Scope.Add("user.read.all"); // example graph scope
options.Scope.Add("store.read"); // example custom api scope
}

Working with entra id will issue access token with graph audience and scope only.
How to cache additional access token for custom api?
How to get each http client using the correct access token from cache?

[wcabus]

@yigi-zz While the resource method would be the way to go, unfortunately, Entra ID doesn't support the resource parameter at the OAuth token endpoint to retrieve a token for a specific resource.

While I was looking for an alternative fix, I may have stumbled upon a bug in the latest Duende.AccessTokenManagement.OpenIdConnect version(s). Stay tuned :)

[yigi-zz]

@wcabus Great, I can't wait :)
BTW maybe another bug at Duende.AccessTokenManagement.OpenIdConnect.Internal.OpenIdConnectUserAccessTokenRetriever
line 17, the force refresh boolean is not being copied, is it on purpose?

[wcabus]

That is exactly the bug I'm referring to, and it's preventing you to force requesting a new token using the different scopes. If this is fixed, you should be able to retrieve a new access token per HTTP client using the desired scopes.

You may need to change the MS Graph scopes to include the resource name however, so that groupmember.read.all becomes https://graph.microsoft.com/groupmember.read.all

[yigi-zz]

@wcabus ahh :)
My concern is that for every client request a new access token is issued which is of course unnecessary. Can you think of a way I can avoid it?
Indeed this way it is much easier to work with https clients without taking care of attaching access tokens to requests but the caching is totally ignored.

[wcabus]

At this moment, the only way to cache different access tokens is on a per-resource basis, but that doesn't work with Entra ID because it doesn't support the resource parameter.

We're investigating what we can do to improve this behavior, without becoming too Entra ID specific.