BACKEND

Home › Glossary › Backend· 230 ·

JWT

\\jay-dub-ul-tee\\n.

Filed underBackendSecurityApisDesign

In brief · quick answer

JWT (JSON Web Token) is a compact, URL-safe token format for representing claims between two parties. It is commonly used for stateless authentication and secure information exchange in web applications.

§ 1 Definition

JWT (JSON Web Token, pronounced 'jot') is defined by RFC 7519. It is an open standard for creating tokens that assert claims (statements about an entity, typically the user). A JWT consists of three parts separated by dots: Header (metadata about the token type and signing algorithm), Payload (the claims: user ID, expiration, issuer, custom data), and Signature (cryptographic verification that the token has not been tampered with). The format is base64url-encoded JSON for the header and payload, with a signature computed over both. A typical JWT looks like: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.doxSXT0RtVnF7w5sQqC9yA. JWTs can be signed (JWS, most common) or encrypted (JWE). Signed tokens verify integrity and authenticity. Encrypted tokens additionally protect the contents from being read. JWTs are commonly used for stateless authentication: the server generates a JWT containing the user's identity and permissions, signs it, and sends it to the client. The client sends the JWT with every request (typically in the Authorization header). The server verifies the signature and reads the claims without querying a database. This statelessness is JWT's primary advantage over session-based authentication.

§ 2 JWT Structure

A JWT has three parts. The Header specifies the signing algorithm (HS256, RS256, ES256) and token type. The Payload contains claims: registered claims (iss, sub, exp, iat, nbf), public claims (can be defined in a registry), and private claims (custom to your application). The Signature is computed by encoding the header and payload, then signing them with the algorithm and secret/private key. The complete token is header.payload.signature. The payload is base64url-encoded, not encrypted. Anyone with the token can decode and read the payload. Do not store secrets in the payload. Sensitive data must be in an encrypted JWT (JWE) or stored server-side.

§ 3 Signature Algorithms: HMAC vs RSA vs ECDSA

JWTs can be symmetric (HMAC) or asymmetric (RSA, ECDSA). HMAC (HS256, HS384, HS512) uses a shared secret. The same secret signs and verifies. It is simple but requires the secret to be shared between the issuer and verifier. Asymmetric algorithms (RS256, ES256) use a private key to sign and a public key to verify. The private key stays with the issuer. Anyone can verify with the public key. Asymmetric signing is essential for multi-service architectures where multiple services must verify tokens but should not be able to sign them. ES256 (ECDSA) is recommended over RS256 because it produces smaller signatures and is faster to generate. Never use 'none' as the algorithm (a common security vulnerability when implementations do not validate the algorithm header).

§ 4 JWT Security Best Practices

JWTs have specific security requirements. Always validate the signature using the correct algorithm. Never accept 'none' algorithm tokens. Check the expiration (exp) and not-before (nbf) claims. Validate the issuer (iss) matches your expected issuer. Validate the audience (aud) if using JWTs across multiple services. Use short expiration times (15-60 minutes). Combine with refresh tokens for longer sessions. Store tokens securely on the client (httpOnly cookies for web apps, secure storage for mobile). Rotate signing keys periodically. Use a key management system for production. Implement token revocation (blacklist or short expiry with refresh tokens). The biggest JWT security failures come from implementation errors (algorithm confusion, not validating claims, storing secrets in payload) rather than the protocol itself.

§ 5 Note

Common misunderstanding: JWT payloads are not encrypted. They are base64url-encoded. Anyone who possesses the token can decode and read the payload. Never put secrets, passwords, or sensitive data in a JWT payload. Use JWE (encrypted JWT) if you need confidentiality. Another misconception: JWTs are inherently more secure than session IDs. They are not. A stolen JWT is just as dangerous as a stolen session cookie. The difference is that JWTs are stateless (no server-side lookup needed), which is an architectural tradeoff, not a security advantage. Short expirations and refresh tokens mitigate theft. Also: algorithm confusion attacks (where an attacker changes the algorithm from RS256 to HS256 and signs with the public key) must be prevented by always validating the algorithm against an allowlist.

§ 6 In code

```javascript
// JWT generation and verification
import jwt from 'jsonwebtoken';

const SECRET = process.env.JWT_SECRET;

// Generate token
function createToken(user) {
  return jwt.sign(
    {
      sub: user.id,
      role: user.role,
      email: user.email,
    },
    SECRET,
    {
      algorithm: 'HS256',
      expiresIn: '15m',
      issuer: 'my-app',
    }
  );
}

// Verify token
function verifyToken(token) {
  try {
    const decoded = jwt.verify(token, SECRET, {
      algorithms: ['HS256'],
      issuer: 'my-app',
    });
    return decoded; // { sub, role, email, iat, exp }
  } catch (err) {
    return null; // Invalid or expired
  }
}
```

§ 7 Common questions

Q. Should I use JWT for all my authentication?: A. JWTs are excellent for stateless APIs and distributed systems. For traditional server-rendered applications, session-based auth (server-side sessions) is simpler and equally secure.
Q. How do I revoke a JWT?: A. You cannot revoke a JWT server-side (that is the point of statelessness). Use short expirations (15 min) with refresh tokens, maintain a blacklist, or use a session store for tokens that need revocation capability.
Q. What is the difference between JWT, JWS, and JWE?: A. JWT is the token format. JWS (JSON Web Signature) is a signed JWT (integrity + verification). JWE (JSON Web Encryption) is an encrypted JWT (confidentiality + integrity). Most JWTs in practice are JWS.

Key takeaways

JWT is a compact, URL-safe token format for representing claims between two parties.
JWTs are signed for integrity, not encrypted. Payloads are readable by anyone with the token.
Always validate algorithm, signature, expiration, issuer, and audience.
Use short expirations with refresh tokens. JWT does not provide revocation by default.

How Atomic Glue helps

Atomic Glue uses JWTs for stateless API authentication across our web applications. We follow JWT best practices: short-lived access tokens, refresh token rotation, algorithm allowlisting, and strict claim validation. JWTs are our standard token format for API authentication, paired with OAuth 2.0 and OpenID Connect for social login. If your application needs token-based authentication, we design a system that is both secure and developer-friendly. JWT implementation is part of our Web Development services. Get in touch to secure your API.

Get in touch

# JWT

Category: Backend (also: Security, Apis, Design)

Author: Atomic Glue Development Team

## Definition

## JWT Structure

## Signature Algorithms: HMAC vs RSA vs ECDSA

## JWT Security Best Practices

## Note

## In code

## Common questions
Q: Should I use JWT for all my authentication?
A: JWTs are excellent for stateless APIs and distributed systems. For traditional server-rendered applications, session-based auth (server-side sessions) is simpler and equally secure.
Q: How do I revoke a JWT?
A: You cannot revoke a JWT server-side (that is the point of statelessness). Use short expirations (15 min) with refresh tokens, maintain a blacklist, or use a session store for tokens that need revocation capability.
Q: What is the difference between JWT, JWS, and JWE?
A: JWT is the token format. JWS (JSON Web Signature) is a signed JWT (integrity + verification). JWE (JSON Web Encryption) is an encrypted JWT (confidentiality + integrity). Most JWTs in practice are JWS.

## Key takeaways

JWT is a compact, URL-safe token format for representing claims between two parties.
JWTs are signed for integrity, not encrypted. Payloads are readable by anyone with the token.
Always validate algorithm, signature, expiration, issuer, and audience.
Use short expirations with refresh tokens. JWT does not provide revocation by default.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/jwt-backend