How to Verify access tokens on your backend
Your frontend sends the user's access token to your API asAuthorization: Bearer <token>. Your API verifies it locally against our public keys — no shared secret and no call to AuthJet per request.
You need three values
- JWKS URL
https://api.authjet.dev/.well-known/jwks.json- Issuer
https://api.authjet.dev- Audience — your account id
- Shown in the dashboard under Account Settings → Account details → Account ID, with a copy button.
What to check
SignatureRS256 only, using the JWKS key whose kid matches the token header. Never accept HS256 or none.issMust equal https://api.authjet.dev.audMust equal your account id. This is what stops a token issued for another AuthJet customer's tenant from working on your API — skipping it is a security bug.expMust be in the future. Access tokens live 30 minutes; the SDK refreshes them for you.typeMust be "access".
Any standard JWT library does all of this when given the right options — pick your language below.
Code samples
Each sample verifies a token and returns its claims. Replace<your-account-id> with your account id.
Claims
sub | User id. The literal "platform" during an AuthJet support session with no specific user. |
tenant_id | The tenant the user signed in to — scope your own data by this. |
aud | Your account id. |
email | The user's email, when known. |
app_role / app_permissions | The app role and permissions you defined for this user. |
platform_impersonation | true when AuthJet support staff are acting in your tenant. Log it; decide whether your API allows it. |
exp / iat / jti | Expiry, issued-at, unique token id. |
Key rotation
We rotate signing keys periodically. The JWKS always lists the active key and, for a while after a rotation, the previous one. Both libraries above refetch the JWKS when they see an unknownkid, so rotations need nothing from you. Don't hard-code a key — always load it from the JWKS URL.
AuthJet