Forum Discussion
ID token issued by AAD doesn't match public signing key
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?
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-97bc-6eba6914391e 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.
- Thank you so much. This saved my day.
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.
Try this endpoint
https://<tenant-name>.b2clogin.com/
<tenant-name>.onmicrosoft.com/<policy_name>/discovery/v2.0/keys
