Elysia Tools
Navigation
Workflow Playbook
Build a controlled JWT fixture or inspect an authorized sample, then review claims, algorithms, expiry, sensitive fields, and signature evidence without confusing decoding with verification.
Hubs
This workflow is for developers, identity engineers, and reviewers who need a concrete answer about a JWT sample. Start with a synthetic token or an authorized sample, record the service policy, and decide whether the purpose is fixture construction, structural inspection, or security review. A token value is sensitive even when it is only being used for debugging.
Use jwt-generator to create predictable test claims when you need a repeatable case. Use jwt-decoder to look at the header and payload and to check which iss, aud, iat, nbf, and exp values are present. This is not a verification step: decoding reveals encoded content but cannot prove who signed it.
Use jwt-decoder-security-auditor for the focused review. It can report algorithm and signature status, supported HS256 or RS256 verification results when an authorized key is supplied, time-claim problems, and likely sensitive claim names. Treat a missing key as unverified, not valid.
Compare the findings with the consuming service policy, including allowed algorithms, issuer and audience requirements, clock skew, and expiry handling. Rerun only with a redacted test fixture after changes, then record accept, revise, or block. For broader credential coverage, see auth-token-security; for key and signature topics beyond this JWT scope, see key-generation-signature-verification.
Workflow playbook
Generate a non-production JWT with deliberately chosen issuer, audience, subject, expiry, and optional custom claims. Keep the secret as test-only material and note the intended algorithm before moving on.
Decode the authorized sample or generated fixture and review the header and payload as separate data. Confirm which time claims are present, while recording that this step does not establish signature validity.
Pass the same controlled sample to the auditor to surface algorithm concerns, signature state, expired or not-yet-valid timestamps, missing issuer or audience signals, and potentially sensitive claim names. Supply a verification key only when authorized.
Resolve only the findings that belong to the test objective, rerun the auditor on the redacted fixture, and record which observations are accepted, which require a token-policy change, and which remain unverified because no key was supplied.
Use jwt-generator when you need predictable claims, timestamps, and an algorithm for a test case. Use jwt-decoder for an authorized sample when creating a new token would hide the behavior you need to investigate.
jwt-decoder displays the header and payload but does not validate the signature. Use jwt-decoder-security-auditor for security findings and provide an authorized HS256 secret or RS256 public key only when a real signature check is in scope.
Keep the finding and claim name when useful, but mask values that could identify a user, tenant, session, email address, or credential. A decoded payload is readable base64url data, not encrypted content.