JWTDecoder

A JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. Defined by RFC 7519, JWTs are commonly used in modern web applications for stateless authentication and authorization. The information within a JWT is digitally signed using a cryptographic algorithm, ensuring its integrity and authenticity.

JWT (JSON Web Token) is an open standard that allows secure data exchange between a client and a server. Because they are self-contained, JWTs hold all the necessary information about a user, avoiding the need to query a database repeatedly for session state. This makes them highly scalable for microservices and APIs.

A standard JWT consists of three parts separated by dots (.): Header, Payload, and Signature.

Header

The header typically consists of two parts: the type of the token (JWT) and the signing algorithm being used, such as HMAC SHA256 or RSA.

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

Payload

The payload contains the claims. Claims are statements about an entity (typically, the user) and additional data.

{
  "sub": "123456",
  "name": "John Doe",
  "iat": 1710000000
}

There are three types of claims: registered (standard claims like exp or sub), 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. This provides integrity validation, tamper detection, and secure authentication.

1. Login: The user provides credentials (username/password) to the authentication server.
2. Generation: The server verifies the credentials and creates a signed JWT.
3. Storage: The client stores the JWT locally (often in localStorage, sessionStorage, or an HttpOnly cookie).
4. Transmission: For subsequent requests, the client sends the JWT in the Authorization header using the Bearer schema.
5. Validation: The server decodes and verifies the signature of the token to authenticate the request before responding.

JWTs support multiple algorithms for signing. The differences mainly revolve around symmetric versus asymmetric cryptography:

• HS256, HS384, HS512: Symmetric algorithms (HMAC). They use a single shared secret key for both creating and verifying the token signature.
• RS256, RS384, RS512: Asymmetric algorithms (RSA). They use a private key to sign the token and a public key to verify it. This is more secure for distributed systems where multiple microservices need to verify the token without knowing the signing key.

• Token Expiration: Always use short-lived tokens and implement the exp claim to limit the window of opportunity if a token is stolen.
• HTTPS Only: Only transmit tokens over encrypted HTTPS connections to prevent interception (Man-in-the-Middle attacks).
• Signature Verification: Your backend must strictly verify the signature before trusting any payload data.
• Secret Management: Store symmetric secrets securely (e.g., environment variables, secret managers) and rotate them regularly.
• Browser-Side Privacy: Use our local decoding tool to inspect tokens without sending sensitive payloads over the network.