Understanding JWT Refresh Token Rotation & Revocation
Why a refresh token lives for 7 days, and what the revoke column is for.
Phanith LIM
If you rotate refresh tokens, every refresh hands back a new access token and a new refresh token. So why set the refresh token to 7 days? If it gets replaced anyway, why not 30 minutes?
Because the expiry is not about how long the token lives. It is about how long a user can be away.
A 30-minute token breaks lunch
Say you set the refresh token to 30 minutes, for extra security.
- 12:00: the user logs in. Access token: 15 minutes. Refresh token: 30 minutes.
- 12:15: they finish what they were doing and close the laptop to get lunch.
- 12:50: they come back and open the app.
Both tokens are dead. The access token expired at 12:15, the refresh token at 12:30. The user has to type their password again because they stepped away for 35 minutes, and they blame your app for it.
7 days is a sliding window
With a 7-day refresh token you get a window that keeps moving:
- Active user: every refresh resets the 7-day timer. As long as they keep using the app, they stay logged in.
- User on holiday: no app for 10 days, the timer runs out, and they log in again when they return.
That is the real setting you are choosing: how long inactivity is allowed before a password is required.
Expiry is the clock, revocation is the kill switch
Expiry is a token dying of old age. Revocation is you killing it on purpose.
| Feature | Expiration | Revocation |
|---|---|---|
| Controlled by | The clock | The admin / server |
| Question | "Is this token too old?" | "Is this token still allowed?" |
| Database | Checked via expiry_date | Checked via is_revoked column |
That is_revoked column earns its place three times over:
- Logout. The server marks the token revoked, so it can never be used again.
- Password reset. Revoke every token for that user and all their sessions drop at once.
- Stolen token. If someone replays an old rotated token, the server sees it is already revoked and can lock the account.
Rotation, step by step
- The client logs in with a username and password. The server stores refresh token 1 with a 7-day expiry and returns access token 1 and refresh token 1.
- Access token 1 expires. The client asks for a refresh and sends refresh token 1.
- The server checks that refresh token 1 is valid and not revoked, marks it revoked, stores a new refresh token 2 with a fresh 7-day window, and returns access token 2 and refresh token 2.
Step 3 is the whole trick. The old token is revoked the moment it is used, so any later attempt to reuse it is both rejected and a signal that something is wrong.
In short
The 7-day expiry is your inactivity limit: it keeps active users logged in. Rotation and revocation are what make a long-lived session safe to hand out.