What is a JWT? JSON Web Tokens Explained

The decoded token. Header: {"alg":"ES256","typ":"JWT","kid":"stg-2026-09"}. Payload: iss https://auth.staging.bank.example, sub C-100482, aud accounts-api, iat and nbf both 1790748000 (30 September 2026, 06:00:00 UTC), exp 1790834400 (1 October 2026, 06:00:00 UTC), jti 7d2f0c9e-4b1a-4e8e-9a3d-5c6b2f1e8a40, scope accounts:read transfers:write, role customer, name Sara Al-Harbi, national_id 1234567890. The signature segment has 86 characters, which is 64 bytes: the size of an ES256 signature.

Summary: five defects (the lifetime, the personal data, the storage, the none algorithm in V3 and the unchecked audience in V6 and V7), three questions for the team (role, the leeway in V4 and, raised by V7, whether the API checks scope), and four rows where the API behaves correctly (V1, V2, V5, V8). Decoding needed no key at all, which is the guide’s central point: everything in the payload can be read by anyone who holds the token.

Header, iss, aud, sub, jti and scope — correct. alg is ES256 with a kid, as T1 requires, and iss and aud match T2. nbf equal to iat is normal: the token is valid from the moment it was issued. jti is what makes the denylist in T5 possible.

Lifetime — defect (T3). exp - iat is 86400 seconds, that is 24 hours instead of 600 seconds (10 minutes), so a leaked token can be used for a whole day instead of a few minutes. A general-purpose claims analyzer may call a 24-hour lifetime acceptable; here the test basis is T3, and T3 says 10 minutes. Severity major. Expected result: exp = iat + 600. After the fix, also check that a token is refused soon after its 10 minutes (plus the leeway from V4) and that the web app renews it with the refresh token without signing the customer out.

name and national_id — defect (T4). The payload is encoded, not encrypted: you have just read a national ID without any key, and so can anyone who sees the token in browser storage, a log, a proxy or a screenshot attached to a bug report. The token also travels with every request. Severity major; the bank’s data protection rules may rate it higher. Expected result: the payload holds only the claims T4 lists. This rule is about the access token; the ID token is meant for the web app and may carry the name (see the developer’s question).

role — question for the team. T4 does not list it, so either the specification is out of date or the claim should go. A role inside a signed token is not a security problem in itself, because the signature protects it, but only if the API verifies the signature with a pinned algorithm, and V3 shows that today it does not: with none, anyone can write any role.

Storage — defect (T6). The token sits in localStorage under the key access_token, where any script running on the page can read it, including a script injected through a cross-site scripting (XSS) bug. With a 24-hour lifetime, a stolen token keeps working for a day unless the customer signs out (V8 shows that signing out does revoke it). Severity major. Expected result: an HttpOnly, Secure, SameSite cookie. When the fix arrives, paste its Set-Cookie header into the Cookie Analyzer to confirm the three attributes, and check that localStorage no longer holds the token.

V1 — correct: 200 with the customer’s own accounts. V2 — correct: 401. Changing the payload breaks the signature, and the API notices. This is the difference between decoding and verifying: anyone can edit a decoded payload, but only the auth server’s private key can produce a signature that matches it.

V3 — defect, critical (T1, T7). Expected result: 401, because T1 allows ES256 only. The 200 with customer C-100483’s accounts is the failure; the defect behind it is that the API lets the token’s own header choose the algorithm, and with none it checks no signature at all. Together with V2 this shows that verification works when the header says ES256 and is switched off when the header asks for it. Anyone who knows or guesses a customer number can read that customer’s accounts, and can write any other claim too, such as a scope that includes transfers:write.

V4 — question. RFC 7519 allows a verifier a small leeway for clock differences between servers, usually no more than a few minutes, and T3 says nothing about it. V5 shows that exp is checked, so the leeway lies somewhere between 40 seconds and 15 minutes. Ask the team for the configured value and have it added to the specification; then test the boundary with two values: a token used just inside the leeway is accepted, and one used one second after it ends gets 401. If the leeway turns out to be longer than a few minutes, report it as a defect, because it extends the life of every token. V5 — correct: 401.

V6 — defect (T2). Expected result: 401, because aud is cards-api, not accounts-api. A token issued for one service opens another, so a token leaked from the Cards API, or from any service that receives such tokens, also opens customers’ accounts. V7 — defect with the same root cause: an ID token is meant for the web app, not for an API, and the guide says it must never be used as an access token. Report V6 and V7 together as one defect, "The Accounts API does not check aud", with both rows as examples; two reports would describe the same root cause twice. Severity major (some teams rate it critical). V7 also raises a question: the ID token has no scope at all and still returned the account list, so ask whether the API checks accounts:read, and add a test for it.

V8 — correct: 401 after sign-out, so the jti denylist from T5 works. It does not make a 24-hour lifetime harmless: a customer who never signs out leaves a token that stays valid for a day.

Verification tests the log does not contain yet (any three are enough): the header changed to HS256 and the token signed with an HMAC secret of your choice, for example in the JWT Generator, expected 401, and the API log should show that it was refused for its algorithm, because the server, not the header, must choose the algorithm; none in other letter case, such as None and NONE, after the fix, because a check that blocks only the exact string none can miss them; a token signed with your own ES256 key instead of the auth server’s, expected 401, because only keys from the JWKS may be trusted; a token from the development environment’s auth server (another iss and another key) and a token whose nbf lies in the future, both expected 401; an access token whose scope lacks accounts:read, expected a refusal (RFC 6750 recommends 403 for insufficient scope; confirm the code with the team); and the leeway boundary from V4. Tokens with chosen claims and a valid ES256 signature need the auth team’s help on staging, for example a test client that issues them; ask for it rather than skipping those tests.

The developer’s question: no for national_id, and not in this form for name. Personal data does not belong in the access token (T4). The ID token is the token meant for the web app and it already carries the customer’s name (see V7), so the page can show the name from the ID token or from an endpoint that returns the customer’s profile and permissions; national_id belongs in neither token. Reading the access token in JavaScript also works only because the token sits in localStorage: once it moves into an HttpOnly cookie as T6 requires, page scripts cannot read it at all, so the design has to change anyway. Hiding the Transfers menu is fine as a convenience, but it is not a security control: decoding is not verifying, so the API must check transfers:write on every transfer request. Add a test for that: a transfer request with a token whose scope has no transfers:write must be refused.

Report V3 first. Title, for example: "Accounts API accepts unsigned tokens with alg: none; changing sub returns another customer’s accounts". It comes first because it needs no stolen token and no key, only a customer number, and it exposes every customer’s accounts: severity critical, highest priority. Because it is a security defect, tell the developers straight away and follow your team’s process for security issues, for example a ticket with restricted access. Then the audience defect (V6 and V7); then the 24-hour lifetime and the storage in localStorage, which together decide how long and how easily a stolen token can be used; then the personal data in the payload. If your team ranks the national ID first because the bank’s data protection rules treat it as an incident, that is a sound reason; what matters is that the priority follows the impact. After each fix, rerun the affected rows as confirmation tests, and rerun V1, V2, V5 and V8 as regression tests, because a change in the verification code can break what works today.

To check your work: you should have five defects and none in V1, V2, V5 or V8. If you marked V2 as a defect, reread "Decoding is not verifying" in the guide: a 401 for an edited payload is exactly what a verifier must do. If you marked nbf equal to iat as a problem, reread the section on claims: nbf only bounds when the token became valid.