What is a JWT Token? Plain English Explanation

What is JWT?

JWT stands for JSON Web Token. It is a compact, self-contained method of securely transmitting information between parties. A JWT is an encoded string that contains encoded data (claims) about a user and is cryptographically signed to prove it has not been tampered with. Instead of storing user sessions on the server, modern applications often use JWTs, which are stateless tokens that the server can verify without any database lookup.

Think of a JWT like a digital passport: it contains information about who you are, has been verified by an authority (the server), and can be checked whenever you use it without the authority needing to look up your information in a database.

The Three Parts of a JWT

Every JWT consists of three parts separated by dots: header, payload, and signature. Here is an example JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Part 1: Header

The header contains metadata about the token, specifically the type (always JWT) and the algorithm used to sign it (like HS256 or RS256).

{
  "alg": "HS256",
  "typ": "JWT"
}

This is Base64-encoded to create the first part of the token. The algorithm specifies how the signature will be created.

Part 2: Payload (Claims)

The payload contains the actual data you want to transmit. These are called "claims." They typically include information about the user and metadata about the token itself.

{
  "sub": "1234567890",
  "name": "Alice",
  "email": "alice@example.com",
  "iat": 1516239022,
  "exp": 1516325422
}

Common claims include: "sub" (subject, usually the user ID), "name" (user's name), "email" (email address), "iat" (issued at timestamp), and "exp" (expiration timestamp). The "exp" field is crucial—it specifies when the token expires and is no longer valid. This is also Base64-encoded to create the second part of the token.

Part 3: Signature

The signature is created by taking the header and payload, combining them, and cryptographically signing the result using a secret key and the algorithm specified in the header. This signature proves that the token has not been modified.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

When the server receives a JWT, it verifies the signature by recalculating it using the same secret key. If the calculated signature matches the provided signature, the token is authentic. If someone modifies the payload or header, the signature will no longer match, and the token is rejected.

How JWT Authentication Works

Here is the typical flow of JWT-based authentication:

1. User logs in: The user provides their username and password to the login endpoint.

2. Server verifies credentials: The server checks the password against the stored hash in the database.

3. Server creates JWT: If credentials are correct, the server creates a JWT containing the user's ID and other relevant claims, signs it with a secret key, and sends it to the client.

4. Client stores JWT: The client stores the JWT (usually in localStorage, sessionStorage, or a secure cookie).

5. Client sends JWT with requests: For subsequent requests, the client includes the JWT in the Authorization header: Authorization: Bearer [JWT]

6. Server verifies JWT: The server receives the JWT, verifies the signature using its secret key, and checks if the token is expired. If valid, the server processes the request without needing a database lookup.

JWT vs Sessions: Key Differences

Sessions: The server stores session data (user ID, login time, permissions) in memory or a database. When a user logs in, the server creates a session ID, sends it to the client as a cookie, and the client includes the session ID in subsequent requests. The server looks up the session ID in its database to verify the user.

JWTs: The server signs user data into a token and sends it to the client. The client includes the JWT with requests, and the server verifies it using the signature. No database lookup is needed.

Scalability: Sessions require server-side storage, making them less suitable for distributed systems with multiple servers. JWTs are stateless, so any server in a load-balanced system can verify them without accessing a database.

Performance: JWTs reduce database queries (better performance), but sessions are better at enforcing immediate logout (you can delete the session record instantly, whereas invalidating a JWT is harder before expiration).

Security Best Practices for JWTs

1. Use HTTPS Only

Always transmit JWTs over HTTPS to prevent man-in-the-middle attacks. Sending JWTs over plain HTTP exposes them to interception.

2. Keep Your Secret Key Secure

Never expose your secret key in client-side code, version control, or anywhere publicly accessible. Store it in environment variables on your server.

3. Use Reasonable Expiration Times

Set the "exp" claim to a reasonable value (typically 15 minutes to 1 hour). Shorter expiration times reduce the impact of token theft. Use refresh tokens to get new access tokens without re-logging in.

4. Validate All Claims

When verifying a JWT, check not just the signature, but also the expiration time and any other relevant claims. Use the JWT Decoder tool to inspect tokens and verify their contents.

5. Use Strong Signing Algorithms

Prefer RS256 (RSA with SHA-256) over HS256 for production applications, as it uses asymmetric cryptography and is more secure for distributed systems.

Conclusion

JWT tokens are a modern, scalable approach to authentication that fits perfectly with distributed systems, microservices, and mobile applications. By encoding user information and signing it cryptographically, JWTs allow servers to verify user identity without session storage. While they require careful attention to security (using HTTPS, protecting secret keys, setting expiration times), they offer significant advantages in performance and scalability. Understanding how JWTs work is essential for any modern web developer.

---