Jul 15 2020
11:49 PM
- last edited on
Jan 14 2022
04:30 PM
by
TechCommunityAP
Jul 15 2020
11:49 PM
- last edited on
Jan 14 2022
04:30 PM
by
TechCommunityAP
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?
Jul 20 2020 11:39 PM
@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
Jul 29 2020 12:21 AM
@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.
Sep 03 2020 06:29 PM
@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.
Sep 03 2020 11:58 PM
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.
Nov 10 2020 05:04 PM
Try this endpoint
https://<tenant-name>.b2clogin.com/
<tenant-name>.onmicrosoft.com/<policy_name>/discovery/v2.0/keys
Mar 27 2021 07:59 AM
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.