What breaks when OAuth step-up relies on acr_values alone?

Step-up breaks when teams assume acr_values is an enforceable requirement. In practice, it is only a request, so the authorization server may return a valid token without raising assurance. If the resource server does not verify the acr claim and auth_time, the system can accept a token that looks successful while still failing the intended security control.

Why This Matters for Security Teams

OAuth step-up is often treated as a simple assurance knob, but NIST SP 800-53 Rev 5 Security and Privacy Controls makes the broader point clear: access decisions only matter if they are enforced at the point of use. With acr_values, the client is asking for stronger authentication, not demanding it. If the authorization server declines to honor the request and the resource server does not validate the resulting token claims, the “step-up” becomes a signalling exercise rather than a control.

This is especially dangerous in OAuth-connected environments where tokens are reused across SaaS apps, automation, and third-party integrations. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means weak assurance can travel farther than teams expect. The risk is not just login bypass. It is the creation of a false security boundary that downstream systems trust because the token still looks valid.

Security teams usually discover this only after a privileged action succeeds with a token that was never truly stepped up, rather than through intentional assurance testing.

How It Works in Practice

In OAuth and OpenID Connect, acr_values is commonly used by the client to request a specific Authentication Context Class Reference. That request can be useful, but it is not a guarantee. The authorization server may authenticate the user at a lower assurance level, issue a token anyway, and still remain technically compliant unless the flow is designed to require and verify the stronger context.

The practical fix is to treat assurance as a runtime validation problem, not a front-end request parameter. Resource servers should verify the token’s acr claim, inspect auth_time where freshness matters, and reject tokens that do not meet the expected policy for the protected action. This aligns with guidance in RFC 9470 OAuth 2.0 Step-Up Authentication Challenge, which focuses on signalling that stronger authentication is required, and with the policy enforcement mindset described in NIST SP 800-207 Zero Trust Architecture.

• Require the resource server to enforce the minimum accepted assurance level.
• Validate acr against the action being performed, not just the session state.
• Check auth_time for sensitive operations where recent reauthentication is required.
• Use policy-as-code so step-up rules are evaluated consistently at request time.

For teams handling vendor access, the lesson is operational, not theoretical. NHIMG’s Ultimate Guide to Non-Human Identities shows how long-lived credentials and weak lifecycle controls widen blast radius, and OAuth step-up fails for the same reason when downstream services trust claims they never verify. These controls tend to break down when multiple resource servers accept the same access token but apply different assurance expectations, because the weakest verifier becomes the effective policy endpoint.

Common Variations and Edge Cases

Tighter assurance enforcement often increases user friction and integration complexity, so organisations have to balance stronger step-up requirements against service reliability and support load. There is no universal standard for how every API should interpret acr, which is why current guidance suggests documenting the assurance levels that matter most and applying them only where the business risk justifies the extra checks.

A common edge case appears when legacy identity providers set acr_values but do not return a reliable acr claim, or when middleware strips claims before the token reaches the resource server. Another is when machine-to-machine workflows reuse user-authenticated tokens and inherit assurance expectations they were never meant to satisfy. NHIMG’s analysis of Salesloft OAuth token breach and Klue OAuth Supply Chain Breach shows how quickly token trust can extend beyond the original authentication event.

Best practice is evolving toward explicit challenge-and-verify flows for high-risk actions, with clearer separation between authentication request, issued assurance, and resource-server enforcement. That is the real control gap: not whether step-up was requested, but whether any system verified that it actually happened.

Related resources from NHI Mgmt Group

• What breaks when AI governance depends on email or OAuth discovery alone?
• What breaks when identity governance relies on visibility alone?
• What breaks when fraud detection relies on login success alone?
• What breaks when API security relies on bearer tokens alone?