AADSTS50013 fix: invalid assertion in on-behalf-of flow

What does AADSTS50013 mean?

Microsoft’s description:

InvalidAssertion: Assertion is invalid because of various reasons - The token issuer doesn’t match the API version within its valid time range -expired -malformed - Refresh token in the assertion isn’t a primary refresh token. Contact the app developer.

An assertion is a token that an app hands to Entra ID as proof of something, and Entra ID refused it. The error comes back as invalid_grant, which Microsoft describes as “some of the authentication material (auth code, refresh token, access token, PKCE challenge) was invalid, unparseable, missing, or otherwise unusable”.

Most user reports of 50013 come from the on-behalf-of (OBO) flow. A client calls your API with an access token. Your API sends that token to Entra ID in the assertion parameter and asks for a new token to call another API, often Microsoft Graph. Microsoft’s OBO reference sets the rule for that token: “This token must have an audience (aud) claim of the app making this OBO request (the app denoted by the client-id field). Applications can’t redeem a token for a different app (for example, if a client sends an API a token meant for Microsoft Graph, the API can’t redeem it using OBO. It should instead reject the token.”

The message usually carries a reason in brackets. The ones users post:

• “Assertion failed signature validation. [Reason - Key was found, but use of the key to verify the signature failed.]”
• “Assertion failed signature validation. [Reason - The key was not found.]”

Microsoft doesn’t map these reasons to causes. See the table below for what users found.

Don’t confuse it with 700024. That code is about the client assertion, the signed JWT an app uses to prove its own identity. 50013 is about the assertion being exchanged, in OBO the user’s token.

Is it an attack?

Usually not. It is a developer error in how the app passes tokens around. Microsoft’s own text ends with “Contact the app developer.”

Pattern	Likely meaning
“Key was found, but use of the key to verify the signature failed”, from a backend calling Graph via OBO	The client sent the API a Microsoft Graph token and the API tried to exchange it. In one Q&A thread the frontend requested Graph scopes and the backend passed that token on; the cause wasn’t confirmed there. Microsoft says Graph tokens have a “proprietary format” and can’t be validated like other tokens; our reading is that this is why the signature check fails.
“The key was not found”, and the token’s kid only appears in metadata fetched with ?appid=	The middle-tier app has a custom signing key. A user reports exactly this. Microsoft: “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.”
50013 that mentions expiry	The client passed an expired access token. Get a fresh one before calling the API.
50013 for one app, starting right after a release	The new version changed which scope the client requests.
50013 from an unfamiliar IP for an app you own, with no successes	Someone is sending tokens your app didn’t issue to the token endpoint. Our interpretation: a forged or tampered token would also fail signature validation and land here. Not documented by Microsoft, but worth a look.

A token with a bad signature gets nothing from Entra ID, so the failure itself grants no access.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table an OBO failure lands in. OBO is a sign-in “performed by a client app or OS components on behalf of a user”, which fits the non-interactive log, but we haven’t checked. Look in all three:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50013"
| summarize Rows = count(), Apps = dcount(AppId) by SourceTable

Which app fails, for which downstream API, and with which reason. We assume ResultDescription carries the bracketed reason; Microsoft documents it only as “the error message or the reason for failure”:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "50013"
| extend Reason = extract(@"Reason - ([^\]]+)", 1, ResultDescription)
| summarize Rows = count(), Users = dcount(UserPrincipalName), FirstSeen = min(TimeGenerated)
          by AppDisplayName, AppId, ResourceDisplayName, Reason
| sort by Rows desc

50013 for apps that had no successful sign-in in the last 14 days. A starting point for spotting tokens sent to an app from somewhere it doesn’t normally run; tune the window to your tenant:

let failing =
    union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50013"
    | summarize Fails = count(), IPs = make_set(IPAddress, 10) by AppId, AppDisplayName;
let working =
    union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
    | where TimeGenerated > ago(14d)
    | where ResultType == "0"
    | distinct AppId;
failing
| join kind=leftanti working on AppId
| sort by Fails desc

ResultType is a string column, so compare it with "50013", not 50013. Non-interactive rows are aggregated when application, user, IP address, status and resource match, so row counts there are not request counts.

How do I fix AADSTS50013?

For the user: you can’t fix this yourself. Report the error, with the time and the Correlation ID, to whoever runs the app.

For developers:

1. Decode the token you pass as assertion (Microsoft names jwt.ms for debugging only). Its aud must be your API’s client ID or App ID URI. If it points at Microsoft Graph (https://graph.microsoft.com), the client asked for the wrong token.
2. Expose a scope on your API (App registrations > your API > Expose an API) and have the client request that scope, for example api://<api-client-id>/access_as_user. The accepted Q&A answer gives these steps; the scope name is your choice.
3. If your API receives a token whose audience is Microsoft Graph rather than your API, reject it. Microsoft’s OBO reference says exactly that: the API “should instead reject the token”. The fix is on the client side: have it request a token for your API’s own scope.
4. Check the middle-tier app has no custom signing key (claims mapping, or an enterprise app configured for SAML SSO). Microsoft says those apps can’t be OBO middle tiers. Use a separate app registration for the API.
5. Send a fresh, unexpired access token. Don’t cache and replay an old one.
6. Set requested_token_use to on_behalf_of, as Microsoft requires.

For admins:

1. Use the second query to find the app and the reason, and send both to the app’s owner.
2. If an enterprise app with SAML SSO is also used as an API, that is the custom-signing-key case above. The fix is a separate app registration, not a setting.