JWT Decoder Online Free

Understanding JSON Web Tokens (JWT)

A JSON Web Token (JWT), defined in RFC 7519, is an open, industry-standard method for securely representing claims between two parties. JWTs are the dominant authentication and authorization mechanism in modern microservices, single-page applications (SPAs), OpenID Connect (OIDC), and OAuth 2.0 implementations.

A JWT is compact and URL-safe, allowing it to be easily passed inside an HTTP Authorization: Bearer <token> request header, POST body, or URL query parameter. Unlike server-side session IDs that require database lookups on every request, a JWT is stateless and self-contained: it carries all necessary identity, role, and permission data within itself.

The Three Segments of a JWT Explained

Every JSON Web Token consists of three parts separated by periods (.):

1. Header: Typically consists of two parts: the signing algorithm being used (such as HMAC SHA256, RSA SHA256, or ECDSA) and the type of the token (which is JWT).
2. Payload: Contains the claims. Claims are statements about an entity (typically, the authenticated user) and additional operational metadata. There are registered claims, public claims, and private claims.
3. Signature: Generated by taking the encoded header, the encoded payload, a secret (or private key), and signing them using the specified algorithm. The signature allows servers to verify that the message wasn't tampered with along the way.

Standard Registered Claims Explained

RFC 7519 specifies a set of registered claim names that provide interoperability between authentication servers and API gateways:

• exp (Expiration Time): Unix timestamp representing when the token becomes invalid. Systems must reject tokens if the current time exceeds this value.
• iat (Issued At): Unix timestamp marking the exact second the token was minted.
• nbf (Not Before): Unix timestamp indicating the time before which the JWT must not be accepted for processing.
• iss (Issuer): Identifies the principal that issued the JWT (e.g., https://auth.company.com).
• sub (Subject): The principal that is the subject of the JWT (typically a unique user ID or account UUID).
• aud (Audience): Identifies the recipients that the JWT is intended for (e.g., an API resource identifier).

Real Worked Examples

Example 1: Standard User Authentication Token

Decoded Payload with user claims and expiration:

{
  "sub": "usr_998412",
  "name": "Jane Developer",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1740000000
}

In this example, iat: 1516239022 corresponds to 2018-01-18T01:30:22Z, and exp: 1740000000 defines the expiration deadline.

Example 2: Machine-to-Machine OAuth Token

{
  "iss": "https://accounts.google.com",
  "aud": "https://api.mycloud.io/v1/",
  "scope": "read:reports write:invoices",
  "iat": 1700000000,
  "exp": 1700003600
}

Common Mistakes & Security Pitfalls with JWTs

• Confusing Encoding with Encryption: Base64URL is NOT encryption. Anyone who intercepts a JWT can decode the header and payload instantly without a key. Never store passwords, API secrets, or unencrypted Social Security numbers in a JWT payload.
• Failing to Check Token Expiration: When building client applications or backend services, always ensure the exp claim is evaluated before honoring an API request.
• Accepting the 'none' Algorithm: Historical security vulnerabilities arose from servers accepting tokens signed with {"alg": "none"}. Modern backend frameworks strictly reject unsigned tokens.
• Storing Sensitive Tokens in Insecure Storage: Storing long-lived JWTs in browser localStorage exposes them to Cross-Site Scripting (XSS) attacks. For web applications, secure HttpOnly cookies are recommended for storing authentication tokens.

Frequently Asked Questions (FAQ)