JWT
Most important commands to remember
python3 -m pip show PyJWT— check the JWT library available to this interpreter.python3 -— run the small local validation example from standard input.
Commands and flags
| Command or syntax | Meaning |
|---|---|
python3 -m pip show PyJWT |
Show installed package metadata; install nothing. |
python3 - |
Read Python source from standard input. |
<<'PYTHON' |
Supply a literal multiline script without shell variable expansion. |
Inside Python, jwt.encode creates the test token. jwt.decode verifies it with a fixed algorithm, issuer, and audience. require demands the named claims. exp is an expiry timestamp in seconds since the Unix epoch.
The concepts that matter
1. JWT is a token format
A JSON Web Token carries claims: statements such as a subject identifier or intended audience. A common signed compact JWT has three dot-separated parts: a header, a payload, and a signature or authentication tag.
The header and payload are base64url encoded, so they are readable without the signing key. Encoding is not encryption. Other JWT forms support encryption, but an ordinary signed token should not contain information that must be hidden from its holder.
2. A valid signature is only one check
Signature verification checks integrity under a selected key. The recipient must also enforce the token’s intended use: trusted issuer, correct audience, required claims, time constraints, and the permissions relevant to the requested operation.
A perfectly signed token intended for another API should still be rejected. Decoding JSON proves only that the contents can be read; it does not establish any of these trust conditions.
3. The verifier chooses its trust rules
The receiver configures allowed algorithms and trusted keys. It must not accept whatever algorithm or key location an untrusted token requests. A key identifier can select among trusted keys, but does not make a new key trustworthy.
With symmetric HMAC, anyone holding the verification secret can also create tokens. With asymmetric signatures, verifiers can use a public key without possessing the signing key. Both approaches still require sound key distribution and lifecycle management.
4. Expiry does not mean immediate revocation
An expiry claim bounds token lifetime when the verifier checks it. It does not make a token disappear after logout or automatically communicate a changed account policy to every API.
Locally validated tokens can remain acceptable until expiry unless the system adds revocation or other stateful checks. Short lifetimes reduce that window. Refresh tokens and session termination belong to the broader authorization design, not to JWT formatting itself.
One small example
Optional: use an existing PyJWT 2.x environment. The example generates a fresh in-memory test secret and validates only its own disposable token. It sends nothing over the network.
python3 -m pip show PyJWT
python3 - <<'PYTHON'
import secrets
import time
import jwt
key = secrets.token_bytes(32)
claims = {"iss": "lab-issuer", "aud": "lab-api", "sub": "lab-user", "exp": int(time.time()) + 60}
token = jwt.encode(claims, key, algorithm="HS256")
print(jwt.decode(token, key, algorithms=["HS256"], issuer="lab-issuer", audience="lab-api", options={"require": ["iss", "aud", "sub", "exp"]}))
try:
jwt.decode(token, key, algorithms=["HS256"], issuer="lab-issuer", audience="different-api")
except jwt.InvalidAudienceError:
print("Rejected: wrong audience")
PYTHON
The first decode should print the verified claims. The second uses the same token and key but a different expected audience; the handler should print Rejected: wrong audience. These outcomes demonstrate that an authentic token can still be invalid for a recipient.
The random key is intentionally shared by signer and verifier inside one process. This is not a production trust-distribution design. No token or key is written to disk. If PyJWT is missing or Python reports an import error, the validation experiment has not run.
Keep this idea: Readable claims are input; trust comes from cryptographic verification plus the recipient’s explicit validation rules.