How do you use JWTs safely (expiry, rotation, revocation, scopes)?

JWTs are a standard building block for modern authentication and authorization in scalable architecture. They give you stateless identity, fast validation, and simple integration across microservices. But because JWTs are self contained, they can easily become unsafe without the right controls on expiry, rotation, revocation, and scopes. This guide explains how to use JWTs safely in both real systems and system design interview settings.

Why it Matters

JWTs appear in many system design interview questions because they touch identity, distributed systems, and security. With the right design, JWTs let every backend service validate user identity locally without depending on shared session storage. This helps you scale horizontally, reduce latency, and support many device types.

At the same time, mistakes such as long expiry, no revocation plan, or putting sensitive data inside the token can create serious vulnerabilities. Interviewers expect you to demonstrate that you understand these trade offs and can design safe token based authentication for large systems.

How it Works Step by Step

Step 1. Use access tokens and refresh tokens separately

A safe JWT design uses two types of tokens.

• Access token.

  • A short lived JWT used on every API request.
  • Validated by microservices through signature and claims checks.

• Refresh token.

  • A longer lived token used only to request new access tokens.
  • Stored securely and tracked server side for rotation and revocation.

This separation keeps API calls stateless and fast while still giving you control over long term sessions.

Step 2. Set safe expiry times

Expiry is your first defense.

• Access tokens expire in minutes. often around five to fifteen minutes.
• Refresh tokens expire in days or weeks. but with better storage and checks.

Important rules.

• Always validate the exp claim.
• Keep access tokens short lived to limit the impact of theft.
• Add a small clock skew margin if needed for distributed systems.

Short expiry reduces risk because even if an attacker steals an access token, it stops working quickly.

Step 3. Implement refresh token rotation

Rotation means each refresh token can be used only once.

A typical rotation flow.

1. User logs in and receives

   • A short lived access token
   • A refresh token recorded in the database

2. Client calls the refresh endpoint before access token expiry

3. Server validates the refresh token

4. Server issues

   • A new access token
   • A new refresh token

5. Server marks the old refresh token as used so replay is detected

Rotation stops attackers from silently reusing stolen refresh tokens because replay immediately triggers detection.

Step 4. Build revocation into your design

Because JWTs are stateless, revocation requires additional logic.

Common revocation patterns.

• Server side refresh token store.

  • Keep refresh tokens and revoke them by updating their status.

• User or session versioning.

  • Store a version number in the user record.
  • Include it inside refresh tokens.
  • Increment version on password reset or suspicious activity.
  • Tokens with old versions become invalid.

• Short lived blocklist for critical access tokens.

  • Useful for high risk operations.
  • Kept small to maintain scalability.

Most systems rely on short expiry for access tokens and explicit revocation only for refresh tokens.

Step 5. Use scopes and claims with least privilege

Put only essential information inside the JWT.

Safe scope design.

• Scopes describe allowed actions at a high level. for example read_profile, write_profile, stream_video.
• Avoid embedding complex permission models inside the token.
• Combine JWT scopes with server side authorization for fine grained control.

This keeps tokens small and reduces the need to reissue them when permissions change.