JWT Signing: Safe Token Issuance and Validation
A source-reviewed guide to JWT signing, algorithm selection, claim validation, key separation, rotation, and safe test-token generation.
Primary source: authoritative reference
JWT signing protects a token's integrity and authenticates its issuer only when the verifier uses an expected algorithm, a trusted key, and the correct validation rules. Encoding a header and payload does not make a token trustworthy, and a valid signature does not by itself authorize an action.
Use a maintained identity or JWT library for production issuance and validation. A browser encoder is useful for synthetic fixtures and protocol learning, not for minting production credentials.
The parts of a signed JWT
A compact signed JWT has three Base64url-encoded segments:
header.payload.signature
The header identifies parameters such as the signing algorithm and key identifier. The payload contains claims. Neither segment is encrypted merely because it is Base64url encoded; anyone holding the token can usually read both.
The signature covers the encoded header and payload. A verifier must still decide which algorithms, keys, issuers, audiences, token types, and claim rules are acceptable for this exact context.
Choose an algorithm from the trust architecture
Do not let an incoming token choose the verification policy. RFC 8725 requires libraries and applications to verify that the algorithm is one the application permits and warns that each key must be used with exactly one algorithm.
- HMAC algorithms such as HS256 use the same secret to sign and verify. Every verifier that knows the secret can also mint tokens. This can be appropriate inside one tightly controlled trust boundary, but it is usually a poor fit when many independent services or external parties only need verification capability.
- Asymmetric algorithms separate a private signing key from public verification keys. They are often a better architectural fit when an issuer distributes verification capability without granting signing authority.
There is no universal rule that one algorithm is always best for microservices, public APIs, or “high-security” systems. Select an algorithm supported by the protocol and libraries, then design key custody, rotation, verifier distribution, and failure behavior around the actual trust boundary.
For HS256, RFC 7518 requires a key at least as large as the hash output: 256 bits. Generate HMAC keys with a cryptographically secure random-number generator. A human password, UUID, repository name, or short environment string is not an adequate signing key.
Treat token types as separate protocols
Applications often accept more than one kind of JWT: access tokens, ID tokens, logout tokens, email-action tokens, or internal job assertions. Reusing one permissive validation function across these types can let a token created for one purpose be accepted in another.
RFC 8725 recommends mutually exclusive validation rules for different JWT kinds. Use distinct values such as typ, issuer, audience, keys, and required claims so that the rules for one token type cannot accidentally validate another.
Validate more than the signature
A production verifier should use a maintained library and enforce a policy configured outside the token:
- Allowlist the accepted algorithm and bind the selected key to it.
- Resolve keys only from trusted configuration or a tightly constrained issuer metadata path.
- Validate
issagainst the expected issuer. - Validate
audfor the receiving service and reject a token issued for another resource. - Require and validate
exp; apply a small, documented clock-skew allowance only where needed. - Validate
nbfwhen present and enforce any application-required maximum token age. - Distinguish the expected token type and reject tokens from another context.
- Apply authorization using current subject, tenant, resource, and privilege policy after validation.
Claims are not universally mandatory merely because they exist in RFC 7519. The issuer and verifier must agree on a profile that defines which claims are required and what they mean.
Do not put secrets in the payload
JWT payloads are readable by their holders unless a separate encryption design is used. Avoid passwords, API keys, signing material, session secrets, and data the client does not need.
Even non-secret personal or operational data can spread through browser storage, logs, telemetry, support tickets, referrer mistakes, and copied debugging output. Keep claims minimal and use opaque identifiers where a resource server can retrieve current data safely.
Design lifetime, rotation, and revocation together
There is no universal 15- or 30-minute access-token lifetime. Choose a lifetime from the operation's sensitivity, expected detection time, client behavior, network conditions, and the issuer's ability to terminate access.
The jti claim is an identifier, not a revocation mechanism. A deployment may use it in a server-side denylist or replay-detection design, but the claim alone does not make a token revocable.
Plan how to:
- rotate signing keys without accepting an attacker-selected key;
- overlap old and new verification keys for a bounded migration window;
- reject tokens signed by retired or compromised keys;
- revoke sessions, grants, or refresh-token families through the issuer;
- investigate use without logging raw tokens.
For OAuth deployments, follow the access-token and refresh-token guidance in RFC 9700, including audience restriction and replay protection appropriate to the client type.
Generate only synthetic test tokens in browser tools
Create a synthetic HMAC JWT locally
Use the browser-local JWT Encoder for test fixtures with invented claims and a throwaway key. It does not manage production keys, validate your architecture, or issue trusted application credentials.
Open JWT Encoder →Use only synthetic claims and a throwaway test key. Do not paste a production signing secret, live bearer token, API key, customer record, or real identity data into a general-purpose tool. If a signing key may have been exposed, rotate or revoke it through the system that owns the key rather than testing whether it still works.
Issuer and verifier checklist
- [ ] The token type and trust boundary are documented.
- [ ] Production signing and validation use maintained libraries or an identity platform.
- [ ] Accepted algorithms are configured by the verifier, not copied from the token.
- [ ] Each key is bound to its intended algorithm and purpose.
- [ ] HMAC keys have sufficient cryptographic entropy and restricted custody.
- [ ] Issuer, audience, expiration, not-before, and token-type rules match the token profile.
- [ ] Different JWT types have mutually exclusive validation rules.
- [ ] Payloads exclude secrets and unnecessary sensitive data.
- [ ] Authorization is enforced after token validation.
- [ ] Key rotation, compromise response, and session or grant termination are tested.
- [ ] Logs and analytics exclude raw tokens and signing material.