A JWT is three base64url blocks joined by dots, and only the last one protects anything. This set covers reading the claims with no key, adding the padding that base64url drops, and why a verifier has to fix the algorithm itself instead of trusting the header.
Each one is marked as you go, and the explanation arrives straight after, which is
the part worth reading.
4 questions, marked as you go.
Tasks
These need your own device. Run the command in Termux, then paste what it printed.
The marking looks at what the output means, so spacing, version numbers and
ordering do not matter. If you have not installed anything yet, the
lesson covers the setup.
Verify a token signature for real
The jwt.sh you finished is saved next to you. This decodes the sample token and then checks its HS256 signature against the secret it was signed with. Paste the last few lines.
Run this in Termux
On your own device. Nothing on this page executes it. The command runs in
your terminal, and this box only reads what you paste back.
You are looking for the verdict line at the very bottom.
the payload was decoded
the signature checked out against the secret
the script ran
What a good answer looks like
The decoded payload, which includes the name Mira, and then result: VALID, meaning the HMAC the script computed over the header and payload matches the signature in the token. Run the same command with --secret wrong-secret and the verdict flips to INVALID, which is the whole point: the signature is the only part of a token that proves anything, and it only proves it when you hold the right key. The payload was readable without any key at all, so treat every claim in it as public.
Marking your own work
Both halves of this are checked in your browser, with no server involved, so nothing
stops you from pasting output you did not run. The tasks are written so that the
easiest way to pass one is to actually do it and read the result, which is the whole
intention.