When should organisations rely on access tokens without refresh tokens?

When access tokens alone make sense

Access tokens without refresh tokens fit best when the work is intentionally bounded. If the session is short, the user can be prompted to sign in again when needed, and the app does not need background continuity, the simpler model reduces token lifetime, reuse risk, and lifecycle complexity. That is why it is often used for tightly controlled internal workflows and high-trust, low-latency sessions.

A useful Token and Session Security Guide principle is that shorter-lived access alone is a control choice, not a default. It shifts the design toward reauthentication and explicit session boundaries instead of silent continuation.

When the model breaks down

The trade-off appears when the user experience depends on continuity. If the application must survive browser restarts, mobile backgrounding, offline gaps, or long-running business tasks, removing refresh tokens forces repeated reauthentication and can interrupt legitimate work. At that point the design starts to optimize security at the cost of reliability and usability.

That is also where token theft becomes more visible. Access tokens are still bearer credentials, so a short lifetime helps, but it does not eliminate replay if an attacker can capture the token during its valid window. Sender-constrained patterns and strong validation matter when the exposure window is still meaningful.

A good reference point is RFC 9700: Best Current Practice for OAuth 2.0 Security, which reinforces that token lifetime, audience restriction, and proof-of-possession style protections are part of the security decision, not an optional extra.

Practical decision points for architects

Use access tokens alone when the process is simple enough that reauthentication is an acceptable control, not a burden. If the workflow is human-driven, time-bounded, and easy to resume, a short session can be safer and easier to govern than introducing refresh token handling, rotation, storage, and revocation complexity.

Use a refresh token when continuity is a product requirement, not a convenience. The moment you need durable sessions, delegated background access, or fewer user interruptions, the design should shift to managed refresh behavior with clear expiry, rotation, and revocation rules. For the underlying OAuth model, RFC 6749: The OAuth 2.0 Authorization Framework remains the baseline specification for how access and refresh tokens fit into the overall grant flow.

When teams want stronger replay resistance, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is the better control conversation than simply extending token lifetime. It helps reduce the value of a stolen access token by binding use to the holder.

Risk and Threat Considerations

Access-token-only designs reduce persistence, but they can create brittle sessions if the business process actually depends on continuity. They also concentrate risk into a smaller window: if the token is stolen, the attacker needs less time to act before expiry, but the token is still usable until it dies.

Failure mechanism: The session expires before the work is complete, or a stolen bearer token is replayed within its validity window because no refresh-layer controls or sender constraints exist.

Impact: Legitimate users face repeated sign-ins and workflow interruption, while attackers can still abuse any captured token until it expires, especially in high-value internal tools with broad backend access.

Practitioner Guidance

What to verify: Confirm that the session can genuinely be treated as disposable. If the user would be forced into awkward workarounds, shared credentials, or token caching hacks, the token-only model is the wrong fit.

Decision rule: If the main requirement is controlled, short-lived access, keep the design simple and bound the session tightly. If continuity, offline support, or long-running delegation is required, introduce refresh tokens with explicit lifetime and revocation handling rather than stretching the access token model.

What practitioners underestimate: The operational cost of “just make them log in again” is often small in theory and expensive in practice once the workflow spans multiple steps, devices, or handoffs. The right answer is usually not “never use refresh tokens”, but “only add them when continuity is a real requirement.”

Practitioner takeaway: Treat refresh tokens as a continuity mechanism, not a universal default, and reserve access-token-only sessions for workflows where reauthentication is acceptable and the blast radius of interruption is low.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on access grants without equally strong removal workflows?
• What breaks when organisations rely on surveillance tools without access governance?
• What do organisations get wrong about access reviews when they rely on approvals without decision context?
• What breaks when healthcare organisations rely on shared repositories without granular access controls and auditability?