← Lessons/Anatomy of a JWT
← Anatomy of a JWT

What the signature protects

Learn

Anyone can read it. Nobody can change it.

You decoded every claim without a key. A standard JWT is signed, not encrypted, so:

  • never put passwords, API keys or sensitive personal data in a payload. Assume everyone who sees the token (browser extensions, logs, proxies) reads it;
  • the signature's job is integrity. Change one character of the payload (say "role":"support" → "role":"admin") and the signature no longer matches, so the API rejects it.

That's also why the API must actually verify the signature and check exp, aud and iss before trusting a single claim. Skipping or botching that check is the root of most JWT vulnerabilities. You'll exploit several of them later in this course.

This step isn't a command: answer the questions below.

You just read every claim without any key. Answer the questions below.

What does a JWT's signature guarantee?
What should never go in a JWT payload?
Sign in to check your answers

Interview prep

JWT questions are standard for backend, platform and security roles. Show you know a JWT is signed, not encrypted.

What are the three parts of a JWT?

Three base64url segments separated by dots: the header (JSON with alg, usually typ, and often kid), the payload (JSON claims such as sub, exp and aud), and the signature over base64url(header) + '.' + base64url(payload). The header and payload are only encoded, so anyone can read them. The signature makes them tamper-evident.

Is the data in a JWT secret?

No. A standard JWT (a JWS) is signed, not encrypted. Anyone who gets the token can base64url-decode the payload and read every claim. Never put secrets, passwords or sensitive PII in it. If you need confidentiality you'd use JWE (encrypted JWTs), or keep the data server-side and put only an opaque ID in the token.

Name the registered claims and what each one is for.

iss is who issued the token. sub is who it's about (the user or client). aud is who it's intended for (the API that should accept it). exp is the expiry time. nbf is not-before. iat is issued-at. jti is a unique token ID, useful for revocation and replay detection. The times are NumericDate: seconds since the Unix epoch, in UTC.

$ bash solution.sh
Loading...

Output

Run your solution to see its output here.