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

Canonical: https://brambrinkmeier.com/entra/aadsts/5002730/
By Bram Brinkmeier. JSON: https://brambrinkmeier.com/api/aadsts/5002730.json

**Short answer:** AADSTS5002730 means Entra rejected a JWT because its signing algorithm doesn't fit the key. Microsoft doesn't list the code. The MSAL.NET 4.60.1 release notes tie it to certificate sign-in with SHA2 and PSS signing and an Entra bug; the fix was to upgrade MSAL.NET. Users also report it for OBO with an HS256 token. Low attack value.

**Fix:** Developer: on MSAL.NET 4.60.0, upgrade to 4.60.1 or later. If you build the client assertion yourself, use `alg` PS256 with PSS padding and a `x5t#S256` header. For OBO, exchange an Entra-issued access token, not an HS256 token. Admin: nothing to change in Entra; tell the app owner.

| Field | Value |
|---|---|
| Code | AADSTS5002730 |
| Category | App configuration |
| Type | Configuration error |
| Attack signal | Low: usually configuration or user error |
| In Microsoft's error reference | No (checked 2026-10-30) |
| Verification | documentation |
| Last updated | 2026-10-30 |

## What does AADSTS5002730 mean?

Microsoft's [error code reference](https://learn.microsoft.com/entra/identity-platform/reference-error-codes) 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](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/releases/tag/4.60.1). 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](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/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:

```kusto
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:

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

## Evidence

Not in Microsoft's error reference and not reproduced in the lab; built from lab results, other Microsoft pages and user reports, which the page names.

## Sources

1. [Microsoft Entra authentication and authorization error codes](https://learn.microsoft.com/entra/identity-platform/reference-error-codes)
2. [MSAL.NET release 4.60.1 (GitHub)](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/releases/tag/4.60.1)
3. [[Bug] Using the SHA2 feature will cause the following errors (MSAL.NET issue 4690)](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/4690)
4. [Invalid JWT token. Unsupported key for the signing algorithm (Microsoft Q&A)](https://learn.microsoft.com/en-us/answers/a/2062046)
5. [Microsoft identity platform application authentication certificate credentials](https://learn.microsoft.com/entra/identity-platform/certificate-credentials)
6. [AADServicePrincipalSignInLogs table reference (Azure Monitor)](https://docs.azure.cn/en-us/azure-monitor/reference/tables/AADServicePrincipalSignInLogs)

## Related codes

[AADSTS7000218](https://brambrinkmeier.com/entra/aadsts/7000218/), [AADSTS7000215](https://brambrinkmeier.com/entra/aadsts/7000215/), [AADSTS7000222](https://brambrinkmeier.com/entra/aadsts/7000222/), [AADSTS700016](https://brambrinkmeier.com/entra/aadsts/700016/)

## License and citation

CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.

Cite as: Bram Brinkmeier, "AADSTS5002730: Unsupported key for the JWT signing algorithm (fix)", https://brambrinkmeier.com/entra/aadsts/5002730/ (CC BY 4.0), last updated 2026-10-30.