Two Tokens Beat One
Last timeTokens That Carry Their Own Claim
One token cannot be both short-lived and convenient. Splitting the job in two, a short worker and a long renewer, resolves the conflict and makes theft detectable.
One token, two goals
The previous lesson ended with a dilemma. The staleness window of a
self-contained token is exactly its lifetime, so you want the lifetime
short. But when it expires the holder has to prove who they are again, and
proving who you are means a password and probably a second factor, so you
want the lifetime long.
Pick one number and both goals are compromised. A five-minute token means
signing in roughly a hundred times a working day, which nobody will accept.
A one-week token means a week of stale permissions, which nobody should
accept. The usual choice, an hour or a day, is a number that is bad at both
jobs rather than good at either, arrived at by splitting the difference
between two incompatible requirements.
The resolution is not a better number. It is noticing that the two goals
belong to two different activities and giving each its own token.
| staleness window is smal | the person signs in rare | works for a browser left | withdrawal lands in minu | |
|---|---|---|---|---|
| one token, five minutes | 1 | 0 | 0 | 1 |
| one token, one week | 0 | 1 | 1 | 0 |
| one token, one hour | 1 | 1 | 0 | 0 |
| two tokens, five minutes | 1 | 1 | 1 | 1 |
Splitting the job
Two tokens, with two jobs.
The access token is short, typically five to fifteen minutes. It is the one
sent with ordinary requests to ordinary services, and it is the natural
place for a self-contained signed statement, because its staleness window
is small enough to accept.
The refresh token is long, typically days or weeks. It is sent to exactly
one place, the authority that issues tokens, and it does exactly one thing:
it asks for a new access token. It is never sent to a business service, it
never authorises a read or a write, and it is always a handle checked
against a store rather than a self-contained statement.
The short lifetime now costs an exchange with the authority rather than a
sign-in by the person. The person notices nothing.
- exchanges needed over one period of use
- how long the person stays signed in
- lifetime of the access token
That last point deserves emphasis. The authority becomes a hard dependency
for the whole system, on a schedule set by the access token lifetime. It
needs to be the most available thing you run, and the arithmetic above is
how you size it.
The lesson stops here
4 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents