Skip to content
All articles
Engineering27 May 2026·8 min read

Sessions, tokens, and the refresh you keep getting wrong

Short-lived access tokens are the right default. The interesting part is what happens in the second they expire.

Paycux engineering

There are two ways to know who is making a request. Look it up, or carry it with you. A session identifier is a lookup: small, revocable, and one database read per request. A signed token carries the claims: no lookup, but now the claims are true as of when they were minted rather than now.

Most systems end up with both, and most of the bugs live in the seam.

Why short expiry, and what it costs

A five minute access token bounds the damage of a leak. It also means that in a busy application, several requests will hit expiry at the same instant, each notice the token is stale, and each start a refresh. If your refresh tokens rotate on use — and they should — the first one wins and the others present a token that has just been invalidated.

Now you are signing people out at random, and the logs will tell you the token was reused, which looks exactly like an attack.

Concurrent refresh looks identical to token theft in the logs. Handle it before it wakes you up.

The fixes are boring and they work

Serialise refresh per session, so concurrent requests wait on one attempt rather than racing. Allow a short grace window in which the previous refresh token still returns the current session, so a request in flight during rotation does not fail. And refresh on a margin — a minute before expiry, not at the exact timestamp — so clock skew between two machines is not an outage.

Then decide what a refresh means. If it silently extends forever, you do not have a session lifetime, you have an ornament. Bound the total session independently of the refresh interval, and re-authenticate at the boundary.

  • One refresh in flight per session; others wait for its result
  • Grace window on the previous refresh token, measured in seconds
  • Refresh on a margin, not on the expiry instant
  • Bound the absolute session length, not just the token

Revocation is the part people skip

Signing out should end the session everywhere, including at the identity provider, or the next visit silently signs the person straight back in. Deleting your cookie is not signing out; it is hiding the evidence.

The same applies when an administrator removes someone. If access only disappears when the current token expires, your answer to 'how quickly can you revoke access' is 'within five minutes, probably' — and that is a sentence you will have to write in a questionnaire.

Everything here, already built

Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.

Start selling to enterprise customers

Create an account, point sign-in at Paycux, and get back to the part of the product that is actually yours.