Mastering JWT-Based User Authentication: An 8‑Step Guide

What Is User Authentication?

User authentication lets a user log in once and then access the site for a period without re‑entering credentials.

Step 1 – Submit Credentials

The client sends the username and password to the server via an HTTPS POST request, protecting the data from eavesdropping.

Step 2 – Verify Credentials

The application checks the supplied username and password against the database.

Step 3 – Create JWT

When verification succeeds, the server builds a JWT. It places the user’s id (shown as user_id in the diagram) into the payload, Base64‑encodes the header and payload, and signs the result, producing a token that looks like lll.zzz.xxx.

Step 4 – Return JWT in an HttpOnly Cookie

The JWT string is sent back to the user as a cookie with the HttpOnly flag, preventing JavaScript from reading it and mitigating XSS attacks.

Step 5 – Subsequent Requests Carry the JWT

As long as the cookie remains valid, each request includes the JWT, allowing the server to extract the token.

Step 6 – Validate the Token

The application checks the JWT’s signature, expiration time, and optionally the intended audience.

Step 7 – Decode Payload and Load User

After confirming validity, the server decodes the payload, reads the user_id (e.g., 1025), and retrieves the corresponding user record from the database, initializing any ORM or session state.

Step 8 – Process the Request

With the user context loaded, the application handles the request and returns the appropriate response.

Differences from Session‑Based Storage

Traditional session storage keeps the user ID in server memory, which can consume significant resources for large applications and often requires additional key‑value stores or caches. JWT moves the state to the client, reducing server memory usage and allowing extra user attributes (e.g., admin flag, bucket assignment) to be stored in the token.

While JWT adds CPU overhead for signing and decoding, this cost is usually comparable to disk I/O for session persistence, and the choice should be guided by performance data for the specific scenario.

Enabling Single Sign‑On Across Subdomains

With session cookies, each subdomain would need synchronized session stores. JWT eliminates this need because the token is already on the client. Setting the cookie’s domain attribute to the top‑level domain (e.g., .taobao.com) makes the token available to taobao.com and all *.taobao.com subdomains.

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

Note that the leading dot is required so that both taobao.com and any subdomains receive the cookie.