Entra ID - Adding actor claim to the token via client credential flow

Question

I have an old ASP.NET MVC app that uses ASP.NET membership to login users and issues a sign in cookie. My application needs to call an API protected by Entra ID (users themselves don't have Entra ID accounts nor access to the API). The app server can acquire a token for the API using client credentials flow (service principal or Azure managed identity).

Is there a way to add "actor" claim (or any arbitrary-name claim) to the access token that's issued for the app server, that would contain a username of my membership user?

It seems I can't use on-behalf-of flow since my users aren't registered in EntraID and don't have access to the API themselves, so I'm stuck with client credentials flow.

There is a claims parameter in the TokenRequestContext, but that doesn't seem to have any effect - claims passed to EntraID token endpoint seem to just be ignored. I wonder why that parameter is even in there.

var azureCredential = new ManagedIdentityCredential();

var claimsDict = new Dictionary<string, string>
{
    { "actor", "[email protected]" }
};

var claimsJson = JsonConvert.SerializeObject(claimsDict);

var context = new TokenRequestContext(scopes: new[] { scope }, claims: claimsJson);

var accessToken = await azureCredential.GetTokenAsync(context);

return accessToken.Token; // Doesn't have "actor" claim.

My last resort solution is to pass actor as a custom HTTP header, add a custom role to the service principal (something like can_specify_actor) and have the API take the actor from the headers if a user has this role. This is far from ideal, it would be much better if the claim was in the JWT.

Answer 1

My understanding is that this claims argument is not supported at all by ManagedIdentityCredential. It's supported by MSAL (https://learn.microsoft.com/en-us/dotnet/api/microsoft.identity.client.abstractacquiretokenparameterbuilder-1.withclaims?view=msal-dotnet-latest) and used in Conditional Access error scenarios.

As far as I can see this is the intended scenario:

1. App tries to get a token on behalf of a user
2. Conditional Access policy blocks it due to user having to do MFA
3. MSAL returns an error that has the Claims property set
4. App passes this Claims value to that argument with an MSAL credential
5. Interactive authentication is triggered and this time we might get a token

Your last resort solution is what you will probably need to go with.