LEARN. PRACTICE. GROW.Start with the resource contract
A fictional fund-report API receives a signed JWT. The team confirms the signature and treats the request as authorized. It still needs to establish the intended resource, issuer, purpose and validity interval. The resource server needs an explicit policy agreed with the issuer: accepted algorithms, keys bound to the issuer, audience, type and required claims. The generic JWT format does not make every claim mandatory. The RFC 9068 access-token profile requires more information, including iss, exp, aud, sub, client_id, iat and jti. Document the applied profile rather than assuming any three-part sequence is a credential for this API.
Decoding does not authenticate content
The lab creates temporary RSA keys in memory and signs synthetic tokens with RS256. Reading the claims segment reveals tenant and scope without knowing the private key: encoding provides no confidentiality. When the exercise changes tenant after signing, signature verification fails. Another private key also cannot produce a signature accepted by the pinned public key. However, a correctly signed token with a different audience remains unsuitable for the resource. Cryptographic verification and context validation answer different questions. Do not put actual tokens into public decoders or log the complete bearer for convenient diagnosis; anyone obtaining the credential may be able to reuse it while controls accept it.
Choose trust before reading untrusted hints
The alg field must not let the sender freely choose cryptographic policy. The model accepts RS256 only and rejects HS256 or none even when other fields look correct. A kid identifies a key within the configured set; it does not create trust in that key. The fixture follows no jku URLs, downloads no remote material and rejects extensions it does not implement. In production, key discovery and refresh need trusted origins, limits and defined failure behavior. Do not treat a token-supplied URL as authorization to contact any destination. To reduce confusion between ID tokens and access tokens, the exercise requires a type compatible with at+jwt alongside issuer and audience checks.
Make time boundaries observable
The fixture clock is fixed and clock tolerance is zero. At exp the token is already rejected; at nbf it can become valid. Missing exp and a text-valued exp are rejected under this profile. Local policy adds a ten-minute maximum lifetime and rejects future issuance. Those two limits are teaching choices, not universal requirements for every JWT. Actual systems can permit small clock tolerance but need to justify its value and monitor synchronization. Indefinitely increasing tolerance to resolve an incident extends exposure and can hide drift. Record observed time, failure category and policy version without publishing the credential.
Use the exercise to formulate integration criteria
Turn the checks into integration acceptance criteria: altered signatures, wrong issuer, wrong audience, incompatible type, expiration, unknown key and missing claims should have defined outcomes. Include valid cases to avoid a protection that merely blocks everything. The code is a bounded model, not an audited JWT library or a complete profile implementation. It does not cover every parsing edge, duplicate JSON members, OAuth protocols or remote key retrieval. In a project, use maintained and reviewed components, confirm effective configuration and repeat tests at relevant entry points. The lab’s value is making boundaries explicit and assessable without turning local execution into approval of a production architecture.
node content/labs/securityx-api-authorization/run.mjs --output /tmp/securityx-api.json
# Synthetic keys and claims only; inspect checks, not real bearer tokens.A valid signature with aud intended for another API is rejected, as is a token at the exact exp instant.
Common pitfalls
Decoding as validation; kid as trust; ID token as access token; unlimited clock tolerance.
Related topics: Trust boundaries · API authorization · Revocation and operations
A valid signature is only one part of the token acceptance contract.
Reference: JWT Profile for OAuth 2.0 Access Tokens · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17