How should security teams choose between short-lived access tokens and refresh tokens?

Use short-lived access tokens when re-authentication is acceptable and the resource is sensitive. Add refresh tokens when the business needs persistent sessions, but pair them with secure storage, narrow scopes, and rotation so longevity does not become durable abuse potential.

Why This Matters for Security Teams

Short-lived access tokens and refresh tokens solve different problems, but both can become security liabilities if teams treat them as interchangeable. Access tokens should limit exposure when a session is compromised, while refresh tokens extend usability and therefore expand the abuse window. For NHI and agentic workloads, that distinction matters even more because autonomous systems can request, reuse, and chain credentials faster than humans can review them. The OWASP Non-Human Identity Top 10 treats credential misuse and weak lifecycle control as core risks, not edge cases.

NHIMG research shows how quickly token exposure becomes real-world compromise. In the Salesloft OAuth token breach, stolen OAuth material was used to access downstream systems, illustrating why longevity must be justified, not assumed. The practical question is not which token type is “more secure” in isolation, but which one matches the required session length, recovery model, and revocation capability. In practice, many security teams discover token misuse only after a refresh path has already preserved attacker access far longer than intended.

How It Works in Practice

Security teams should start by separating authentication continuity from authorization exposure. Short-lived access tokens are best when the resource is sensitive, re-authentication is acceptable, and the application can tolerate frequent renewal. Refresh tokens are appropriate when user or workload experience requires persistent sessions, but they must be treated as high-value secrets with strong storage controls, narrow scopes, rotation, and revocation.

For NHI and agentic systems, current guidance suggests using workload identity as the primary identity primitive, then issuing ephemeral access tokens only for the specific task in progress. That means a service or agent proves what it is through a cryptographic identity, then receives a short-lived token scoped to one action or one destination. Standards such as SPIFFE are useful here because they shift identity away from shared credentials and toward attestable workload identity. The control plane can then apply request-time policy rather than relying on a long-lived session assumption.

• Use access tokens with tight TTLs when compromise impact must be minimized.
• Use refresh tokens only when the business case for continuity is clear.
• Store refresh tokens in protected server-side storage or platform-backed secure enclaves where possible.
• Rotate refresh tokens on use, and revoke the chain when abnormal behavior appears.
• Bind scopes to the smallest viable set of resources and actions.

This aligns with The State of Non-Human Identity Security, which reports that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations. That finding reinforces a simple operational rule: longevity is only safe when rotation, visibility, and revocation are reliable. These controls tend to break down in legacy integrations that cannot rotate tokens cleanly or in third-party OAuth relationships where the owning team cannot monitor downstream usage.

Common Variations and Edge Cases

Tighter token lifetimes often increase operational overhead, requiring organisations to balance reduced exposure against session churn, retry logic, and support burden. That tradeoff is especially visible in distributed applications, third-party integrations, and autonomous workflows where a token failure can interrupt a critical chain of actions. Current guidance suggests treating refresh tokens as the exception, not the default, when the workload can safely re-authenticate.

One common edge case is browser-based or mobile client behaviour, where user experience often drives the need for refresh tokens, but theft risk rises if tokens are stored unsafely. Another is machine-to-machine automation, where long-lived refresh tokens can create durable abuse potential if a compromised pipeline can silently renew access. The Guide to the Secret Sprawl Challenge is a useful reminder that token sprawl is often a storage and visibility problem as much as a cryptography problem.

For AI agents, best practice is evolving toward task-scoped, JIT-issued access with runtime policy checks and minimal persistence. There is no universal standard for this yet, but the direction is clear: refresh tokens should not be used to preserve broad, open-ended authority for autonomous systems. Where the application must remain continuously available, teams should pair short-lived access tokens with secure refresh rotation and explicit anomaly detection rather than extending token lifetime by default.

Related resources from NHI Mgmt Group

• Should security teams use short-lived tokens for workload and agent access?
• What is the difference between short-lived access tokens and refresh tokens in identity risk?
• How should security teams choose between OAuth flows for different client types?
• When do OAuth refresh tokens become more risky than short-lived access tokens?