How JWT Enables Secure, Login‑Free Actions: A Step‑by‑Step Guide

JSON Web Token (JWT) is a lightweight specification that allows secure transmission of information between a user and a server.

Consider a scenario where user A follows user B. Instead of requiring B to log in, the system can send B an email with a link that contains a JWT, enabling the follow action without a login step.

JWT Structure

A JWT is a string composed of three parts: Header , Payload , and Signature .

Payload

The payload is a JSON object that carries claims. Example:

{
  "iss": "John Wu JWT",
  "iat": 1441593502,
  "exp": 1441594722,
  "aud": "www.example.com",
  "sub": "[email protected]",
  "from_user": "B",
  "target_user": "A"
}

The first five fields are defined by the JWT standard:

iss – issuer of the JWT

sub – subject (the user the JWT is about)

aud – audience (the intended recipient)

exp – expiration time (Unix timestamp)

iat – issued‑at time

Base64‑encoding this JSON yields the payload part of the token.

Note: Base64 is an encoding, not encryption; it can be decoded back to the original data.

Node.js example using the base64url package:

var base64url = require('base64url')
var header = {
  "from_user": "B",
  "target_user": "A"
}
console.log(base64url(JSON.stringify(header)))
// Output: eyJ... (truncated)

Header

The header describes the token type and signing algorithm:

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

After Base64‑encoding, this becomes the JWT header.

Signature

The encoded header and payload are concatenated with a period (.) and then signed using the algorithm specified in the header (e.g., HS256) and a secret key:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

The resulting signature ensures the token cannot be altered without knowledge of the secret.

This process is reflected in the source code of libraries such as node-jws .

Purpose of the Signature

The signature guarantees that any modification to the header or payload will produce a different signature, and without the secret key an attacker cannot forge a valid signature.

Is Information Exposed?

Because Base64 is reversible, sensitive data (e.g., passwords) should never be placed in the payload. Non‑sensitive identifiers like user IDs are acceptable.

Typical Use Cases

JWTs are suitable for transmitting non‑sensitive data in web applications, such as friend‑request links, order confirmations, and stateless authentication.

Eight‑Step Authentication Flow

User submits username and password via an HTTPS POST.

Server validates credentials against the database.

Upon success, the server creates a JWT containing the user’s ID in the payload.

The JWT is returned to the client as an HttpOnly cookie.

For subsequent requests, the client sends the cookie containing the JWT.

The server verifies the JWT’s signature, expiration, and audience.

If valid, the server decodes the payload to retrieve the user ID.

The server loads the user’s data and processes the request.

Difference from Session Storage

Session storage consumes server memory and often requires distributed caches, whereas JWTs store state on the client, reducing server load. However, JWTs add computational overhead for signing and verification.

Single Sign‑On (SSO)

By setting the JWT cookie’s domain to a top‑level domain (e.g., .taobao.com), all subdomains can access the same token, enabling seamless SSO without synchronizing session data across servers.

Set-Cookie: jwt=lll.zzz.xxx; HttpOnly; max-age=980000; domain=.taobao.com