AADSTS50013 Assertion Failed Signature Validation | Fix

Seeing AADSTS50013 Assertion Failed Signature Validation in a sign-in trace usually means Azure AD could not trust the token your app sent. The error tends to show up during on-behalf-of flows, API calls that rely on bearer tokens, or when you switch certificates and secrets. The good news is that the message is pretty precise once you know how to read it, and you can narrow down the bad assertion quickly.

This guide walks through what the error text means, common patterns that trigger it, and clear fixes you can apply in Azure portal, your code, and your identity platform configuration. By the end, you should be able to take any AADSTS50013 trace from your logs and turn it into a concrete change that restores sign-in and API calls.

What The AADSTS50013 Assertion Failed Signature Validation Error Means

AADSTS50013 Assertion Failed Signature Validation tells you that Azure AD tried to verify the digital signature on an incoming JWT, but the check did not pass. Azure AD did find a key that matched the token header, yet the cryptographic verification failed, or the thumbprint in the trace did not line up with any active key in your app registration.

The full message usually includes a bracketed Reason field, such as “The key was not found”, “Key was found, but use of the key to verify the signature failed”, or “The token issuer does not match the expected issuer”. That short sentence is your starting point, because it tells you whether the trouble sits with keys, token contents, or tenant and authority settings.

You will usually see three main pieces in the trace message.

• Error code — AADSTS50013 identifies a failed signature check during token validation.
• Reason text — explains whether the key was not found, did not work, or the issuer or audience did not match.
• Thumbprint and dates — show which certificate or key Azure AD tried to use and when that credential starts and ends.

Common Causes Of AADSTS50013 In Azure Ad Token Flows

Most cases of AADSTS50013 come from a mismatch between the token you send and what Azure AD expects for that app registration. The nature of the mismatch depends on your authentication flow, but in practice the same handful of issues keep turning up across Microsoft Q&A, Stack Overflow, and GitHub threads.

The table below links the Reason text that often appears with this error to typical root causes and first checks.

Reading the table alongside your own error string helps you move from a vague “signature failed” message to a precise check list. Instead of guessing at certificate issues in general, you can prove or rule out specific causes by checking the claims in the token and the keys attached to your application.

Many reports of this message involve the on-behalf-of flow, where a backend API trades a user token from a client for a new token to call another API. In that pattern, the user assertion must target the middle tier API, not Microsoft Graph or some other audience, and the client assertion must match the app registration that represents that middle tier.

When you rely on MSAL or another library, you will often find that the stack logs extra hints around AADSTS50013. Inspecting verbose logs from the client side can reveal which certificate thumbprint the code picked, which authority it used, and which token endpoint it called. Pair that view with the Azure AD error text, and you get a full picture from both ends of the handshake. It helps you prove whether the problem sits on client or server side.

Step-By-Step Fixes To Clear AADSTS50013 During Sign-In

Once you know which Reason text you are dealing with, walk through these checks in order. Start in a test tenant or a non-production client so that you can capture traces without affecting users.

1. Confirm tenant clock sync — Check that the servers creating tokens and the machines running client libraries have accurate time, ideally via NTP, because large skew can break token signatures.
2. Decode the failing token — Use a local JWT viewer to decode the token that produced AADSTS50013 and record the header, iss, aud, iat, nbf, and exp claims.
3. Match the audience to your API — Confirm that the aud claim in the user assertion or access token matches the Application ID URI or api:// identifier configured for the API you are calling.
4. Check the issuer and tenant — Compare the iss claim with the authority you configured in MSAL or your library; they must point to the same tenant and policy.
5. Verify certificate upload and thumbprint — If the error mentions a thumbprint, open the app registration, check Certificates and secrets, and confirm that the thumbprint and validity dates line up with the failing trace.
6. Confirm private key availability — On the machine that signs client assertions, confirm that the certificate includes a private key and that the process account has permission to read it.
7. Recreate the client assertion — If you build a signed JWT for client_assertion, rebuild it with fresh iat and exp values, correct audience, and the certificate you just checked.
8. Check for Azure AD B2C limits — If the issuer shows a B2C authority and you are trying an on-behalf-of flow, pick another OAuth2 flow that the B2C tenant allows, because OBO is not wired to work there.

