Share via

Key was found, but use of the key to verify the signature failed

support engineer 21 Reputation points
2022-06-22T11:42:23.977+00:00

com.microsoft.aad.msal4j.MsalInteractionRequiredException: AADSTS50013: Assertion failed signature validation. [Reason - Key was found, but use of the key to verify the signature failed., Thumbprint of key used by client: '8D2D57A353960E3FF9DAF6F018D82F40ED95CCC7', Found key 'Start=01/30/2022 23:06:14, End=01/30/2027 23:06:14'].
Trace ID: b9b7ae0e-41b9-4cc2-896e-e55a43b22d00
Correlation ID: 9cfae943-8f32-4c35-89d6-70d95596a2ae
Timestamp: 2022-06-22 11:41:13Z
at com.microsoft.aad.msal4j.MsalServiceExceptionFactory.fromHttpResponse(MsalServiceExceptionFactory.java:39)
at com.microsoft.aad.msal4j.TokenRequestExecutor.createAuthenticationResultFromOauthHttpResponse(TokenRequestExecutor.java:102)
at com.microsoft.aad.msal4j.TokenRequestExecutor.executeTokenRequest(TokenRequestExecutor.java:33)
at com.microsoft.aad.msal4j.AbstractClientApplicationBase.acquireTokenCommon(AbstractClientApplicationBase.java:128)
at com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier.execute(AcquireTokenByAuthorizationGrantSupplier.java:63)
at com.microsoft.aad.msal4j.AcquireTokenByOnBehalfOfSupplier.acquireTokenOnBehalfOf(AcquireTokenByOnBehalfOfSupplier.java:63)
at com.microsoft.aad.msal4j.AcquireTokenByOnBehalfOfSupplier.execute(AcquireTokenByOnBehalfOfSupplier.java:49)
at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:71)
at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:20)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1692)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

Azure API Management
Azure API Management
An Azure service that provides a hybrid, multi-cloud management platform for APIs.
0 comments
Accepted answer
  1. Alfredo Revilla - Upwork Top Talent | IAM SWE SWA 27,526 Reputation points Moderator
    2022-06-22T19:42:21.747+00:00

    Hello @support engineer , errors as this are usually caused by wrong OBO implementation.

    Please ensure that:

    1. You're getting an access token from the middle-tier API for your user.
    2. You're using the retrieved access token as assertion for the OBO call between the middle-tier and downstream Api (target resource).
    3. If using client credentials, you're properly creating the client_assertion using a registered X.509 cert for each Api.

    Let us know if this answer was helpful to you or if you need additional assistance. If it was helpful, please remember to accept it so that others in the community with similar questions can more easily find a solution.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2023-01-26T22:14:37.1233333+00:00

    Hi, I came across the same error while working with the OAuth v2.0 on-behalf-of flow using the Python library azure-identity (1.12.0) and following the OAuth v2.0 on-behalf-of flow documentation. The same error AADSTS50013 was thrown when I tried to use the get_token method of the OnBehalfOfCredential class.

    I solved it by having the correct aud claim in the user's access token when instantiating a OnBehalfOfCredential object. This was mentioned in the documentation:
    "This token must have an audience (aud) claim of the app making this OBO request (the app denoted by the client-id field)."

    To do so, in the Expose an API tab of the app registration I added an application ID URI: api://{client_id}, a scope called user_impersonation and authorised a client application to have the scope user_impersonation so that no consent is required: 04b07795-8ddb-461a-bbee-02f9e1bf7b46 (Azure CLI). I looked up the ID in the documentation.

    If I requested a token as a user with the Azure CLI:

    az account get-access-token --tenant {tenant_id} --scope api://{client_id}/user_impersonation

    ...the aud claim was api://{client_id}/user_impersonation

    I then added the delegated permission in the API permissions tab of the app registration: user_impersonation which allowed me to get a token with the scope {client_id}/user_impersonation or {client_id}/.default:

    az account get-access-token --tenant {tenant_id} --scope {client_id}/user_impersonation

    The aud claim became {client_id} which solved the problem for me when using the OnBehalfOfCredential class. The user's access token was used as the user_assertion parameter.

    0 comments
  2. Pavel Yadlouski 0 Reputation points
    2025-08-26T07:12:41.4066667+00:00

    Hello,

    I've face the very same problem. The root of my problem was that upstream app, from wich I was receiving the access token for user assertion into dowsntream AppB, was an app used for SSO. There is explicit mention of such setup in docs

    Additionally, applications with custom signing keys can't be used as middle-tier APIs in the OBO flow. This includes enterprise applications configured for single sign-on. If the middle-tier API uses a custom signing key, the downstream API won't validate the signature of the access token that is passed to it. This results in an error because tokens signed with a key controlled by the client can't be safely accepted.

    So, the solution could be to setup a separate app for issuing such access tokens for user assertion that is not used for SSO.

    Hope tha helps :)

    0 comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.