401 from verifyToken even though the user is signed in: JWKS key or jwtKey mismatch

TL;DR: Your backend rejects a session token the frontend just minted. The usual cause is a stale or wrong JWKS public key, not a broken session. Confirm the cause 1. Decode the token header (base64, no verification needed) and compare its kid to the key your backend uses.

The fix

1. Figure out which verifier you call. authenticateRequest is networkless only when you pass jwtKey (the JWKS public key from the dashboard). Without it, the SDK makes a network call to fetch the JWKS; blocked egress or a stale cache then looks like a bad token.
2. If you pass jwtKey, confirm it is the CURRENT public key for THIS instance. Keys copied long ago, or copied from a different instance, fail signature verification silently.
3. Decode the token header (base64, no verification needed) and compare its kid to the key your backend uses. A mismatch after a key rotation is the classic cause.
4. Make sure you are not verifying a JWT-template token as a session token (or the reverse). Template tokens carry different claims and issuers.
5. Re-copy the JWKS public key from the dashboard into your jwtKey config and redeploy.
6. If you fetch the JWKS over the network, clear the cached keys and let the SDK refetch.
7. Always pass authorizedParties with your real origins alongside the key (see the azp skill).

When to use this

• This covers exactly what the title says: 401 from verifyToken even though the user is signed in.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with 401; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current 401 behavior.

Verified against Clerk's verifyToken and authenticateRequest reference docs 2026-09-26: verifyToken takes a jwtKey for networkless verification; authenticateRequest is networkless only when jwtKey is provided, otherwise it performs a network call to retrieve the JWKS from the Backend API. Session tokens are short-lived and auto-refreshed by Clerk's frontend.