Understanding On-Behalf-Of Flows And AADSTS50013 Assertion Signature Errors

In an on-behalf-of flow, your web API receives a bearer token from a client and then asks Azure AD for another token to call a downstream API. The web API presents the original token as a user assertion, along with its own client credentials, and expects Azure AD to trade that package for a new access token.

AADSTS50013 shows up when one part of that triangle does not line up. The user token might be for Graph instead of your API, the client assertion might be signed with a certificate that Azure AD does not know about, or the authority in your library might target a different tenant from the one in the token.

When you read forum threads about this error, a small pattern repeats: the developer either passes the wrong token into the on-behalf-of call, sets the wrong audience on the downstream API, or leaves an old certificate in code while updating it in the portal.

For an on-behalf-of exchange to succeed, you need three elements to line up.

• Correct user assertion audience — The incoming user token must list your middle tier API as aud.
• Matching client credentials — The client assertion must be signed with the certificate or secret that belongs to the app registration for that API.
• Aligned authority and tenant — The authority used in MSAL must match the tenant that issued the user token.

Preventing AADSTS50013 Errors In Day-To-Day Operation

Once you have fixed the immediate problem, it helps to reduce the chances of seeing AADSTS50013 again. Most prevention work comes down to how you manage certificates, rotate secrets, and monitor token validation in your platform.

These habits keep signature validation steady over time.

• Plan certificate rotation ahead of expiry — Track certificate end dates and schedule changes well in advance, updating both the app registration and any local certificate store.
• Keep a single source of truth for keys — Avoid spreading signing certificates across many folders or machines; instead, centralise storage and document which apps use which certificate.
• Log claims and thumbprints during testing — In pre-production, log token iss, aud, iat, and the thumbprint that your code selects so you can compare them with Azure AD traces.
• Document audience values for every API — Store the exact Application ID URI or api:// entry for each protected resource in your design docs so developers do not guess when they request tokens.
• Add health checks for token validation — Build small internal endpoints that run a test on-behalf-of request or client credential flow and record whether signature checks pass.

When these habits are in place, AADSTS50013 tends to appear only when you change something on purpose, such as rotating certificates or adding a new API. That makes the trace much easier to reason about, because you can tie each failure back to a recent change.

When To Escalate AADSTS50013 To Microsoft

Most assertion validation errors resolve once you align certificates, audience values, and tenants. Now and then, though, the trace looks correct while Azure AD still returns AADSTS50013, especially in complex hybrid setups or when new features roll out.

Before you raise a ticket with Microsoft, gather a clean set of data: the full error text, correlation ID, timestamp, tenant ID, decoded token header and payload, and the set of certificate or secret credentials configured on the app registration.

You will save time on the case if you can also show that you have walked through these checks.

• Reproduced the error in a minimal app — Strip your sample down to the smallest client and API that still hit AADSTS50013.
• Captured HTTP traces — Use a tool such as Fiddler or your platform logging to capture the raw HTTP request and response where the token exchange fails.
• Confirmed tenant and authority alignment — Verified that the authority in code matches the issuer in the failing token and the tenant shown in the portal.
• Checked for known service issues — Look at the Azure status page and recent posts on Microsoft Q&A for any wider problem that mentions AADSTS50013.

By treating AADSTS50013 Assertion Failed Signature Validation as a precise signal rather than a vague warning, you can quickly map each failure to a small set of checks. That approach keeps your token handling predictable, cuts downtime during certificate or app changes, and helps every new team member reason about Azure AD errors with confidence.

Send us your feedbackTell us what you thought about this post

⚠Please use a real email you check. If it's fake or mistyped, your message won't reach us and we can't reply — wrong addresses are rejected automatically.

Name *Email *

Your comment *

Quick check — what is …? *

Send feedback