Authorization code should always be redeemed with MSAL

[scrocquesel-ml150]

Microsoft.Identity.Web Library

Microsoft.Identity.Web

Microsoft.Identity.Web version

4.1.0

Web app

Sign-in users

Web API

Not Applicable

Token cache serialization

Not Applicable

Description

I have configured my web application to use SignedAssertionFromManagedIdentity instead of clientSecret and ResponseType=code.
When redeeming the authorization_code on redirection, the app throws the exception

Microsoft.AspNetCore.Authentication.AuthenticationFailureException: An error was encountered while handling the remote login.
 ---> Microsoft.IdentityModel.Protocols.OpenIdConnect.OpenIdConnectProtocolException: Message contains error: 'invalid_client', error_description: 'AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'. Trace ID: 4fd981cf-1ae9-4f05-9c7b-f0608a8f0700 Correlation ID: eeb1c507-503c-4a69-84d1-42f2f39543cb Timestamp: 2025-11-28 14:53:40Z', error_uri: 'https://login.microsoftonline.com/error?code=7000218'.
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.RedeemAuthorizationCodeAsync(OpenIdConnectMessage tokenEndpointRequest)
   at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectHandler.HandleRemoteAuthenticateAsync()
   --- End of inner exception stack trace ---
   at Microsoft.AspNetCore.Authentication.RemoteAuthenticationHandler`1.HandleRequestAsync()
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddlewareImpl.Invoke(HttpContext context)

I configured logging level to debug but I don't see relevant traces around the exception that would tell the credential source fails.

With client secret, it works.

My app runs as a docker container inside App Services. The managed identity works ok to retrieve manually an assertion with this endpoint

// add a minimal endpoint, that returns "Hello World!"
app.MapGet("/token", async (ILogger<Program> logger) =>
{
    var fic = new ManagedIdentityClientAssertion("zzz", null, logger);
    var a = await fic.GetSignedAssertionAsync(new Microsoft.Identity.Client.AssertionRequestOptions()
    {
        ClientID = "yyy",
        TokenEndpoint = "https://login.microsoftonline.com/xxx/oauth2/token"
    });
    return a;
});

Reproduction steps

1. Program.cs

   var builder = WebApplication.CreateBuilder(args);
   builder.Services.AddMicrosoftIdentityWebAppAuthentication(builder.Configuration);
   var app = builder.Build();
   
   app.MapGet("/protected", () => "Hello").RequireAuthorization(p => p.RequireAuthenticatedUser());
   
   app.Run();

2. Configuration

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "xxx",
    "ClientId": "yyy",
    "ResponseType": "code",
    "ClientCredentials": [ 
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "zzz"
      }
    ],
    "CallbackPath": "/signin-oidc"
  }
}

3. In Entra of tenant Id xxx, create an app registration, declare a FIC with the managed identity zzz. This app registration has a client id yyy.

Error message

No response

Id Web logs

No response

Relevant code snippets

provided above

Regression

No response

Expected behavior

I would expect a more meaningfull exception, or at least some traces. With subscribeToOpenIdConnectMiddlewareDiagnosticsEvents set to true, I do have traces from category Microsoft.Identity.Web but not useful. Otherwise, I don't see any traces from this category.

[scrocquesel-ml150]

Got it working with EnableTokenAcquisitionToCallDownstreamApi(). In this case, OnAuthorizationCodeReceived is processed by Microsoft.Identity and not with the default OpenIdConnectHandler.

Would it be possible to actually handle the code even without token acquistion enabled ? And/Or document the limitation.

[scrocquesel-ml150]

What I did so far because I don't want to cache tokens at all.

builder.Services.AddMicrosoftIdentityWebAppAuthentication(builder.Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi();
builder.Services.TryAddSingleton<IMsalTokenCacheProvider, NoTokenCacheProvider>();


internal class NoTokenCacheProvider : IMsalTokenCacheProvider
{
    public Task ClearAsync(string homeAccountId)
    {
        return Task.CompletedTask;
    }

    public void Initialize(ITokenCache tokenCache)
    {
    }

    public Task InitializeAsync(ITokenCache tokenCache)
    {
        return Task.CompletedTask;
    }
}

[bgavrilMS]

Makes sense, Microsoft.Identity.Web knows how to handle these complex credentials. I understand then that your scenario is to just sign in users, i.e. get the id token aka the ClaimsPrincipal?

[scrocquesel-ml150]

Makes sense, Microsoft.Identity.Web knows how to handle these complex credentials. I understand then that your scenario is to just sign in users, i.e. get the id token aka the ClaimsPrincipal?

Yes, the application will not use the token to make any external call. I waste quite a lot of time because of some pain points :

1. it works with client secret and it should have been easy to change the configuration without modifying the user code. IMHO, to behave the same, the client secret should be merged on the configuration only if it is the selected client credential.
2. the name of the extension method is misleading as we don't call downstream api.
3. unfortunately, this lib is not listening to the authorization code received event unless enabling token acquisition which do not give an opportunity to log a configuration error.