How long should a JWT live? exp claim guidance for multi-tenant apps

Short access tokens limit the blast radius of a leak. Long tokens are convenient. Here's how to pick a number, with reasoning.

Last updated: May 2026

shield

Private: Decoding, analysis, signature verification, and token generation all run in your browser. Nothing is sent to any server, except a JWKS URL you explicitly enter and click Verify on.

Paste your JWT

At a glance

Typical access token lifetime: 15–60 minutes
Typical refresh token lifetime: 14–90 days
Long-lifetime threshold (analyzer warns): > 24 hours
Spec reference: RFC 7519 §4.1.4

The `exp` claim is your blast-radius cap. If a token leaks, attackers have until `exp` to use it before a refresh-token-revocation step ends access. The shorter the lifetime, the less damage from any individual leak — and the more often the user's permissions, role, and active tenant are re-checked at the auth server.

Why short access tokens

A leaked access token is valid until `exp`. If `exp` is one hour out, the attacker has at most one hour. If `exp` is one week, the attacker has a week. Short lifetimes don't prevent leaks, but they cap the damage.

Pair short access tokens with longer refresh tokens stored server-side. Refresh tokens are exchangeable for new access tokens; they're the long-lived credential. Because they live in your database, you can revoke them — logout, role change, or "force sign out from all devices" all become "delete refresh tokens for this user".

Frequently asked questions

Is 15 minutes too short?expand_more

For most B2B SaaS, no. The frontend silently refreshes when the token nears expiry, so the user never sees it. The benefit is that role and permission changes propagate within 15 minutes — useful when an admin removes a user's access and expects them out within minutes, not hours.

When is 24 hours acceptable?expand_more

When you're shipping a backwards-compat API and changing token lifetime would break clients. Otherwise, almost never. A 24-hour token gives an attacker who steals it 24 hours of unrestricted access — that's plenty of time to exfiltrate data, change settings, or pivot.

Should I add clock-skew tolerance when validating exp?expand_more

Yes — a small one. ≤60 seconds is enough to absorb clock drift between machines without meaningfully extending the leak window. Don't go higher; clock drift large enough to need more is itself a problem worth fixing.

JWTs scale horizontally without shared session storage but make revocation hard. Server sessions revoke instantly but require shared state. Here's how to choose.

JWKS in multi-tenant apps: key rotation and per-tenant keys

How to host a JWKS endpoint, when to rotate keys, and the question of per-tenant keys (almost always: don't).