Part of the Refresh Token Design series. The Gap Device Binding Left Binding the refresh token to a device means a copied refresh token is worth nothing on its own. Good. It also means the refresh token is now the better protected of the two credentials, and the access token, which is sent on every single request, is still a bearer secret. Anybody who captures one has five minutes of full access and needs nothing else. ...

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. Signing In Is Not a Boolean Most auth code treats the session as a switch. Either somebody is in or they are not. Real sign-in has states in between, and each one needs a session that exists and reaches almost nothing. Somebody types a correct password and owes a second factor. They are not signed in, but they have to be able to call the route that lists their factors, the route that sends a code, and the route that verifies one. Those routes need to know who is answering, which means a session, which means a token. ...