Topic starter
08/02/2026 8:28 pm
TL;DR: Refresh tokens persist beyond SSO and MFA, can be stolen from storage or third-party integrations, and may be replayed long before revocation, according to Obsidian Security. The practical problem is not just protection but detection, because behavioral monitoring is the only control that can expose active token abuse in time.
Editorial analysis by NHI Mgmt Group, based on content published by Obsidian Security: “Refresh Token Security: Best Practices for OAuth Token Protection”.
Key questions
Q: What breaks when refresh tokens are stolen from SaaS environments?
A: When a refresh token is stolen, the attacker can mint new access tokens without repeating SSO or MFA, so the compromise survives beyond the original login event.
Q: Why are refresh tokens riskier than access tokens after compromise?
A: Access tokens are usually short-lived, so their damage window is limited.
Q: How can security teams tell whether refresh token handling is actually safe?
A: The key signal is whether a stolen or replayed refresh token can still mint new access tokens after it has already been used once.
Practitioner guidance
- Implement token-family rotation with reuse detection Use atomic updates so each refresh exchange invalidates the previous token and any reused token family is revoked immediately.
- Baseline token behaviour across SaaS apps Track normal access patterns, timing, volume, and source location so deviations can be flagged before exfiltration completes.
- Inventory third-party OAuth relationships Map which vendors, applications, and users can mint tokens into each SaaS platform so revocation decisions are precise during an incident.
Bottom line: Refresh tokens create a hidden SaaS attack path because they continue working after the authentication event that created them.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/10/2026 4:33 pm
Refresh token security is an NHI governance problem disguised as an authentication problem. Refresh tokens are long-lived bearer credentials, so the governance issue is not initial sign-in but what happens after a token outlives the authentication event that created it. That makes lifecycle control, revocation, and abuse detection central to the identity programme. Practitioners should stop treating refresh tokens as a peripheral OAuth detail and manage them as privileged non-human credentials.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
- Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
A question worth separating out:
Q: When should organisations revoke refresh tokens aggressively?
A: Aggressive revocation is appropriate when an employee leaves, a vendor is breached, or a token shows anomalous behaviour that suggests replay or exfiltration. The key is knowing which tokens map to which resources so revocation is targeted, not a blunt disruption event.
👉 Read our full editorial: Refresh token security exposes the hidden SaaS attack path