Refresh-Tokens

Part of the Refresh Token Design series. Two Correct Features Branching says a refresh that cannot prove its device gets a new row of its own, copying the device key from the row it came from, opening at the lowest tier. The honest case is a browser whose storage was cleared, and its road back is to prove a second factor, which rebinds the row to a fresh key. Per request signing says every request carrying a session must be signed by the device key on that session’s row. ...

Part of the Refresh Token Design series. The Question the Last Post Left Open A refresh arrives carrying a device proof that does not verify. Two things can produce it, and the request looks identical either way. A browser that lost its key and generated a new one, which is ordinary and frequent. Somebody holding a copy of the refresh token, who cannot sign because the key never left the machine it was made on. ...

Part of the Refresh Token Design series. The Actual Defect The previous post ended on a reframing worth repeating. Reuse detection was never really about token ordering. It was trying to answer “is this a different person” by looking at “has this token been seen”, which is a bad proxy, and the false logouts are the evidence. The real defect is that a refresh token is a bearer secret. Whoever holds the bytes is the session. Copy them out of storage, a log, a crash report, a proxy, and you are indistinguishable from the person they belong to. ...

Part of the Refresh Token Design series. I Have Shipped the Other Answer Twice Two systems I have written and published about keep a table of spent refresh tokens and treat a repeat as an attack. One uses a used_refresh_tokens table and a queue in the client. The other hashes the token and rejects the second presentation outright. That is the standard advice and I still think it is defensible. This post is about what happens when you take it out, which the previous post in this series did, and what that actually costs once you look at the code rather than the intention. ...

Part of the Refresh Token Design series. The Problem With Single Use Single use refresh tokens are the standard advice and the advice is right. A refresh token that works twice is a refresh token somebody can steal and use behind you. The trouble is the failure mode when a response goes missing. A client sends its refresh token. The server rotates, writes the new pair, and answers. The answer never arrives, because the tunnel dropped, the phone changed cell, the laptop lid closed. The client still holds the old token, and the old token is now spent. It retries, gets refused, and the person is looking at a login screen because of one lost packet. ...