Wiki · Concept · Last reviewed June 25, 2026

OAuth Step-Up Authentication

OAuth Step-Up Authentication is the RFC 9470 pattern for asking a client to obtain a new access token when the current token was not issued after strong enough or recent enough user authentication.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, step-up, authentication evidence, audit trails

Definition

OAuth Step-Up Authentication is the Standards Track protocol defined in RFC 9470, OAuth 2.0 Step Up Authentication Challenge Protocol, by Vittorio Bertocci and Brian Campbell. RFC 9470 was published in September 2023.

The protocol lets a resource server tell a client that the access token on the current request is not enough because the user-authentication event behind that token lacks the required strength or recentness. It extends the Bearer-token challenge pattern from RFC 6750 with a new error value, insufficient_user_authentication, plus challenge parameters that tell the client what kind of step-up is needed.

For AI agents, this is a boundary between ordinary automation and high-risk action. A read token, old session, or low-assurance login may be acceptable for browsing a file list but not for sending money, deleting records, deploying code, or changing account recovery settings.

How It Works

The flow starts when a client calls a protected resource with an access token. The resource server evaluates the authentication information associated with that token. If the token does not meet the resource server's authentication requirements, the resource server denies the request and returns a WWW-Authenticate challenge.

RFC 9470 defines two challenge parameters. acr_values is a space-separated list of authentication context class reference values, in preference order. max_age is the allowed elapsed time in seconds since the last active user-authentication event. The two parameters can appear together when the resource needs both a particular authentication context and a fresh authentication event.

A client that receives insufficient_user_authentication should parse the challenge and construct a new authorization request using the indicated acr_values or max_age. If the authorization server succeeds, it returns a new access token whose associated authentication information can satisfy the resource server.

RFC 9470 describes two common ways for the resource server to evaluate the token: JWT access tokens from RFC 9068, using acr and auth_time claims, and OAuth token introspection from RFC 7662, using acr and auth_time response members. The client must still treat access tokens as opaque and should not inspect them to decide whether step-up requirements are satisfied.

Agent Context

Agent systems often batch routine and exceptional actions behind one interface. A user may allow a scheduling agent to read calendars every day, but approving a mass cancellation, external invitation, or payment-linked booking should require a fresh check. Step-up gives the resource server a standards-based way to interrupt the automation and require the client to obtain better authentication evidence.

This matters because the resource server may know risk facts that the authorization server did not know at token-issuance time: purchase amount, target account, jurisdiction, deletion count, privileged repository, anomaly score, or policy state. The challenge lets that resource-specific decision travel back through the OAuth flow.

Step-up does not prove that an agent action is wise. It proves only that a new token was obtained under authentication conditions acceptable to the resource server. Least privilege, user-facing explanation, tool policy, and audit review remain necessary.

Governance and Safety

RFC 9470 is explicit that it must not be used to position OAuth as an authentication protocol. It relies on a separate authentication layer, commonly OpenID Connect, to perform and describe user authentication. The OAuth layer carries the consequences of that event for protected-resource access.

The governance risk is disclosure. The RFC notes that acr_values can reveal information about the user, resource, authorization server, or context. A challenge demanding a high assurance value for only some users or resources may expose who has sensitive privilege. Resource servers should therefore disclose only what the client needs to complete the flow.

Audit trails should preserve the protected resource, action class, original token result, challenge error, requested acr_values, requested max_age, authorization server, new token result, validated acr, validated auth_time, client ID, agent run, human approval surface, and final resource decision. Logs should not store full access tokens or refresh tokens.

Defense Pattern

Source Discipline

Claims about OAuth Step-Up Authentication should identify the protected resource, challenged action, challenge error, acr_values, max_age, access-token validation method, resulting acr and auth_time, authorization server, and client behavior. Do not collapse step-up into Rich Authorization Requests, Token Introspection, MFA marketing, ordinary scope denial, or a claim that OAuth itself authenticates the user.

Spiralist Reading

Spiralism reads step-up as a ritual of interruption. The machine may already carry a token, but the resource can still say: not for this act, not with that old evidence, not without a sharper proof from the person.

The interruption is the point. It gives the system a chance to distinguish routine permission from consequence.

Open Questions

Sources

Return to Wiki