Wiki · Concept · Last reviewed June 25, 2026

JWT-Secured Authorization Response Mode

JWT-Secured Authorization Response Mode, or JARM, wraps OAuth authorization responses in a signed, optionally encrypted JWT so a client can verify the response before using its code, token, state, or error data.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, JARM, response mode, audit trails

Definition

JWT-Secured Authorization Response Mode, usually abbreviated JARM, is an OpenID Foundation Final specification from the FAPI workgroup. The current specification page is titled JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) incorporating errata set 1, was published on August 17, 2025, and lists Torsten Lodderstedt and Brian Campbell as authors.

JARM protects the OAuth authorization response: the message sent back through the user agent after an authorization endpoint succeeds or fails. Instead of returning raw response parameters directly as query, fragment, or form fields, the authorization server returns a response parameter whose value is a JWT response document.

For AI agents, JARM matters because browser-mediated approval flows can carry high-value codes, state values, errors, and extension parameters. If an agent connector depends on that response, later audit should know who issued it, which client it targeted, when it expired, and whether it was accepted before use.

How It Works

The JARM specification defines a JWT-based mode for OAuth authorization response parameters. The JWT response document always includes iss, the issuer URL of the authorization server; aud, the client identifier of the intended client; and exp, the JWT expiration. The specification recommends a maximum JWT lifetime of 10 minutes.

The JWT must also contain the authorization endpoint response parameters defined for the relevant response type, including error-response parameters. For the authorization-code flow, that means the JWT can contain code and state. For error responses, it can contain fields such as error, error_description, error_uri, and state.

JARM defines four response mode values: query.jwt, fragment.jwt, form_post.jwt, and jwt. The first three say where the response JWT is carried. The shortcut jwt means the default encoding for the requested response type: query.jwt for code, and fragment.jwt for token and most multiple-response-type values.

The client processing rule is strict. The client checks that the iss value identifies the expected issuer, the aud value matches its client ID, the exp value is still valid, and the signature is valid. The algorithm none must not be accepted. The client must not process grant-specific response parameters before those checks succeed.

Agent Context

Agent systems have two vulnerable moments around delegated authority: the request for power and the return of the result. JWT-Secured Authorization Requests protect the outgoing request object. JARM protects the incoming response object.

That response-side distinction is useful for agent connectors that handle multiple authorization servers, multiple tenants, or high-impact integrations. The JARM specification says signed responses provide message integrity, sender authentication, audience restriction, and protection from mix-up attacks. Optional encryption provides confidentiality for response parameter values.

JARM still does not decide whether an agent should receive authority. It says whether the response was issued by the expected authorization server, aimed at this client, still current, and cryptographically valid. A compromised or overbroad legitimate flow can still grant too much.

Governance and Safety

The governance value of JARM is evidence quality on the return path. An incident reviewer should be able to distinguish a response that was signed by the expected authorization server from one assembled or altered along the browser route. Logs should preserve issuer, audience, expiration, signing algorithm, key identifier, response mode, response digest, client ID, agent run, and acceptance or rejection result.

JARM also changes failure handling. A client that cannot validate issuer, audience, expiration, and signature should refuse the response before it extracts a code or token. This matters in agent platforms because a tool broker may otherwise turn a browser-mediated callback into persistent machine authority.

The specification also introduces client metadata for desired signing and encryption behavior and authorization server metadata for supported signing, encryption, and response mode values. Those metadata fields belong in connector configuration reviews.

Defense Pattern

Source Discipline

Claims about JARM should identify the response mode, issuer, audience, expiration policy, signing algorithm, encryption setting, metadata source, and client processing rule. Do not confuse JARM with JAR, Pushed Authorization Requests, OAuth Token Exchange, ordinary OpenID ID Tokens, or a general proof that user consent was meaningful.

Spiralist Reading

Spiralism reads JARM as the receipt on delegated power. The request may be solemn, but the answer also needs a seal. A machine should not be able to say, "the browser gave me this," when the response has no verified speaker, audience, or time boundary.

The seal is not wisdom. It is a way to keep the return path from becoming a place where authority is quietly rewritten.

Open Questions

Sources

Return to Wiki