Understanding JWT Claims and Token Renewal Strategies

Hello everyone, I am a top architect.

The payload part of a JWT token is a JSON string that carries a set of statements called claims.

Standard claims defined by the JWT specification include:

iss (Issuer) : the entity that issued the JWT;

sub (Subject) : the subject of the JWT;

aud (Audience) : the intended recipient of the JWT;

exp (Expiration time) : when the JWT expires;

nbf (Not Before) : the time before which the JWT must not be accepted;

iat (Issued at) : when the JWT was issued;

jti (JWT ID) : a unique identifier for the JWT.

In addition to these standard claims, custom claims can be added. The following Java snippet (using the com.auth0 library) creates a token with an expiration time and a custom claim "username":

String token = JWT.create()
    .withIssuer(ISSUER)
    .withIssuedAt(new Date(currentTime)) // signing time
    .withExpiresAt(new Date(currentTime + EXPIRES_IN * 1000 * 60)) // expiration timestamp
    .withClaim("username", username) // custom parameter
    .sign(Algorithm.HMAC256(user.getPassword()));

Here withIssuer() sets the issuer, withIssuedAt() sets the issue time, withExpiresAt() sets the expiration timestamp (duration defined by EXPIRES_IN in seconds), and withClaim() adds a custom claim.

When a token expires, the client must obtain a new token, typically by prompting the user to log in again. To improve user experience, many applications implement automatic token renewal.

Token Expiration Renewal Schemes

Below are representative solutions for handling token renewal.

Single‑Token Scheme

Set the token expiration time to 15 minutes.

The frontend sends a request; the backend checks if the token is expired. If expired, the frontend requests a token refresh and the backend returns a new token.

The frontend uses the new token to retry the request.

To enforce a mandatory re‑login every 72 hours, the backend records the user's last login time and rejects refresh requests that exceed the 72‑hour window, forcing the user to log in again.

The backend can also limit the number of refreshes (e.g., a maximum of 50) and require re‑authorization after the limit is reached.

Double‑Token Scheme

After a successful login, the backend returns an access_token and a refresh_token , both stored on the client.

The client uses the access_token to call protected resources. If the token is expired, the client sends the refresh_token to the token‑refresh endpoint to obtain a new access_token .

The backend validates the refresh_token . If it is still valid, a new access_token is issued; otherwise, the client is redirected to the login page.

When the user logs out or changes the password, both the access_token and refresh_token are invalidated and cleared from the client.

WeChat web authorization also follows a double‑token OAuth2.0 flow: after the user authorizes, the third‑party app receives a short‑lived code , exchanges it for an access_token (valid for 2 hours) and a long‑lived refresh_token (valid for 30 days). When the access_token expires, the app uses the refresh_token to obtain a new one; if the refresh_token expires, the user must re‑authorize.

Another practical approach is to store tokens in Redis with an expiration time; if the token key is missing, it is considered expired.

Feel free to discuss, ask questions, or contact me for further communication.

--- Additional resources and interview questions are linked throughout the article, covering topics such as backend architecture, Redis usage, Docker, MySQL auto‑increment handling, and more.