Should organisations use refresh tokens in authorization code flows?

Why This Matters for Security Teams

Refresh tokens sit at the intersection of usability and blast radius. In an authorization code flow, they can keep users signed in without repeated prompts, but they also become a durable target for theft, replay, and session extension. That matters because token leakage is rarely theoretical: the Salesloft OAuth token breach shows how a stolen token can be turned into broad access, and NHI research from The 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild.

Security teams often get this wrong by treating refresh tokens as a routine implementation detail instead of a high-value secret with a longer life than access tokens. The right decision depends on whether the application truly needs persistent sessions, whether the authorization server supports sender-constrained or rotation-based protections, and whether storage is isolated from logs, browsers, and developer tooling. Guidance from the NIST Cybersecurity Framework 2.0 is consistent with that risk-based view. In practice, many security teams encounter refresh token misuse only after a downstream account takeover has already been investigated.

How It Works in Practice

When refresh tokens are used well, they are issued sparingly, scoped narrowly, rotated on use, and protected from exposure paths that are acceptable for access tokens but not for long-lived credentials. The storage model matters as much as the OAuth grant itself. Browser-based apps should generally avoid keeping refresh tokens in places that are easy to exfiltrate, while server-side apps can sometimes use them safely if the process boundary, secret handling, and audit logging are tightly controlled.

Current best practice is to pair refresh tokens with controls that reduce replay value. That can include rotation on every use, revocation on suspicious reuse, sender-constrained tokens where supported, and strict TTLs that align with the real business need. The Guide to the Secret Sprawl Challenge is a useful reminder that leaked credentials rarely stay contained, especially when they are copied into tickets, chat tools, or build logs. At the protocol level, the OAuth 2.0 framework and the OAuth 2.0 Security Best Current Practice both support the idea that refresh token use should be intentional, not default.

• Use refresh tokens only when uninterrupted access is a real requirement.
• Prefer rotation and revocation over long-lived static reuse.
• Store tokens server-side where possible, not in user-facing code or local storage.
• Limit scopes so a stolen refresh token cannot mint broader access than necessary.
• Monitor reuse, unusual geography, and token creation patterns as abuse signals.

These controls tend to break down in public clients, mobile apps with weak device hardening, and CI/CD environments where tokens are copied into scripts or logs.

Common Variations and Edge Cases

Tighter refresh token controls often increase implementation overhead, so organisations need to balance user convenience against session risk. That tradeoff becomes sharper when the application is a browser SPA, a native mobile app, or a headless workload, because each has different exposure paths and different options for secure storage.

There is no universal standard for this yet, but current guidance suggests avoiding refresh tokens in clients that cannot keep secrets confidential. For browser-based applications, the safer pattern is often short-lived access tokens with re-authentication or backend mediation rather than exposing a durable credential to the front end. For server-side applications, refresh tokens can be reasonable if they are stored like secrets, rotated, and bound to the smallest practical scope. The operational lesson from the JetBrains GitHub plugin token exposure is that developer convenience features can create lasting credential risk when the surrounding controls are weak.

Edge cases deserve special caution: shared accounts, admin consoles, service-to-service integrations, and legacy SSO bridges often accumulate tokens that outlive the original session design. The practical question is not whether refresh tokens exist, but whether the organisation can detect reuse, revoke them quickly, and prevent them from becoming the easiest path to persistence after compromise.

Related resources from NHI Mgmt Group

• What should organisations check before removing passwords from user access flows?
• Should organisations use PKI or FIDO for passwordless access?
• How should organisations use MFA and SSO together for enterprise access?
• What are the implications of using OAuth tokens in third-party integrations?