Bearer token handling and storage

Refresh tokens allow short-lived, narrowly scoped access tokens, reducing the impact of access token leakage, but they are an attractive target because they carry the full scope granted to a client. RFC 6749 baseline protection requires confidentiality of refresh tokens in transit and storage, transmission over TLS-protected connections between client and authorization server, a checked binding between each refresh token and its client, and that refresh tokens cannot be generated, modified, or guessed. Issued refresh tokens MUST be bound to the scope and resource servers consented by the resource owner, to prevent privilege escalation and reduce leakage impact. For public clients, authorization servers MUST detect refresh token replay using sender-constrained refresh tokens (RFC 8705 or RFC 9449) or refresh token rotation, where every refresh response issues a new refresh token and invalidates the previous one; a later presentation of an invalidated token reveals the breach and the authorization server revokes the active refresh token. Authorization servers MAY revoke refresh tokens automatically after security events such as a password change or logout, and refresh tokens SHOULD expire after client inactivity. Scope: OAuth 2.0 security. Reviewed October 4, 2026.