Devise token expiration: immediate revocation vs. grace period?

The short answer

Enforce immediate invalidation at the configured expiry, and solve the user-experience problem with token renewal rather than a grace period on the same token. A grace period extends the effective lifetime of a credential that may already be compromised, which directly contradicts your least-privilege constraint. Renewal (refresh token or sliding expiration with rotation) gives active users continuity without keeping dead tokens valid.

Confirmed facts vs. likely explanation

Confirmed, assuming the classic Devise 3.x :token_authenticatable behavior (or the devise-token_authenticatable gem that preserves it):

• config.expire_auth_token_on accepts :creation (fixed lifetime) or :last_request (sliding window based on updated_at).
• Expiration is evaluated at authentication time; an expired token simply fails valid_token? and the request gets a 401. There is no grace-period hook and no automatic cleanup of expired rows.

Likely explanation for your dilemma: token_authenticatable was removed from Devise core in 4.0 (2014), so if you are on a modern Devise you are either using the compatibility gem or a custom module. Verify before designing around it:

bundle info devise-token_authenticatable
grep -E 'expire_auth_token' config/initializers/devise.rb

Why not a grace period

A grace window implemented by overriding valid_token? to accept expiry + grace has three problems:

1. It is just a longer expiry. An attacker holding a stolen token gets the same extra window as a legitimate user. You have not reduced risk; you have renamed it.
2. Race conditions. With :last_request, concurrent requests update updated_at; a monkey-patched comparison must be careful about which timestamp wins, or the grace window becomes unpredictable.
3. No revocation signal. A grace period implies "about to be revoked," but the client receives no distinct signal — it just gets a 401 slightly later. The UX problem (mid-upload or mid-form 401s) is not actually fixed, only deferred.

What to do instead

Pick one of two patterns, both compatible with least privilege:

• Sliding expiration (:last_request) with a short window. Active users never hit expiry because each authenticated request slides the window; idle users are logged out quickly. This is the least-effort fix and often eliminates the "expires mid-session" complaint entirely, since genuine mid-session expiry then only happens on requests longer than the window.
• Short-lived access token + refresh token. Issue a 5–15 minute token; a refresh endpoint validates the user is still active, then rotates both tokens. This gives you immediate revocation on logout, password change, or security events — something expire_auth_token alone never provides, because expiration is passive, not an explicit revocation.

If you must keep a grace window for legacy clients, scope it tightly: apply it only to requests that started before expiry (hard to prove server-side) or, more practically, return a distinct 401 token_expired response so clients can re-authenticate silently instead of erroring.

Cleanup either way

Neither approach deletes expired rows; Devise never did. Schedule a recurring job (sidekiq-cron, whenever, or your scheduler of choice):

User.where("authentication_token IS NOT NULL AND token_updated_at < ?",
  Devise.expire_auth_token.ago).update_all(authentication_token: nil)

Adjust the column names to your schema, and add the grace window to the cutoff if you implemented one. Run it at least daily; add an index on the timestamp column if the table is large.

One caveat

The exact method names and timestamp column (updated_at on the user vs. a separate token record) vary between Devise 3.x, the compatibility gem, and custom implementations. Read your installed module's valid_token? source before overriding anything — the design above holds, but the patch point may differ.