Why must refresh tokens be either sender-constrained or one-time-use (rotated), and how does rotation detect theft?

Refresh tokens are long-lived, so a stolen one would give lasting access; sender-constraining binds it to the client's key so a thief cannot use it, and rotation issues a new refresh token on every use so that a reused old one reveals the theft and lets the server revoke the whole chain.

Two options:

• Sender-constrained: the refresh token is bound to a key or certificate the client holds (for example via mutual TLS or DPoP, "Demonstrating Proof of Possession"). Presenting the token also requires proving possession of the key, which a thief does not have. For confidential clients, plain client authentication at the token endpoint already has this effect.
• Refresh token rotation (one-time use): every refresh returns a new refresh token and invalidates the old one. If an attacker steals a refresh token, either the attacker or the legitimate client will eventually present an already-used token. The server sees the reuse, cannot tell who is who, and revokes the entire token family, forcing a fresh login.

You can see rotation in a typical session refresh: the client sends refresh token 8xLOxBtZp8 and receives both a new access token and a new refresh token 9yNOxJtZa5; the old value is now dead.

Go deeper:

• RFC 9700, Section 4.14: Refresh Token Protection — sender-constraining and rotation explained, including reuse detection.
• RFC 9449: DPoP — how tokens are bound to a client-held key at the application layer.