JWT Decoder

Understanding JSON Web Tokens (JWT)

JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.

How a JWT is Structured

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header: Typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
• Payload: Contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
• Signature: To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.

The Formula Behind JWT

The output is typically three Base64-URL strings separated by dots. The structure looks like this:

base64UrlEncode(header) + "." + base64UrlEncode(payload) + "." + signature

To create the signature:

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

What are Claims?

Claims are the "meat" of the JWT. Common registered claims include:

• iss (Issuer): Identifies the principal that issued the JWT.
• sub (Subject): Identifies the principal that is the subject of the JWT.
• aud (Audience): Identifies the recipients that the JWT is intended for.
• exp (Expiration Time): Identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.
• iat (Issued At): Identifies the time at which the JWT was issued.

Practical Example

Imagine a user logs into a service. The server validates the credentials and returns a JWT. The payload might look like this:

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}

The client stores this token (often in LocalStorage or a Cookie) and sends it in the Authorization header using the Bearer schema for subsequent requests. The server simply checks the signature to verify the user's identity without hitting the database for every single request.

Security Best Practices

1. Do Not Store Sensitive Data: JWTs are encoded, not encrypted. Anyone who intercepts the token can read your payload. Never store passwords, SSNs, or private keys in the payload.
2. Validate the Algorithm: Always enforce the expected algorithm on the server side to prevent "alg: none" attacks.
3. Use HTTPS: Always transmit tokens over encrypted connections to prevent man-in-the-middle attacks.
4. Keep Secrets Secret: If using HMAC, ensure your secret key is long, complex, and stored securely.
5. Short Expiration: Set a reasonable expiration time to limit the window of opportunity if a token is stolen.

Common Mistakes to Avoid

• Ignoring Expiration: Not checking the exp claim on the server.
• Storing Tokens in LocalStorage: While common, this makes them vulnerable to XSS. HttpOnly cookies are often a more secure alternative for web apps.
• Using Weak Keys: Using "password" or "secret" as your signing key makes it trivial to brute-force and forge tokens.

Frequently Asked Questions