by Đorđe Zeljić

Understanding JWT: Why the Payload is Decodable and How It Remains Secure

JSON Web Tokens (JWT) have become a widely used mechanism for securely transmitting information between parties, especially in the world of web applications. They’re commonly used for authentication, authorization, and information exchange in stateless environments.

But there’s a frequent misconception when developers first encounter JWTs: If anyone can decode the payload, how is the data secure? In this post, we’ll dive into what JWTs are, why the payload is easy to decode, and most importantly, how you can trust the validity and integrity of the data inside.

What is JWT?

A JWT, or JSON Web Token, is a compact, URL-safe token format used to represent claims between two parties: a client and a server. It’s often used to identify and authorize users in web applications. One of the reasons for its popularity is its stateless nature—once issued, a server doesn’t need to store tokens, which simplifies scaling and performance.

A typical JWT consists of three parts, each separated by a dot (.):

  1. Header: Contains metadata, such as the type of token (JWT) and the hashing algorithm (e.g., HS256 or RS256).
  2. Payload: Contains the actual claims—data like user ID, roles, and other relevant information.
  3. Signature: Provides a way to verify the authenticity of the token to ensure it hasn’t been tampered with.

Here’s what a JWT might look like:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Why is the Payload Decodable?

One of the first surprises developers encounter is that the JWT payload is base64-encoded, not encrypted. This means that anyone with the token can decode and read the payload.

So, why is the payload not encrypted?

1. Performance and Scalability

JWTs are often used in stateless environments where performance is crucial. Keeping the payload base64-encoded allows servers to quickly extract the information they need without the overhead of decryption. For many applications, such as user authentication, the payload doesn’t contain sensitive data that needs to be hidden—it contains data that needs to be verified.

2. Separation of Concerns

JWT’s purpose is not to hide the data; it’s to verify the integrity and authenticity of the data. If sensitive data needs to be transmitted securely, encryption mechanisms like TLS (for data in transit) or an additional layer of encryption within the payload can be used.

Think of the payload as a transparent envelope—anyone can look inside, but what matters is whether or not it has been tampered with. This is where the signature comes in.

How Can We Trust the Payload?

While the payload is readable, the security of JWTs lies in the signature.

1. The Signature: Ensuring Data Integrity

The signature is a cryptographic hash created by the JWT issuer using a secret key (for symmetric algorithms like HMAC) or a private key (for asymmetric algorithms like RSA). It combines the encoded header, the encoded payload, and the secret key or private key.

For example, using HMAC-SHA256, the signature is generated as follows:

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

When the recipient (usually a server) receives a JWT, they can verify its authenticity by re-creating the signature using the same method and key. If the re-created signature matches the one included in the token, the token is considered valid and trusted.

The process of validation ensures that any tampering with the payload (or the header) would result in a mismatched signature, and the token would be rejected.

2. Trusting Claims: The Importance of Verifying JWTs

In addition to verifying the token signature, JWTs typically include claims that further enhance trust and security. For example:

  • iss (Issuer): Identifies who issued the token. The server can verify that it trusts the token issuer.
  • aud (Audience): Specifies the intended recipient. Only the audience for which the token was intended should accept it.
  • exp (Expiration Time): Indicates when the token expires. Tokens with invalid or expired timestamps should be rejected.

These claims provide context and help protect against misuse, such as token replay attacks.

Common Pitfalls and Misconceptions

  1. JWT is Not Encrypted by Default While JWTs are base64-encoded, they are not encrypted. If sensitive data must be protected from unauthorized viewing, it should be encrypted separately or passed over a secure connection (such as HTTPS).

  2. Long-lived Tokens are Risky JWTs are stateless, meaning once issued, the server doesn’t track them. This makes long-lived tokens risky since, if compromised, they can be used until they expire. It’s best to keep JWTs short-lived and use refresh tokens when longer sessions are needed.

  3. Don’t Store JWTs in LocalStorage Since JWTs are often used to authenticate users, storing them in localStorage is dangerous as it exposes them to potential cross-site scripting (XSS) attacks. Instead, use httpOnly cookies, which cannot be accessed via JavaScript, adding an extra layer of protection.

Final Thoughts

While the JWT payload is decodable by anyone, that doesn’t compromise the security of the token. The real power of JWT lies in its signature, which ensures that the payload hasn’t been tampered with. By using proper token validation mechanisms, claims such as expiration times, and a trusted signing key, JWTs can provide a scalable and secure solution for managing user authentication and data transmission in web applications.

JWTs are efficient and flexible, but with great power comes great responsibility. Always verify your tokens, ensure you’re using secure transmission methods, and keep sensitive data protected.

By understanding JWTs and their underlying mechanics, you can confidently implement them in your applications, knowing your data is both verifiable and secure.