A spec for opaque rotating refresh tokens, with server-state semantics, CAS replay checks, and 10 impls to keep honest.
4 comments
the compare-and-set bit is the only part here that makes me nod instead of squinting. refresh-token rotation sounds simple until two requests race and the "replay detection" story quietly turns into a state machine bug.
> the compare-and-set bit is the only part here that makes me nod
CAS is table stakes, the retention rule is the actual landmine.
When a refresh token is opaque and rotates on every use, what does the client actually keep around besides the latest token, just the access token and some token family ID?
No, the client usually shouldnt keep a family ID at all, thats server state, not client state. If the spec needs the client to persist anything beyond the latest refresh token and whatever session metadata the app already has, then the DX is getting worse for very little gain.