The authorization code is a short-lived, single-use value returned after consent and used only to obtain tokens. The refresh token is a longer-lived credential that can be used later to request a new access token when the original one expires. In practice, the code starts the session, while the refresh token supports ongoing access without repeated user login.
Why This Matters for Security Teams
OAuth 2.0 token handling is a trust boundary, not just a plumbing detail. The authorization code is deliberately ephemeral so that the browser-facing step does not become a reusable bearer credential, while the refresh token extends a session without forcing the user back through consent every time. That split is what makes modern delegated access usable at scale, but it also concentrates risk in the token exchange and storage design.
Practitioners usually get into trouble when they treat both values as interchangeable “tokens” and apply the same handling rules to each. The code should be short-lived and single-use; the refresh token should be more tightly protected, rotated where supported, and scoped to the minimum practical privilege. The distinction matters because a leaked code is usually a narrow, time-bound exposure, while a leaked refresh token can become durable access if the surrounding controls are weak.
For a broader view of the credential and token exposure patterns that make this distinction operationally important, see The 2025 State of NHIs and Secrets in Cybersecurity. In practice, teams usually discover the difference only after token leakage or overlong session persistence has already created an incident window.
How It Works in Practice
In the authorization code flow, the browser is used to obtain a one-time code after the user consents. That code is then exchanged server-to-server for an access token, and often a refresh token, at the token endpoint. The design goal is to keep the most sensitive credential exchange away from the user agent and to ensure the code itself cannot be replayed for long.
The refresh token serves a different function. It is not meant to represent a one-off login event, but a continued delegation relationship between the client and the authorization server. When the access token expires, the client uses the refresh token to obtain a new access token without re-prompting the user, which improves usability and reduces repeated authentication friction.
- The authorization code is transient, single-use, and bound to the exchange step.
- The refresh token is longer-lived and is intended for repeated renewal of access.
- Both are security-sensitive, but the refresh token generally carries the higher blast radius if stolen.
- PKCE is commonly used to reduce code interception risk in public clients.
In practice, the code must be protected from interception and replay during the redirect hop, while the refresh token must be protected at rest and during transport because it can outlive the original access token. These controls tend to break down when native apps, browser extensions, or poorly designed integration layers store refresh tokens in places that are easy to exfiltrate.
Common Variations and Edge Cases
Tighter token handling often increases integration complexity, so organisations have to balance user experience against revocation speed, client type, and storage constraints. The right answer also varies by whether the client is confidential or public, because the trust you can place in client-side storage changes materially.
One common edge case is token rotation. Some platforms issue a new refresh token each time the old one is used, which limits replay if a token is stolen after renewal. Others keep the same refresh token valid until it expires or is revoked, which is simpler operationally but increases exposure if the token leaks. Another edge case is session lifetime: long-lived refresh tokens can be acceptable in low-risk environments, but they are harder to govern when users or integrations change frequently.
Current guidance suggests treating refresh tokens as privileged credentials rather than routine session artifacts, especially when the application can act on behalf of the user without reauthentication. That becomes harder in environments with third-party integrations, mobile clients, and browser-based apps, where storage and revocation semantics differ. Teams should also be careful not to confuse the OAuth 2.0 refresh token with application-specific “remember me” logic, because those are operationally similar but security-wise very different.
Risk and Threat Considerations
The main risk is durable unauthorized access. An intercepted authorization code usually has a very small exploitation window, but a stolen refresh token can continue to mint access tokens until it is revoked or expires. That makes refresh tokens attractive to attackers who want persistence without repeatedly stealing credentials.
Failure mechanism: The common abuse path is interception, exfiltration, or poor storage of the refresh token, followed by repeated token renewal from an attacker-controlled endpoint. If the client does not rotate refresh tokens, bind them well, or detect unusual renewal patterns, the attacker can keep access alive while avoiding obvious login failures.
Impact: The compromise can look like legitimate activity, which weakens detection and slows response. The result may be long-lived access to user data, third-party integrations, API resources, or downstream systems that trust the OAuth session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | OAuth token handling is access control for delegated access sessions. |
| Recommendation — Restrict token scope and revoke stale delegated access quickly. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | The code-to-token exchange and refresh lifecycle govern authenticated access. |
| Recommendation — Apply access-control rules that limit token scope and renewal exposure. | ||
| NIST SP 800-63 | Auth — Authentication and Lifecycle | Token exchange and renewal depend on secure session and authenticator lifecycle. |
| Recommendation — Bind token renewal to strong authentication and protected session handling. | ||
| OWASP Agentic AI Top 10 | A2 — Identity and Access Abuse | OAuth tokens are a common delegated-access mechanism abused by agents and apps. |
| Recommendation — Limit delegated token authority and monitor abnormal token use. | ||
Practitioner Guidance
What to prioritise: Treat the refresh token as the higher-value credential and design controls around where it is stored, how it is renewed, and how quickly it can be revoked. The authorization code should be handled as a short-lived exchange artifact, not a reusable secret.
What to verify: Confirm that the code is single-use, short-lived, and protected by PKCE where appropriate, and verify that refresh token storage is isolated from browser-accessible or easily exported locations. Also check whether refresh token rotation and revocation are actually enabled in the provider, not just assumed by the implementation.
Practitioner takeaway: The safest OAuth implementations do not just issue both values correctly, they make sure the short-lived code cannot be replayed and the long-lived refresh token cannot quietly become a standing access path.
Related resources from NHI Mgmt Group
- What is the difference between an authorization code and an access token in OAuth?
- What is the difference between OAuth token refresh and real privilege control?
- What is the difference between refresh token rotation and a grace window in OAuth providers?
- Why is OAuth token management critical in cloud environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
