AADSTS5002730: Unsupported key for the JWT signing algorithm (fix)

What does AADSTS5002730 mean?

Microsoft’s error code reference doesn’t list AADSTS5002730 (checked 30 October 2026). The closest listed code is AADSTS50027, InvalidJwtToken.

Microsoft’s MSAL.NET team describes it in the 4.60.1 release notes. The fix addressed:

an issue where attempts to acquire a token via certificate authentication resulted in a Microsoft.Identity.Client.MsalServiceException (Error code: AADSTS5002730), signaling an “Invalid JWT token. Unsupported key for the signing algorithm.” This was due to a known bug in Microsoft Entra ID (Azure AD) that affects the handling of JWT tokens signed with certain algorithms, specifically SHA2 and PSS.

The bug report behind it, MSAL.NET issue 4690, shows the full message:

AADSTS5002730: Invalid JWT token. Unsupported key for the signing algorithm.

That report used a confidential client with a PEM certificate and AcquireTokenForClient, on MSAL.NET 4.60.0. A maintainer said a partner team’s first look suggested “an external issue (AAD)”. The workaround in the thread was to stay on 4.59.0.

So the documented trigger is a client assertion: the signed JWT an app sends instead of a client secret when it signs in with a certificate. Microsoft’s certificate credentials page now says the assertion’s alg “Should be PS256” and to “Use PSS padding.” Our reading: the 4.60.0 failure was on the Entra side, and PS256 itself is the recommended algorithm. Microsoft doesn’t say whether or when the Entra bug was fixed.

A second trigger comes from a user report. A user on Microsoft Q&A got the same message in an on-behalf-of (OBO) exchange from a Teams tab app. The user believed the token they exchanged was signed with HS256. They said the same code got an RS256 token in another tenant. A volunteer moderator, an MVP and not Microsoft staff, answered with “I think”: such a token can’t be exchanged, and an Entra-issued token is needed. Our reading: here the JWT is the incoming user token, not a client assertion, and HS256 is a shared-secret algorithm that Entra doesn’t accept for it.

Is it an attack?

Not on the evidence available. Both reports are apps with a signing or library problem.

Pattern	Likely meaning
A service or daemon fails right after a library upgrade	The MSAL.NET 4.60.0 case. Upgrade to 4.60.1 or later.
One app fails, others with certificates work	Probably the app builds its own client assertion with an alg that doesn’t match its key (unconfirmed).
An OBO call fails in a Teams or custom app	The incoming token isn’t an Entra-issued, RS256-signed token. Users report this.
Your app IDs, from IPs you don’t recognise	We found no report of this. Possibly someone sending hand-built assertions for your app. Check the app’s credentials and sign-ins.

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

Microsoft doesn’t document which sign-in table AADSTS5002730 is logged in. Our reading: the certificate case is an app signing in as itself, so AADServicePrincipalSignInLogs is the likely table; the OBO case involves a user, so it may land in a user table. Check all three:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "5002730"
| summarize Rows = count(), LastSeen = max(TimeGenerated) by SourceTable, AppId

For apps signing in as themselves, see which credential was used:

AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "5002730"
| summarize Rows = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), IPs = make_set(IPAddress, 20)
    by AppId, ServicePrincipalName, ClientCredentialType, ServicePrincipalCredentialThumbprint
| sort by Rows desc

If FirstSeen lines up with a deployment, check which MSAL version that deployment shipped.

How do I fix AADSTS5002730?

For developers:

1. On MSAL.NET 4.60.0, upgrade to 4.60.1 or later. The release notes say 4.60.1 addressed this error.
2. If you build the client assertion yourself, follow Microsoft’s certificate credentials page: alg PS256, typ JWT, a x5t#S256 thumbprint header, PSS padding.
3. For OBO, exchange an Entra-issued access token for your API. Don’t pass a token signed with a shared secret (HS256). The Q&A answer recommends the Teams SSO flow or MSAL to get it.

For admins:

1. Use the second query to find the app and certificate thumbprint. Give them to the app’s owner.
2. Ask the owner which MSAL version and signing settings the app uses. Nothing in Entra needs changing for the MSAL.NET case.