Forum Discussion

Alex_Lu's avatar
Alex_Lu
Copper Contributor
Jul 16, 2020

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?

Authentication
Azure Active Directory (AAD)
Identity Management

9 Replies

  • ashutoshranjan's avatar
    ashutoshranjan
    Copper Contributor
    Mar 31, 2025

    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.

  • Ashish-Prakash-Patil's avatar
    Ashish-Prakash-Patil
    Copper Contributor
    Mar 27, 2021

    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-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.

  • Martin Rublik's avatar
    Martin Rublik
    Brass Contributor
    Jul 21, 2020

    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

    • Alex_Lu's avatar
      Alex_Lu
      Copper Contributor
      Jul 29, 2020

      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. 

      • jinsongz's avatar
        jinsongz
        Copper Contributor
        Sep 04, 2020

        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.

Resources