Over the weekend, we saw one of our services suddenly rejecting tokens issued by Microsoft Entra ID.
We have two tenants, lets call them A and B.
Service 1 (hosted in A) is configured to use Bearer tokens from Entra ID with the issuer https://login.microsoftonline.com/A/v2.0.
Service 2 is configured to accept Bearer tokens from Entra ID with the issuer https://login.microsoftonline.com/B/v2.0.
This worked fine until Sunday.
Suddenly we get IDX10500 errors: Signature validation failed. No security keys were provided to validate the signature. But strangely, only in Service 1.
So we checked the OpenID Connect discovery document under https://login.microsoftonline.com/A/v2.0/.well-known/openid-configuration and made sure the key from the token header was available at the jwks_uri https://login.microsoftonline.com/A/discovery/v2.0/keys. And there it was.
Interestingly the same key id was also available at https://login.microsoftonline.com/B/discovery/v2.0/keys (same key parameters/material and everything) So out of pure frustration, we just changed JwtBearerOptions.MetadataAddress in service 1 to the discovery document
of tenant B: https://login.microsoftonline.com/B/v2.0/.well-known/openid-configuration. lo-and-behold, service 1 was able to validate the signatures again.
We'll leave it like this for now, but it certainly doesnt make sense. Can someone explain it to me? Is this a Microsoft issue we should report?
The problem appeared out of nowhere. And nowhere is where it went...
A few hours after I had found that "workaround" and wrote the original question, Service 1 started to work again with the original configuration for JwtBearerOptions.MetadataAddress
Oh well.