Security teams should treat refresh tokens as long-lived credentials and protect them accordingly. Use short-lived access tokens, store refresh tokens in encrypted and isolated locations, and apply strict client authentication and scoped access. Add rotation and reuse detection so a stolen token becomes harder to reuse. Revoke tokens promptly on logout, suspicious activity, or confirmed compromise.
Why refresh tokens behave more like credentials than ordinary session artifacts
Refresh tokens extend a session beyond the lifetime of a single access token, so they should be managed as high-value secret material rather than treated as harmless background state. That changes the control model: the real question is not just where the token is stored, but how tightly its issuance, binding, scope, and revocation are governed across the full token lifecycle. Ultimate Guide to NHIs is useful here because it frames long-lived secrets, rotation, visibility, and offboarding as lifecycle problems, not one-time configuration choices.
Good practice is to minimise the power of any stolen refresh token by keeping the related access token short-lived, limiting the refresh token to the narrowest client and audience possible, and separating storage from general application state. In OAuth deployments, the strongest session-risk reductions usually come from reducing token usefulness after theft, not from assuming theft can be fully prevented.
- Use the shortest practical access-token lifetime so a stolen access token has limited value.
- Bind refresh tokens to the intended client and keep their scope narrower than the user session itself.
- Store refresh tokens in isolated, encrypted storage with tightly controlled read paths.
Rotation, reuse detection, and revocation are what make theft less durable
Refresh token rotation is the key control when you want to lower session risk without making the session unusable. Each refresh should issue a new token and invalidate the previous one, so a replayed old token becomes a detectable anomaly instead of a durable foothold. That is the same basic security logic reflected in Top 10 NHI Issues, where rotation and offboarding are treated as core governance controls for long-lived identity material.
Reuse detection matters because rotation alone does not stop a race condition or a delayed replay. If the old token is presented after a newer one has already been issued, the server should treat that as compromise evidence and revoke the token family or session chain. Where teams skip this step, they preserve convenience but create a long-lived bearer secret that can survive endpoint compromise, proxy theft, or log exposure.
- Rotate on every refresh, not only on a timer.
- Detect reuse of an older token in the same token family and trigger revocation.
- Revoke immediately on logout, account recovery, suspicious device change, or confirmed compromise.
What good operational handling looks like in practice
Security teams should verify that refresh-token handling is enforced by the authorization server, not delegated to each client implementation. That means client authentication must be strong enough for the client type, token storage must not leak into logs or browser-accessible state unless the risk is explicitly accepted, and revocation must be reachable through a clear operational path. For implementation detail on session and authentication controls, the OWASP Cheat Sheet Series and OWASP ASVS both support the practical view that session controls, authentication state, and access checks need explicit verification rather than assumption.
What to verify: confirm the refresh token cannot be replayed after rotation, confirm revocation propagates quickly enough to end active sessions, and confirm no downstream service keeps accepting a token family after the authoritative server has revoked it. If a refresh token can still be used after logout or after a compromise signal, the control is not just weak, it is functionally broken.
What good looks like: a stolen refresh token should either fail immediately, or fail fast enough that the attacker cannot convert it into durable session persistence. In mature setups, the session survives normal user behaviour, but the token itself does not survive theft, duplication, or delayed reuse.
Practitioner takeaway: the safest OAuth 2 design is not the one that keeps refresh tokens forever available, it is the one that makes them narrow, rotated, revocable, and operationally observable enough that theft does not become session persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Credential Rotation and Expiry | Refresh-token rotation directly limits replay and token theft persistence. |
| NHI-06 — Secrets Storage and Protection | Refresh tokens are long-lived secret material that needs isolated, encrypted storage. | |
| NHI-08 — Detection and Response | Reuse detection and revocation reduce session persistence after token compromise. | |
| Recommendation — Rotate refresh tokens on use and invalidate the previous token family immediately. Store refresh tokens in encrypted, tightly scoped storage with minimal read access. Detect refresh-token reuse and revoke the affected session or token family. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Refresh-token handling depends on strong client authentication and scoped access. |
| PR.DS — Data Security | Refresh tokens are sensitive credentials that require protected storage and handling. | |
| RS.RP — Response Planning | Prompt revocation on suspicious activity is part of session compromise response. | |
| Recommendation — Enforce strong client authentication and least-privilege token scope. Protect refresh tokens with encryption and restricted storage access. Define and execute rapid token revocation for suspected compromise. | ||
| CIS Controls v8 | 5.1 — Account Management | Session-token lifecycle requires prompt revocation on logout and compromise. |
| 6.2 — Authentication and Authorization Management | OAuth refresh-token controls are an authentication and authorization concern. | |
| Recommendation — Revoke token-backed access immediately when the account or session is no longer trusted. Apply strong authentication controls to token issuance and refresh flows. | ||
Related resources from NHI Mgmt Group
- How should security teams implement JWT authentication without turning tokens into a permanent session mechanism?
- How should security teams store and refresh session tokens in iOS apps without breaking user sessions?
- How should security teams respond when they discover stolen OAuth or session tokens?
- How should security teams implement passwordless authentication without increasing access risk?
