Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community

ID token issued by AAD doesn't match public signing key

Copper Contributor

Hi,

 

I've encountered an issue that ID tokens (JWT) issued by AAD do not match a public signing key. 

 

This is my JWKS url: https://login.microsoftonline.com/1d063515-6cad-4195-9486-ea65df456faa/discovery/v2.0/keys

 

However the ID token I receive has a unmatched kid like below

 

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "ylQQc6jLgNEIt8AMAPm8jR27QCE"
}

 

 

It's been working fine until a couple of days ago. It is mentioned somewhere that AAD rotates public keys but it seems tokens might be persisted without knowledge that the signing key has changed. 

 

However access token match one of the keys like

 

{
  "typ": "JWT",
  "nonce": "ExKWqBKO2TvzbusXVkALk0RQhka3YiNxEKQg69gs27Q",
  "alg": "RS256",
  "x5t": "huN95IvPfehq34GzBDZ1GXGirnM",
  "kid": "huN95IvPfehq34GzBDZ1GXGirnM"
}

 

 

Is this the expected behaviour? AAD is my IDP and AWS Cognito is the auth server in my set up. Because of this issue, Cognito is unable to verify signature of ID tokens therefore users can sign in but cannot proceed further because of this.

 

Has anyone come across a similar issue before?

7 Replies

@Alex_Lu Hi, is the id_token still valid? According to https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#validating-an-id_token id_token should be within validity period, I would say (hope) that Azure AD does not rotate the keys until the id_tokens issued with previous key are still valid.

 

Martin

@Martin Rublik Thanks for the reply. Yes it was still valid. I also waited for the token to expire and requested a new token and I still didn't see any changes. It's very odd. We had to switch to SAML as we were not able to find out exactly why AAD behaved like this. 

@Alex_Lu I've run into exactly the same problem: the signing key (for the id token) does not match any of the keys pulled from the JWK uri (/discovery/v2.0/keys) while the signing key for the access token does match one. Were you able to solve it somehow? It seems not much we can do until Azure fixes it.

Hi @jinsongz, I'm glad someone else has encountered the same issue. 

 

We had no choice but to switch to SAML as the rest of the companies are all SAML based clients. Our set up is to have AWS cognito as authorization server with AAD as IDP. I suggest you follow the same pattern if you have a similar set up.

@Alex_Lu 

Try this endpoint 

https://<tenant-name>.b2clogin.com/

<tenant-name>.onmicrosoft.com/<policy_name>/discovery/v2.0/keys

@Alex_Luand @jinsongz 

 

I had a same issue where the key id in the id tokens  were not found at "https://login.microsoftonline.com/1d063515-6cad-4195-9486-ea65df456faa/discovery/v2.0/keys". Then I came across this piece in the documentation which says 

 

"If your app has custom signing keys as a result of using the claims-mapping feature, you must append an appid query parameter containing the app ID to get a jwks_uri pointing to your app's signing key information, which should be used for validation. For example   https://login.microsoftonline.com/{tenant}/.well-known/openid-configuration?appid=6731de76-14a6-49ae... contains a jwks_uri of  https://login.microsoftonline.com/{tenant}/discovery/keys?appid=6731de76-14a6-49ae-97bc-6eba6914391e...

 

When I updated my code to look for the jwks_uri as mentioned above, I was able to find the matching key Id.