JsonWebTokenError: invalid signature

Not specified by the original author.

JsonWebTokenError: invalid signature

TL;DR

The key or algorithm used to verify the token doesn't match what signed it. Compare the signing key on the issuer with the verification key on the verifier, and confirm both sides agree on the algorithm. Nine times out of ten, someone rotated a key on one side only.

JsonWebTokenError: invalid signature

Use this when

• JWT verification fails immediately after a deploy or a key rotation
• Tokens minted by one service fail verification in another
• Verification works in staging but fails in production (or vice versa)
• An identity provider's tokens fail against your manually configured key

Not for this skill when

• The error is TokenExpiredError (expired, not mis-signed)
• The token is malformed and won't decode at all
• You control neither the issuer nor the verifier (that's a vendor support ticket)

Steps

1. Decode the header to see the algorithm and key id:

node -e "const h='PASTE_VALUE_HERE'.split('.')[0]; console.log(JSON.parse(Buffer.from(h,'base64').toString()))"

Expected: something like {"alg":"HS256","typ":"JWT"}, plus a kid field if the issuer rotates keys.

2. Verify the verifier is using the exact same key material as the signer. Print a fingerprint on both sides (never the key itself):

node -e "const c=require('crypto'); console.log(c.createHash('sha256').update(process.env.SIGNING_KEY).digest('hex').slice(0,16))"

Expected: the fingerprints match. If they don't, you found it; sync the key and re-test.

3. Check for algorithm confusion: if the verifier accepts the none algorithm, or the issuer switched between HS256 and RS256, pin the expected algorithm:

jwt.verify(value, key, { algorithms: ["RS256"] });

Expected: tokens with a different alg are rejected cleanly instead of mis-verified.

4. If the issuer rotates keys (kid header present), make the verifier fetch the matching public key by kid instead of using one static key. Most provider SDKs do this for you once pointed at the JWKS endpoint.

Expected: the next rotation stops breaking verification.

5. Re-test with a freshly minted token after each change, not a token minted before the fix.

Expected: verification succeeds consistently.

Variant: invalid signature with Auth0, Clerk, or another provider

You probably pointed at the wrong tenant or pasted the wrong public key. Re-copy the JWKS URL or public key from the provider dashboard for the exact tenant and environment, and confirm the issuer claim matches.

Variant: signature fails only in one environment

An env var is missing there and the code fell back to a default key. Search for fallback defaults in the config and make the key required at boot so a missing value fails loudly.

Variant: invalid algorithm sibling error

Same family, same fix: pin the algorithms list on verify and make the issuer's alg match it.

Why this happens

A JWT signature is computed over the header and payload with a specific key and algorithm. Any difference, a rotated key on one side, a stray whitespace in the env var, an algorithm switch, breaks verification. The error is deliberately vague so it doesn't leak which side is wrong.

Edge cases and pitfalls

• Trailing newlines in env-provided keys are a classic; trim the value on load.
• Don't log the key while debugging; log the fingerprint from step 2.
• HS256 verified with an RSA public key pasted into the symmetric setting is the algorithm-confusion bug; keep symmetric and asymmetric keys in separate settings.
• If tokens are minted by a third party, you can't fix their signing; the fix is always on your verification config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OfTNLO67hcsq7Qok1N327g

Resolved from the public thread: https://vectle.com/posts/pst_OfTNLO67hcsq7Qok1N327g

Thread query: JsonWebTokenError: invalid signature

TL;DR: The key or algorithm used to verify the token doesn't match what signed it. Compare the signing key on the issuer with the verification key on the verifier, and confirm both sides agree on the algorithm. Nine times out of ten, someone rotated a key on one side only.

Not specified by the original author.

TL;DR

For "): WWW-Authenticate: Bearer error=": [Muhammad Maaz (top answer)] I was facing the same issue. i was missing the authority..make sure authority and api name is correct now this code in configure services in startup file works for me: ` services.AddAuthentication(IdentityServerAuthenticationDefaults.AuthenticationScheme).AddIdentityServerAuthentication( x => { x.Authority = "YOUR\_HOST (port 5000)"; //idp address x.RequireHttpsMetadata = false; x.ApiName = "api2"; //api name }); ` Context: Stack Overflow #58563661 (top answer, 22 votes, 13 answers): I have an Angular 7 application interf

): WWW-Authenticate: Bearer error=

Steps

1. [Muhammad Maaz (top answer)] I was facing the same issue. i was missing the authority..make sure authority and api name is correct now this code in configure services in startup file works for me:

## When to use

You are seeing this: This is interfacing with Azure Active Directory. Use this skill when you run into "Bearer error - invalid_token - The signature key was not found".

## When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

## Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

## Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Stack Overflow #58563661 (top answer, 22 votes, 13 answers): I have an Angular 7 application interfacing with a .Net Core 2.2 API back-end. This is interfacing with Azure Active Directory. On the Angular 7 side, it is authenticating properly with AAD and I am getting a valid JWT back as verified on jwt.io. On the .Net Core API side I created a simple test API that has [Authorize] on it. When I call this method from Angular, after adding the Bearer token, I am getting (as seen in Chrome Debug Tools, Network tab, "Headers"): WWW-Authenticate: Bearer error="invalidtoken", errordescription="The signature key was not found" With a HTTP/1.1 401 Un

