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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F1d063515-6cad-4195-9486-ea65df456faa%2Fdiscovery%2Fv2.0%2Fkeys&data=02%7C01%7Cyu.kuang.lu%40LEGO.com%7C83d34dcb3e744cd9498508d8294edcdf%7C1d0635156cad41959486ea65df456faa%7C1%7C0%7C637304765982427993&sdata=9WgGhPx7T%2B9ngD3RSu6zT3ePFwIfr3IwKk2m9JiNAxE%3D&reserved=0
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?
10 Replies
For us the issue was that our BE code that validated the SSO token expected token version 2, but the app configuration in Azure portal had
accessTokenAcceptedVersion = null. That difference in versions changed the structure of the claims and thus the token decoding/validation.
Note though that our circumstance is a bit different than yours as we were setting up staging apps to mirror our prod ones. Sounds like you didn't make any code or app changes. But sharing just in case it's useful.I am facing exactly same issue. It was working fine until few days ago and then the issue started appearing. There wasn't any config change done or any change done for that matter. Has anyone figured out the solution or any pointers about what to look at will be very helpful.
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.
Try this endpoint
https://<tenant-name>.b2clogin.com/
<tenant-name>.onmicrosoft.com/<policy_name>/discovery/v2.0/keys
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.
