Renewal credential
A refresh token lets a client ask the authorization server for a new access token without repeating the full authorization flow. It is not sent to resource servers. It often has a longer useful lifetime and must receive stronger storage, binding, rotation, and revocation controls than an access token.
Bind and protect
Bind the token to the authorized client, subject or grant, and permitted resources and scopes. Confidential clients authenticate at the token endpoint. Public clients need refresh-token rotation or sender constraint under current OAuth security guidance. Keep tokens out of URLs, browser-readable storage where avoidable, telemetry, and crash reports.
Detect replay
With rotation, each successful use returns a new refresh token and invalidates the old one. Reuse of an invalidated member of the token family signals replay. Revoke the active family and require new authorization. Define how concurrent legitimate refresh requests behave.
Failure and residual risk
A stolen bearer refresh token can mint access tokens until detection, expiry, or revocation. Weak client binding, unlimited lifetime, broad scopes, concurrency races, and incomplete family revocation extend compromise. Revoking a refresh token does not automatically terminate access tokens, sessions, or completed actions.
Pomerium boundary
Pomerium uses configured identity-provider protocols for user authentication. The provider and client own refresh-token issuance and rotation. Pomerium route policy does not validate or revoke an upstream application's refresh tokens unless that integration explicitly uses them.
Evaluation checklist
- Is the refresh token accepted only by the intended authorization server and client?
- Does a public client rotate or sender-constrain it?
- Does reuse detection revoke the active token family?
- Are storage, concurrency, expiry, logout, and compromise response defined?
- Does revocation cover access tokens and sessions as separate states?
