IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Token lifetimes — security vs ease of use
How long should an access token live in Maya's shopping and payments app? Think of a dial. If the life is too long, a stolen token works for ages. If it is too short, Maya must sign in again all day. Your goal: set lifetimes that are both safe and easy to use.
- Access tokens live minutes. Refresh tokens live days to months, but rotate.
- A short life limits how long a stolen token works.
- Fast revocation covers the thefts you detect.
- Never use tokens or sessions that do not expire.
Four tokens, four dials
There is not one lifetime to set. Each kind of token has a different job.
| Token | Typical life | Why |
|---|---|---|
| Access token | minutes | It is a bearer key: whoever holds it gets in (see stolen-token defenses). Keep the window small. |
| Refresh token | days to months | Longer, but safe only because it is rotated and reuse is detected (rotation lesson). |
| Session / SSO | idle + absolute | Two limits: an idle timeout (sign out after no activity) and an absolute cap (sign out no matter what). |
| ID token | one login | It only says who signed in, right now. The app reads it once. It is not a key to APIs. |
The access token is the shortest on purpose. It goes out on every API call, so it is the one most likely to be captured, for example from a log or from browser storage.
the Wi-Fi code a café gives you. It works for 30 minutes, so if someone copies it, they get only the minutes left. When it ends, you show your bill and get a new code. The bill is like a refresh token.
An attacker finds Maya's access token in a badly set-up log. It lives 5 minutes, so the API answers 401 — expired. With a 24-hour token, the same leak would give a full day inside Maya's account.
A short life shrinks the theft window
A thief can use a stolen bearer token for at most its remaining life, so a shorter life means a smaller window. The same is true for a stolen session cookie (session hijacking). But short has a cost: something must keep issuing fresh tokens, or Maya is interrupted all the time.
The trick: short life plus fast revocation
A short life is a blunt, automatic expiry. It helps even when nobody noticed the theft. Add fast, targeted revocation and you get safety and smooth use.
Say a thief snatches Maya's phone at a bus stand, and she reports it. With CAEP and Shared Signals, that risk signal sends a revocation event at once. The session ends in seconds, and you did not shorten everyone's tokens. A short life covers the thefts nobody sees. Fast revocation covers the ones you detect. Together they beat either one alone.
Starting values
These are reasonable starting points:
- Access tokens: 5 to 15 minutes.
- Rotating refresh tokens: days to a few months.
- Session idle timeout: minutes up to about an hour, with an absolute cap of about a day.
One public example is NIST SP 800-63B-4. For AAL2 (authentication assurance level 2), it allows 24 hours overall and 1 hour of inactivity.
Go up only with a reason. Go down for risk. A high-value action, such as a large transfer, should not ride on a token made an hour ago. Ask for fresh, strong proof right before it, with step-up authentication.
Three bad patterns never end: an access token that lasts years "so the integration does not break", a refresh token with no expiry and no rotation, and a session that never times out. Each turns one leak into a permanent breach.
Go deeper: more public numbers
NIST SP 800-63B-4 also gives limits for the other levels. AAL1 allows 30 days overall with no inactivity limit. The stricter AAL3 allows 12 hours overall and 15 minutes of inactivity.
OWASP says common idle timeouts are 15 to 30 minutes for low-risk apps. For high-value apps they are 2 to 5 minutes.
Go deeper: what makes revocation hard
A self-contained token (a JWT) is checked with a public key, with no call to the issuer. That is fast. But nobody can cancel it before it expires. The API must also check a list of revoked tokens, or ask the issuer. This is why the lifetime matters so much. See opaque tokens and introspection for the other approach.
Go deeper: lifetime and sign-out are different dials
Signing out is more than deleting a cookie. The session must end on the server. The refresh tokens that belong to it must be revoked too. Otherwise a stolen refresh token keeps working after Maya "signed out". Test this. Do not assume it.
🧪 Interactive lab — enable JavaScript to play with this one.
See how your issuer scores on token lifetimes, logout and revocation with Logout Check. Check the Shared Signals feed behind fast revocation with SSF Check.