GUIDE 08 · WEB APPLICATIONS AND APIs
JWT security: validate tokens and access lifecycle
Decoding a JWT does not verify it. The server checks the signature using trusted keys, an allowed algorithm, expected claims and time constraints, then separately authorizes the requested action. Use a synthetic issuer and test tokens; this page does not collect production JWTs.
Prepare JWT scenariosSign-in, ownership verification and consent are required. Authorized scenarios, monitoring and CI require Pro or Business.
On this page
Decoding, verification and authorization
Decoding reads claims. Signature verification establishes integrity under the configured trust model. Authorization decides what that identity may do. A role claim visible in a decoder is not itself a permission grant, and a normally signed JWT is not encrypted merely because it has a signature.
Configure expectations on the server
Define permitted algorithms, trusted keys, issuer, audience, token purpose and time policy. Do not derive a trusted key URL solely from unverified token input. Required claims depend on your protocol; the supplied PyJWT example explicitly requires exp, iss, aud and sub for its synthetic issuer.
claims = jwt.decode(token, key, algorithms=["HS256"],
audience="api-a", issuer="https://issuer.example",
options={"require": ["exp", "iss", "aud", "sub"]})Primary sources: Primary reference 1 · Primary reference 2
Run negative controls
Test the correct token, wrong audience, wrong issuer, expiry, missing required expiry, an invalid signature and a missing token. Add a correct token requesting another owner’s object. The downloadable local example uses a randomly generated key, prints no token and asserts its expected outcomes.
| Test | Expected outcome |
|---|---|
| Valid signature and claims | Accept, then authorize the object |
| Wrong audience | Reject |
| Wrong issuer | Reject |
| Expired token | Reject |
| Required exp missing | Reject |
| Invalid signature | Reject |
| Missing token | Reject |
| Valid token, foreign object | Deny through object authorization |
Handle rotation and verification failures
Define how approved keys are selected and rotated and how unknown keys or issuer outages behave. A failed or unavailable verification service must not silently grant access. Record sanitized error categories without writing raw bearer tokens into analytics, logs or support screenshots.
Primary sources: Primary reference 1 · Primary reference 2
Continue: IDOR and BOLA: test access to another user’s data
Prepare JWT scenariosReview logout, revocation and role changes
A signed token can remain cryptographically valid after a user signs out or loses a role. The intended session and revocation policy must account for lifetime, refresh behavior and server-side state. Test the application’s actual policy; the small local example does not simulate every session lifecycle.
Keep token handling appropriate to the client
Choose storage and transport according to your threat model and platform. Avoid tokens in public URLs, analytics and shared examples. Cookie-based sessions need appropriate cookie attributes and CSRF defenses; bearer tokens still require careful handling and server-side permission checks.
Primary sources: Primary reference 1 · Primary reference 2
Continue: Exposed .env, .git or API keys: contain the leak and verify the fix
A valid JWT does not prevent IDOR
Even a correctly verified user token must be checked against the requested object, organization and role. Reuse the two-account access matrix and positive controls from the IDOR guide. Do not mark object access safe simply because signature validation succeeds.
Repeat after changes
Keep expected claims, test identities, token lifetime rules and fixture objects documented. Scantelio’s supported JWT observations depend on the supplied configuration; do not assume every issuer or audience condition was checked without the necessary inputs. Retest both rejected tokens and a legitimate user flow after fixes.
Reproducible examples and downloads
All example data is synthetic. Downloads contain no active keys or customer records. Run examples only in your own isolated test environment.
Example verification record: versions, actions and observations
Questions and answers
Does decoding validate the token?
No. Verification and authorization are separate steps.
Are JWT claims confidential?
A normally signed JWT is not encrypted by its signature. Do not assume its payload is secret.
Should every application require the same claims?
No. Define a policy appropriate to your protocol, then enforce it explicitly.
Does logout invalidate every issued JWT?
That depends on the application’s lifetime and revocation design; test the actual policy.
Does a valid token prevent cross-user access?
No. Object and tenant permissions still need server-side enforcement.
Can a scanner check claims without expectations?
Some observations are possible, but missing expected claims limit the conclusion.
Editorial team and sources
Scantelio editorial team: methodology and limitations. Example verified: 2026-11-02.
Apply the check to your own project
Prepare JWT scenariosChoose your project after signing in. No scan runs without verification and consent.