JSON Web Tokens are often introduced as authentication tokens, but that description skips the idea that makes them useful. A JWT is a compact container for claims: statements such as who a user is, who issued the token, what audience may accept it, and when it expires. Those claims can be read by anyone holding the token. A cryptographic signature allows a recipient to determine whether a trusted issuer created the token and whether its contents changed afterward.
Three segments with different responsibilities
A typical signed JWT has three dot-separated segments. The header identifies the token type and signing algorithm. The payload contains claims represented as JSON. The signature protects the encoded header and payload. Each segment uses Base64URL so the token can travel safely in HTTP headers, cookies, and links.
Base64URL is an encoding, not encryption. Decoding the first two segments requires no secret. This is intentional: many systems need to inspect claims while relying on the signature for trust. Sensitive information should not be placed in an ordinary signed JWT merely because the text looks unfamiliar.
What the signature actually proves
The issuer signs the exact encoded header and payload. With a shared-secret algorithm, the verifier uses the same secret to check the signature. With an asymmetric algorithm, the issuer signs with a private key and verifiers use the corresponding public key. A changed character produces a different signature result, allowing tampering to be detected.
A valid signature proves only that the signed bytes match a key. The verifier must still decide whether that key belongs to an accepted issuer, whether the chosen algorithm is allowed, and whether the claims make the token valid for the current request. Cryptography supports the trust decision; it does not replace policy.
Registered claims provide a shared vocabulary
JWT defines common claim names such as iss for issuer, sub for subject, aud for audience, exp for expiration, and nbf for not-before time. These claims are optional at the format level, but secure applications usually require several of them.
Audience validation is especially important. A token issued for one service should not automatically authorize requests to another. Issuer validation prevents an application from accepting correctly signed tokens from an untrusted authority. Time claims limit how long stolen or outdated tokens remain useful.
Why servers use JWTs
A service can verify a JWT locally without looking up a session record for every request. That property helps distributed systems and APIs where several services need to recognize the same identity. Public-key signatures allow many services to verify tokens without giving them the ability to create new ones.
The trade-off is revocation. A self-contained token may remain valid until it expires even after the user's access changes. Short lifetimes, refresh-token flows, key rotation, and targeted revocation mechanisms help manage that risk. JWTs reduce some shared-state needs; they do not eliminate identity lifecycle management.
JWTs are not always the best session format
Traditional opaque session identifiers are simple, easy to revoke, and keep user data on the server. They are often a better fit for a conventional web application. JWTs become attractive when claims must cross service boundaries or verification must happen independently, but using them where no such need exists can add complexity.
Large payloads also travel with every request, increasing bandwidth and encouraging applications to place too much authorization state in the token. Claims become stale as soon as roles or account status change. Keep tokens focused on stable, necessary information.
Signing and encryption solve different problems
Most JWTs encountered in APIs are signed tokens, formally known as JSON Web Signatures. Their contents remain visible, while the signature protects integrity and authenticity. JSON Web Encryption is a related standard that can conceal claims, but it adds key-management and interoperability decisions that many systems do not need.
Choosing encryption should follow a clear confidentiality requirement. It should not be used to compensate for placing excessive data in tokens. Even encrypted bearer tokens must be protected from theft because a recipient may accept them without knowing who presented them.
Verification must be strict
A verifier should choose allowed algorithms through configuration rather than trusting the token header blindly. It should validate issuer, audience, expiration, not-before time, and any application-specific claims. Key selection must be constrained so an attacker cannot point verification at an arbitrary key.
Error handling should reveal enough for operators to diagnose failures without leaking token contents or cryptographic details to clients. Logs should avoid storing live bearer tokens because anyone who obtains one may be able to use it.
A token is a signed message, not a magic identity
JWTs work well when a system needs a portable, independently verifiable set of claims. Their compact form and broad library support make them convenient, but the security comes from correct signatures, trusted keys, strict claim validation, and sensible lifetimes.
Thinking of a JWT as a signed message prevents the most common misunderstandings. Its contents are readable, its validity is contextual, and possession may grant access. Used with those realities in mind, JWTs are a useful building block rather than a shortcut around authentication design.