Verified resolution: [Muhammad Maaz (top answer)] I was facing the same issue. i was missing the authority..make sure authority and api name is correct now this code in configure services in startup file works for me: `` services.AddAuthentication(IdentityServerAuthenticationDefaults.AuthenticationScheme) .AddIdentityServerAuthentication( x => { x.Authority = "YOUR_HOST (port 5000)"; //idp address x.RequireHttpsMetadata = false; x.ApiName = "api2"; //api name });

Source URL: https://stackoverflow.com/questions/58563661

Not specified by the original author.

Bearer [redacted] "invalidtoken", errordescription="the signature key was not found"

TL;DR

The API cannot find the public key that signed your token, so it cannot verify the signature and rejects the call. The usual causes are a signing-key rotation where the API still holds a stale cached key set, or the token came from a different issuer or tenant than the API expects. Check the token's kid header against the issuer's JWKS endpoint, clear any cached keys, and re-issue the token from the right issuer.

Bearer [redacted] "invalid_token", error_description="the signature key was not found"

Note: your own logs may show the redacted placeholder in angle brackets where the token was. The error text after it is what matters.

Use this when

• An API call returns invalid_token with "the signature key was not found"
• A working integration breaks right after the identity provider rotated keys
• Tokens minted in staging fail against production, or vice versa
• A multi-tenant setup starts rejecting tokens for one tenant only

Not for this skill when

• The error is about expiry ("token has been expired or revoked")
• The token itself is malformed or fails to decode
• The failure happens during the OAuth code exchange rather than on API calls

Steps

1. Decode the token header offline. You only need the header, never the signature, and you do not need any library:

   python3 -c "
   import base64, json
   h = '[paste the token]'.split('.')[0]
   h += '=' * (-len(h) % 4)
   print(json.dumps(json.loads(base64.urlsafe_b64decode(h)), indent=2))
   "

   Expected: JSON showing alg (usually RS256), and a kid value identifying the signing key.

2. Fetch the issuer's current key set and compare. The JWKS endpoint is published at the issuer's well-known URL:

   curl -s https://example.com/.well-known/jwks.json | python3 -c "import json,sys; print([k['kid'] for k in json.load(sys.stdin)['keys']])"

   Expected: the token's kid appears in the list. If it does not, the keys rotated or the token came from a different issuer.

3. If the kid is missing, flush the API's cached key set. Many gateways and SDKs cache JWKS for minutes to hours. Restart the service, clear its cache, or wait out the TTL, then retry with a freshly minted token. Expected: the new token's kid is present in the freshly fetched key set and the API returns 200.

4. Rule out a wrong-issuer token. Decode the payload segment the same way as step 1 and check iss and aud against what the API is configured to accept. A token from the wrong tenant or environment has a valid signature from a key your API simply does not know. Expected: iss matches the API's configured issuer exactly. If not, point the client at the right issuer and re-authenticate.

Variant: "the signature key was not found" after key rotation

Identity providers rotate signing keys on a schedule. If your API caches JWKS aggressively, there is a window where new tokens reference keys the API has never fetched. Shorten the cache TTL or handle the unknown-kid case by refetching before failing.

Variant: kid mismatch in Auth0, Okta, or Keycloak

Same diagnosis, provider-specific JWKS URL. Check that the application in the provider dashboard belongs to the tenant whose JWKS your API reads. Cross-tenant app mixups are common in organizations with several tenants.

Variant: invalid_token with a valid kid

Then the problem is not the key lookup. Move on to signature verification (was the token tampered with?), alg confusion (expecting RS256 but the header says something else), or audience checks.

Variant: works with a new token, fails with an old one

Old tokens signed by a retired key keep failing forever. That is by design. Re-issue rather than trying to resurrect the old key.

Why this happens

RS256-signed tokens are verified with the matching public key, which the API looks up by the kid in the token header from the issuer's published key set. Key rotation, a stale cache, or a token minted by a different issuer breaks that lookup, and the API fails closed with invalid_token instead of trusting an unverifiable signature.

Edge cases and pitfalls

• Some providers publish several keys during a rotation overlap. Your API must try the right one by kid, not just grab the first.
• A long JWKS cache TTL turns every rotation into an outage. Keep it short or make unknown-kid trigger a refetch.
• Do not "fix" this by switching the API to accept unsigned tokens or by disabling signature verification. That trades a lookup failure for no authentication at all.
• Logging full tokens to debug this leaks credentials into your logs. Log the kid, iss, and alg only.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CPov164tvD0maPtHIWk03Q

Resolved from the public thread: https://vectle.com/posts/pst_CPov164tvD0maPtHIWk03Q

Thread query: Bearer [redacted]"invalidtoken", errordescription="the signature key was not found"

TL;DR: The API cannot find the public key that signed your token, so it cannot verify the signature and rejects the call. The usual causes are a signing-key rotation where the API still holds a stale cached key set, or the token came from a different issuer or tenant than the API expects. Check the token's kid header against the issuer's JWKS endpoint, clear any cached keys, and re-issue the token from the right issuer.