IDX10241: Security token validated. token: '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.

Question

Now getting below error -

 IDX10241: Security token validated. token: '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'.

 

Perviouly was - IDX10214: Audience validation failed. Audiences: '00000002-0000-0000-c000-000000000000'. Did not match: validationParameters.ValidAudience: '3ac0000-0000-0000-ba26-9508e0c058d9' or validationParameters.ValidAudiences: 'null' - This is resolved now

 

Authorization Configuration –

builder.Services.AddAuthorization(config =>

{

    config.FallbackPolicy = new AuthorizationPolicyBuilder()

        .RequireAuthenticatedUser()

        .Build();

    config.AddPolicy("AuthPolicy", policyBuilder => policyBuilder.Requirements.Add(new ScopeAuthorizationRequirement()

    {

        RequiredScopesConfigurationKey = $"AzureAd:Scopes",

    }));

});

Please help me to resolve this....

Answer 1

Hello Prithvi Singh,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well. 

I will try to clarify your doubts regarding this issue and will suggest you some workarounds.

The reported message, IDX10241: Security token validated., is a successful log entry emitted by the System.IdentityModel.Tokens.Jwt or related NuGet packages, typically at the Information or Debug level. This message confirms that all primary token validation checks (signature, lifetime, and audience) have passed (IDX10214 resolved). The issue is likely an Authorization Failure (401/403) occurring after successful token validation in the ASP.NET Core Authorization Middleware. Probable cause will be the configuration uses a custom ScopeAuthorizationRequirement tied to AzureAd:Scopes, but the token lacks the required scopes or roles, or they don’t match the values in AzureAd:Scopes.

I would like to know some extra information to provide you the better solution as

• What HTTP Status Code are you receiving from the API/application when this message appears in the logs? (e.g., 200 OK, 401 Unauthorized, 403 Forbidden).
• What are the exact values defined in your appsettings.json (or environment) for the configuration key: AzureAd:Scopes? (e.g., access_as_user, MyApi.Read).
• Can you decode the token (using a tool like jwt.ms) and confirm the scp (scope) and/or roles claims present in the token's payload?
• Are you still receiving a 401 Unauthorized response, or is it a different error (e.g., a 403 Forbidden)?

Till then will suggest you some workarounds as below:

You need to try debugging the Authorization step, not the token validation step (which is complete).

Debugging Authorization and Scope Claims

1. Temporarily Enable Full PII Logging: To confirm the exact validation steps and view the token's contents in the log, enable PII logging (only in a development environment):

      using Microsoft.IdentityModel.Logging;
      // In your Program.cs or Startup.cs constructor/Configure method
      IdentityModelEventSource.ShowPII = true;
   

   This should reveal the token's claims in the logs, allowing you to visually inspect the scp or roles claim. NOTE: Do this only in development, never in production.
2. Verify Scope/Claim Mapping: Check the Token Claims: Use the decoded token (from PII logs or jwt.ms) to check the value of the scp claim (for v2.0 tokens) or the roles claim. Check the Configuration: Ensure this value exactly matches the comma-separated list of scopes configured in your AzureAd:Scopes setting. Claims are case-sensitive and must be an exact match.
3. Ensure Scope is Requested: Verify that the client application (the one acquiring the token) is correctly requesting the necessary scope (e.g., api://<AppID-URI>/<ScopeName>) when obtaining the access token from Azure AD. If the client doesn't request the scope, the API will never receive the required scp claim.
4. Add a Fallback Policy or Debugging: If the issue is a 401, remove the custom policy and try the built-in logic to confirm the basic token processing is fine:

      // Temporarily revert to standard JWT Bearer authentication to rule out custom policy error
      builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
          .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));
      // Ensure the FallbackPolicy is simple (temporarily)
      config.FallbackPolicy = new AuthorizationPolicyBuilder()
          .RequireAuthenticatedUser()
          .Build();
   

If you can provide the HTTP status code and the decoded contents of the scp and roles claims from your token (if present), I can help you compare them against your authorization policy.

Please do refer these below documents for better understanding:

https://learn.microsoft.com/en-us/entra/identity-platform/scenario-protected-web-api-app-configuration?tabs=aspnetcore

https://learn.microsoft.com/en-us/entra/identity-platform/access-tokens#validate-tokens

https://learn.microsoft.com/en-us/dotnet/api/microsoft.identitymodel.logging.identitymodeleventsource.showpii?view=msal-web-dotnet-latest

OR alternatively you can use jwt.ms or Postman to decode and inspect token claims as an alternative to PII logging.

Hope this helps! If it answered your question, please consider clicking Accept Answer and Upvote. This will help us and others in the community as well.

If you need more info or the above did not work for you, feel free to ask in the comments. Happy to help!

Regards,

Monalisha