Mastering JWT: Standard Claims, Custom Tokens, and Renewal Strategies

JWT token payload is a JSON string containing claims that convey data.

Standard JWT claims include:

iss (Issuer): token issuer.

sub (Subject): token owner.

aud (Audience): token audience.

exp (Expiration time): token expiry.

nbf (Not Before): when token becomes valid.

iat (Issued At): token issuance time.

jti (JWT ID): unique identifier.

Custom claims can be added, e.g., using com.auth0 to create a token with expiration:

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

After setting an expiration, the token becomes invalid and the user must obtain a new token, which can be automated via renewal strategies.

Single‑token renewal scheme

Set token expiration (e.g., 15 minutes).

Frontend requests; backend checks expiration.

If expired, frontend requests a refreshed token; backend issues a new token.

Frontend retries the original request with the new token.

Optionally enforce re‑login after a fixed period (e.g., 72 hours) or limit refresh count (e.g., 50 times).

Double‑token scheme

On login, backend returns an access_token and a refresh_token.

Use access_token for API calls; if it expires, use refresh_token to obtain a new access_token.

Backend validates refresh_token expiration; if valid, issues new access_token, otherwise forces re‑login.

Logout or password change invalidates both tokens.

WeChat web authorization also follows an OAuth 2.0 double‑token pattern, issuing a short‑lived access_token and a long‑lived refresh_token.

Tokens can be stored in Redis with an expiration key; absence of the key indicates token expiry.