YanoSec
Progress0 of 152 lessons complete

Course / 09 Web security / Lesson 27 of 28

JWT

Estimated time: 18 min reading · 12 min activity

A service may receive a token containing claims, which are named statements such as who issued it and which service it is intended for. JSON Web Token, or JWT, defines a compact way to carry those claims. A common signed form has header, payload and signature parts separated by periods; encrypted JWT representations differ.

The payload can be readable without being trustworthy. Decoding converts representation; verification checks the cryptographic protection under the service's policy. iss names the issuer and aud the intended audience. The notes model requires a verified signature, issuer lab and audience notes. All three conditions must hold before it accepts a token.

Before you begin

Estimated time
18 min reading, 12 min activity. Setup and optional practice may take longer.
Where you work
Read the original fictional source, object tables, token claims and policy models in any current desktop or mobile browser. No loader, template engine, provider registration, service or network request is required.
Without a lab
Follow the printed data through each stated rule on paper. Record the decision, its supporting fact and a limit, then compare with the guided rubric. Model reasoning does not establish a live tool result. Reading works without JavaScript. Checking requires JavaScript and a secure context; saving also requires usable storage.

After this lesson you can:

  • Separate decoding a claims set from checking a signature.
  • Withhold the activity token because its signature was not checked.
  • Apply iss and aud as further conditions when the signature does hold.

01Example

Worked claims iss lab, aud notes, role member, signature not checked. The activity claims add role admin and the same unchecked signature.

Worked claims: iss lab, aud notes, role member
Card mark: signature not checked
A readable set is not a verified signature.

02Three conditions

The worked claims say role member, but the signature mark is unchecked. The activity changes the role claim to admin without establishing a verified signature. A stronger-looking claim does not supply the missing verification. The folder contains readable synthetic claims, not a real compact token or a computed signature.

Even successful signature verification does not establish that the token belongs to this service or is currently valid. Real validation should constrain accepted algorithms and keys and enforce the relevant issuer, audience, time and application rules. The simplified policy prints only three conditions. An unsecured alg none token must not be accepted as signed proof under that policy.

Separate readable token claims from cryptographic verification and the service's acceptance policy.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

The claims are readableThe signature and policy are verified

Readable claims

Worked claims: iss lab, aud notes, role member
Selected evidence · Original fictional teaching evidence

Explicit check status

Card mark: signature not checked
Source evidence · Original fictional teaching evidence
supported

The claims are readable

The authored claims line can be read directly.

Readable is not verified.

Original fictional teaching evidence

The authored claims line can be read directly. Readable is not verified.

Follow the explanation

  1. The authored claims line can be read directly. Readable is not verified.
  2. The card explicitly marks the signature unchecked; policy checks are not supplied. No real token was validated.
Read every state and value

1. The authored claims line can be read directly. Readable is not verified.

Evidence selected
Readable claims
Current claim
read
Source origins
Original fictional teaching evidence

2. The card explicitly marks the signature unchecked; policy checks are not supplied. No real token was validated.

Evidence selected
Readable claims · Explicit check status
Current claim
verify
Source origins
Original fictional teaching evidence
Readable claims are not cryptographic verification; do not grant access from a role label.

03Read the activity mark

Read the evidence before comparing with the activity rubric. Do not decode a live token.

Claims sets. No signature was computed. Decoding was not required.

Worked
{"iss":"lab","aud":"notes","role":"member"}
Card mark: signature not checked

Activity
{"iss":"lab","aud":"notes","role":"admin"}
Card mark: signature not checked

A common signed compact form has three period-separated parts. Encrypted forms differ. This file contains only readable claims, not either compact form.
A readable claims set is not a verified signature.

Download the claims sets

Notes service policy.

Accept only when all of these hold:
  the signature checks under the service's allowed algorithm
  iss is lab
  aud is notes

RFC 7519 section 4.1.3: when aud is present, each principal intended to process the JWT must identify itself with a value in aud. If it does not, the token is not for that principal.

Download the notes policy

  1. Write the activity claims and the card mark beside them.
  2. Write the three conditions on the policy card.
  3. Check: the signature was not checked, so the notes service does not take the activity token. The role name admin does not replace the mark.
  4. Stop. Do not use a real token.

04Optional challenge

Name two further reasons a claims set can fail after a signature check, using only the policy lines. The rubric is: iss is not lab, or aud is not notes. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Claims case A: new synthetic readable dataOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

{"iss":"training","aud":"ledger","role":"admin"}
Evidence mark: decoded text only; signature not checked.
These are readable synthetic claims, not a compact token or computed signature.

Claims case B: independent policy rowsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Simplified ledger policy: signature checks under allowed algorithm/key, iss=training and aud=ledger are all required.
P: signature verified; iss=training; aud=ledger.
Q: signature verified; iss=other; aud=ledger.
R: signature verified; iss=training; aud=archive.
Other real token validation conditions are outside this simplified three-condition exercise.

Claims case C: independent incomplete procedureOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Procedure reads iss and aud, finds expected values, then trusts the claims.
It never checks a signature under the service’s allowed algorithm and key.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: distinguish readable claims from validated evidence; test signature, issuer and audience independently; identify the missing constrained verification; keep the simplified exercise separate from complete real-token validation.

07Common mistakes

If you accept the activity token because you can read role admin, you skipped the signature mark.

If you look for a compact three-part string, the file says it does not contain one.

If you treat alg none as proof, the opening says an empty signature is not proof.

References

  • RFC 7519: JSON Web Token (JWT)

    Sections 3–4 distinguish token representation and registered claims; section 4.1.3 defines audience processing.

  • PortSwigger: JWT

    Further explanation of this mechanism and its defenses. The original printed model supplies the required evidence.