Error requesting token for downstream API with Identity & Entra External ID

[vpben]

Hi all,

I'm attempting to authenticate a downstream API from a Web API. I've followed this guide to set up both projects.

When the Identity package attempts to get a token for the downstream API (via either IDownstreamApi or ITokenAcquisition), I receive an error from Entra which reads:

{
  "error": "server_error",
  "error_description": "AADSTS50000: There was an error issuing a token or an issue with our sign-in service. Trace ID: {redacted-guid} Correlation ID: {redacted-guid} Timestamp: 2025-03-11 14:06:33Z",
  "error_codes": [50000],
  "timestamp": "2025-03-11 14:06:33Z",
  "trace_id": "{redacted-guid}",
  "correlation_id": "{redacted-guid}",
  "error_uri": "{redacted-uri}/error?code=50000"
}

By watching the HTTP calls to the token endpoint, I can see what is being requested by the Identity package. It is adding extra scopes and an extra parameter which are causing the call to fail.

The extra scopes are offline_access, openid, and profile. The extra parameter is client_info=1.
If I make the same call to the token endpoint via curl, but remove the client_info parameter and openid & profile scopes, I receive a valid access token for the downstream API.

I'm struggling as to how I should approach debugging this. I'm also unsure if this is a problem with Entra not accepting valid inputs or (far more likely) I've mis-configured something to cause the request to have invalid parameters. Does anyone have suggestions as to where to start? I am happy to provide extra information if needed.

Thank you.

[vpben]

In typical fashion, I have started to narrow down the problem only after asking for help.

For anyone else who has this problem in the future, it appears to be related to the middle-tier API having an extension attribute claim in the token.
According to this documentation, apps with custom signing keys can't be used as middle-tier APIs. It also seems that customising claims causes custom signing keys to be used, even if you don't explicitly set up a key yourself.

I have yet to check if there is a workaround to still be able to use custom claims. For now though, removing them from at least the middle API allows the on-behalf-of flow to work correctly.

[jmprieur]

@vpben : even if there are custom signing keys they should be advertised by the IDP?
Is it Entra ID? or Entra External IDs?

[vpben]

Thank you for responding. This is using Entra External ID.

I had set up the additional claim using the single sign-on section in enterprise applications, then updated the app manifest to include acceptMappedClaims: true as this is a single-tenant app.

[jmprieur]

I'm not familiar with this. Do you have a link to a doc?

[vpben]

No problem.

I'd used this guide for adding custom attributes to claims: Add user attributes to token claims.

There is a notice at the top of the SSO page in Entra saying "OIDC Applications require custom signing keys to customize claims" with a link to this section. You can see it in the screenshot under step 6 of the first link.

This seemed to fit with another page (Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow) where the last paragraph of the Client Limitations section mentions custom signing keys being incompatible with the on-behalf-of flow.

I don't think this is a problem with this package. I think the linked docs could be clearer that the features are incompatible, and it's a bit odd that I got such a generic error from Entra, but neither of those a part of this project. Thank you for looking though.

[jmprieur]

Thanks for sharing.
Yes, this is not about Microsoft.Identity.Web and this is a security feature.