Why not make access tokens valid for 30 days?

Question

Accepted Answer

Making access tokens valid for 30 days is considered a poor security practice because access tokens are typically sent with every API request, often over networks that may be compromised (e.g., through XSS, man-in-the-middle, or logging). If an attacker steals a 30‑day token, they can impersonate the user for an entire month without any further interaction. Additionally, because access tokens are stateless, revoking them requires a blacklist or a versioning mechanism, adding complexity. Short-lived access tokens (e.g., 15 minutes) limit the damage window, and refresh tokens (longer-lived but stored more securely and revocable) allow the system to reissue fresh access tokens while maintaining user convenience. Increased blast radius: A stolen token remains valid for 30 days, giving attackers prolonged access. Difficult revocation: Without a stateful mechanism, you cannot invalidate the token once issued. Poor user experience: If a user logs out, the access token stays valid until expiration—they remain logged in unless you implement additional revocation logic. Violates least privilege: Access tokens should have the minimal necessary lifetime to perform the immediate task, not long-term authorization. Encourages bad patterns: Developers might skip implementing refresh token rotation, leading to security gaps. // Recommended pattern:
// Access token: 15 minutes (short-lived)
// Refresh token: 7-30 days (stored securely, can be revoked)

// If a refresh token is stolen, you can revoke it via a database or rotation.
// The access token's short life limits damage.

// If access token were 30 days:
// 1) No automatic refresh mechanism needed, but:
// 2) Once stolen, attacker has 30 days of access.
// 3) Logout cannot invalidate the token without a blacklist.
``` In rare scenarios where offline access is required and the system cannot rely on refresh tokens (e.g., mobile apps with very limited connectivity), longer access token lifetimes might be considered, but they should be coupled with aggressive revocation strategies and shorter refresh windows. Even then, 30 days is extreme; 1–7 days is more common for such edge cases. The industry standard for OAuth2 and OpenID Connect is short-lived access tokens combined with refresh tokens for obtaining new ones, balancing security and usability.

Why not make access tokens valid for 30 days?

Long-lived access tokens (e.g., 30 days) greatly increase security risks because they give attackers a wide window to misuse stolen tokens, are hard to revoke, and undermine the principle of least privilege.

Why not make access tokens valid for 30 days?

Long-lived access tokens (e.g., 30 days) greatly increase security risks because they give attackers a wide window to misuse stolen tokens, are hard to revoke, and undermine the principle of least privilege.

Scenario Questions

Follow-up Questions