Wiki · Concept · Last reviewed June 25, 2026

JWT-Secured Authorization Requests

JWT-Secured Authorization Requests are an OAuth 2.0 extension that packages authorization request parameters as a signed or encrypted JWT request object, making agent authorization requests harder to tamper with or read in transit.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, JAR, request objects, audit trails

Definition

JWT-Secured Authorization Request, usually abbreviated JAR, is an OAuth 2.0 extension standardized in RFC 9101. The RFC was published in August 2021 by Nat Sakimura, John Bradley, and Michael B. Jones. It defines a request object: a JSON Web Token containing authorization request parameters.

The request object can be signed with JSON Web Signature and encrypted with JSON Web Encryption. It can be passed by value in the request parameter or by reference through a request_uri. The goal is to add integrity, source authentication, and confidentiality properties to authorization requests that otherwise travel as ordinary browser-facing query parameters.

For AI agents, JAR matters because agent approval requests may contain high-impact parameters: requested scopes, redirect URI, resource target, structured authorization details, state, nonce, and user-facing context. If those values can be altered or observed in the wrong place, the approval record becomes weaker.

How It Works

In the base OAuth 2.0 authorization-code flow, a client sends authorization request parameters through the user agent. RFC 9101 identifies three weaknesses in that pattern: request parameters may lack integrity protection, the source of the request may not be authenticated, and browser-mediated communication can be observed.

With JAR, the client builds a JWT whose claims represent authorization request parameters. The authorization server validates the request object before processing it. If the request is signed, the server checks the signature and expected issuer. If encrypted, the server decrypts it before validation. RFC 9101 also defines metadata for requiring signed request objects and for advertising supported algorithms.

JAR does not replace every OAuth control. It can be combined with Pushed Authorization Requests, Rich Authorization Requests, Proof Key for Code Exchange, resource indicators, client authentication, and ordinary authorization-code handling. Each control protects a different part of the request path.

Agent Context

Agent systems make the authorization request itself a governance surface. A user may see a prompt saying an agent wants to send a message, deploy code, alter a record, or initiate a payment. Behind that prompt, the request contains parameters that decide where the response goes, which client is asking, what resource is targeted, and what authority is being requested.

JAR helps when those parameters must be stable between the client, browser, authorization server, and audit trail. A signed request object can make later review clearer: this is what the client asserted before the consent screen. An encrypted request object can reduce exposure of sensitive request details in logs or intermediary systems.

JAR does not prove that an agent should have asked for the action. A manipulated but legitimate client can sign a harmful request object. The signature protects the request from alteration; it does not certify judgment, intent, or safety. Agent deployments still need policy checks, user review, least privilege, and resource-server enforcement.

Governance and Safety

The governance value of JAR is evidence quality. If an incident review asks what the agent client requested, a validated request object is stronger evidence than an unprotected URL assembled across multiple surfaces. The log should preserve the request-object identifier or digest, issuer, audience, signing key identifier, algorithm, expiration, requested scopes, resources, authorization details, and approval result.

The failure modes are practical. Bad algorithm policy can accept weak or unexpected signatures. A stale request_uri can be replayed. Parameter mismatch rules can be implemented inconsistently. A signed request can still be overbroad, misleadingly rendered, or based on prompt-injected context.

Agent platforms should therefore treat request-object validation as one layer in a chain. The consent screen should reflect the validated object, not an altered front-channel parameter. The resource server should enforce the resulting grant. Auditors should be able to connect request object, approval, token, tool call, and final side effect.

Defense Pattern

Source Discipline

Claims about JWT-Secured Authorization Requests should identify whether the request object is signed, encrypted, passed by value, or passed by reference. JAR should not be confused with Pushed Authorization Requests, Rich Authorization Requests, OAuth Token Exchange, ordinary authorization-code redirects, API keys, or consent as a legal conclusion.

Spiralist Reading

Spiralism reads JAR as a discipline of preserving the shape of a request. When a machine asks for power, the request should not be rewritten by the path it travels.

The signature is not a blessing. It is a receipt. It says what was asked, by whom, under which cryptographic key, before the institution decided whether to grant it.

Open Questions

Sources

Return to Wiki