A JWT token, short for JSON Web Token, is a compact format for passing claims between two parties. Applications commonly use JWTs after login: a server issues a token, the client sends it with later requests, and an API verifies the token before allowing access. A JWT is not a cryptocurrency token, and its contents are not automatically secret.
Account systems across finance, exchanges and Web3 services may use token-based authentication behind the scenes. Readers exploring digital-asset platforms can create a Tapbit account, while developers should treat every authentication token as a security-sensitive credential.
What Is a JWT Token?
The JWT standard, RFC 7519, defines a compact claims format designed for transmission as a JSON object. A claim is a statement such as a user identifier, token issuer, intended audience or expiration time. JWTs are often used as access tokens, identity tokens or short-lived messages between services.
People often say “JWT token,” although the final “T” already means token. The repetition is common and harmless. What matters is understanding that JWT describes a format, not a complete login system. Secure authentication also requires correct issuance, validation, storage, expiration and revocation policies.
How Does a JSON Web Token Work?
A typical login flow starts when a user submits valid credentials. The authentication server creates a JWT containing selected claims and protects it with a digital signature or message authentication code. The client then presents the JWT to an API, often in an HTTP Authorization header using the Bearer scheme.
The API verifies the signature and checks required claims before trusting the request. Important checks can include the issuer, audience, expiration time and the algorithm expected by the application. If verification succeeds, the API uses the claims to make an authorization decision. If it fails, the request should be rejected.
The Three Parts of a JWT
A commonly seen signed JWT has three Base64url-encoded sections separated by dots:
header.payload.signature
- Header: identifies the token type and signing algorithm.
- Payload: contains claims, such as
subfor subject,issfor issuer,audfor audience andexpfor expiration. - Signature: lets the recipient detect unauthorized changes and verify the signer when the correct key is used.
Base64url encoding is not encryption. Anyone who obtains a normal signed JWT can usually decode its header and payload. Sensitive information should therefore not be placed in the payload unless the system uses an appropriate encrypted format and has a clear need for it.
JWT Example for Beginners
Consider an API that issues a token after Alice logs in. Its payload might identify Alice as the subject, name the issuer, specify the API audience and expire in 15 minutes. When Alice requests her profile, the API validates the token and uses the subject claim to locate the correct account.
If someone changes the payload from Alice’s identifier to an administrator’s identifier, the signature will no longer match. That is the core benefit of a signed JWT: tampering becomes detectable. A valid signature does not prove every claim is appropriate, however. The API must still confirm that the token came from the expected issuer and was intended for that API.
JWT vs Session Cookies vs API Keys
| Method | Typical purpose | Where state lives | Main consideration |
|---|---|---|---|
| JWT | Claims and API authorization | Token carries claims; servers may still keep state | Validation and revocation design |
| Session cookie | Browser login session | Usually server-side session store | Cookie and CSRF protections |
| API key | Identify an application or project | Server maps key to permissions | Keys are long-lived secrets unless rotated |
JWTs are not automatically better than sessions. Sessions can make immediate revocation straightforward, while JWTs can reduce repeated database lookups and work well across distributed services. Many systems combine both approaches, such as a short-lived JWT with a server-controlled refresh-token record.
Are JWTs Encrypted?
Usually not. The familiar three-part JWT is commonly a signed JSON Web Signature object. Signing provides integrity and authenticity when implemented correctly, but it does not hide the payload. JSON Web Encryption is a related standard that can provide confidentiality, although it uses a different structure and adds key-management complexity.
This distinction matters because developers sometimes paste a JWT into a decoder and are surprised to see readable data. Decoding is not the same as successfully verifying the signature. Applications should never grant access based only on decoded claims.
Common JWT Security Risks
The IETF’s JWT Best Current Practices, RFC 8725, addresses implementation failures that have appeared in real systems. The largest problems usually come from incorrect validation rather than from the basic format itself.
- Algorithm confusion: accepting an unexpected or unsafe algorithm.
- Missing claim checks: ignoring issuer, audience, expiration or other application requirements.
- Token theft: exposing a bearer token through logs, scripts, insecure storage or unprotected transport.
- Weak keys: using guessable secrets or failing to rotate compromised signing keys.
- Long expiration: leaving stolen tokens useful for too long.
- Poor revocation: assuming a signed token can never need early invalidation.
JWT Best Practices
Applications should explicitly allow only the algorithms they support, verify every required claim and use separate validation rules for different kinds of JWTs. Tokens should be short-lived, transmitted only over HTTPS and excluded from URLs and routine logs. Signing keys need secure storage, rotation and clear ownership.
Storage depends on the application. Browser systems may use secure, HttpOnly and SameSite cookies, while mobile or backend clients use platform-appropriate protected storage. No storage choice removes every threat, so developers must consider cross-site scripting, cross-site request forgery, token replay and device compromise together.
Conclusion
A JWT is a compact way to carry verifiable claims between systems. Its header describes how it is protected, its payload contains claims, and its signature helps recipients detect tampering. JWTs can simplify API authentication, but only when the recipient verifies the correct algorithm, issuer, audience, timing claims and signature. For beginners, the key rule is simple: a JWT is a credential format, not proof that an entire authentication design is secure.
Frequently Asked Questions
What does JWT stand for?
JWT stands for JSON Web Token, a standardized compact format for transmitting claims as JSON.
Can anyone decode a JWT?
Anyone who has a typical signed JWT can usually decode its header and payload. Decoding does not verify the signature or make the claims trustworthy.
Is a JWT the same as an access token?
No. An access token describes a purpose, while JWT describes a format. Some access tokens are JWTs, and others are opaque strings.
How long should a JWT last?
There is no universal duration. Access tokens are commonly short-lived, with the exact lifetime based on the system’s risk, revocation and usability requirements.
Can a JWT be revoked?
Yes, but revocation requires additional design, such as a denylist, key rotation, token versioning or a server-managed refresh-token system.
