JAR and JARM close OAuth trust gaps in API authorization flows

At a glance

What this is: This is an analysis of how JAR and JARM harden OAuth 2.0 authorization flows by moving requests and responses into signed JWTs, reducing tampering, leakage, and mix-up risk.

Why it matters: It matters because IAM and API teams need assurance that authorisation intent and response origin stay verifiable across browser-mediated OAuth journeys, especially where third-party access and delegated trust are involved.

Context

OAuth 2.0 often fails at the edges rather than the core. When authorization requests and responses pass through browsers, redirects, proxies, and other intermediaries, the integrity of the flow can be weakened even if the underlying authentication is sound.

JAR and JARM address that gap by protecting the OAuth messages themselves. In practice, that means identity teams are not only validating who is asking for access, but also whether the request and response were altered, spoofed, or exposed while moving through the flow.

For API authorization programmes, this shifts the governance question from simple protocol use to message trust, origin verification, and confidentiality across the authorization boundary.

Key questions

Q: What breaks when OAuth requests and responses are not signed?

A: Unsigned OAuth messages leave intent and origin exposed to tampering, replay, leakage, and response spoofing. The practical failure is not only theft of a code or token, but loss of trust in which party sent the request or returned the response. Signed request and response objects restore that trust at the message level.

Q: Why do JAR and JARM matter if TLS is already in place?

A: TLS protects the transport path, but it does not prove that OAuth parameters stayed intact across browser hops, redirects, and intermediary processing. JAR and JARM add message-level integrity and provenance, which is what identity teams need when the risk is tampering or response confusion rather than simple eavesdropping.

Q: How should teams implement JAR and JARM in delegated access flows?

A: Treat them as required controls wherever OAuth supports sensitive APIs, third-party access, or high-trust authorisation decisions. Enforce signature validation, verify claims before code exchange, and publish key material and response mode expectations so clients can integrate correctly from the start.

Q: What is the difference between PKCE and JAR or JARM?

A: PKCE binds the authorization code exchange to the client instance, while JAR and JARM protect the request and response envelopes themselves. They solve different problems and work best together, because one limits code interception abuse and the others preserve message integrity and provenance.

Technical breakdown

How JAR turns OAuth requests into verifiable request objects

JWT Secured Authorization Request, or JAR, moves OAuth authorization parameters out of exposed query strings and into a signed JWT known as a request object. The client signs the request with its private key, the authorization server verifies the signature with the registered public key, and the server then trusts the parameters only if the JWT checks out. Optional encryption adds confidentiality when the request content itself is sensitive. This changes the security model from browser-visible parameters to authenticated, integrity-protected claims, which is especially relevant when request data traverses untrusted intermediaries.

Practical implication: require signed request objects for flows where request tampering or leakage would undermine authorisation intent.

How JARM secures authorization responses and reduces mix-up risk

JWT Secured Authorization Response Mode, or JARM, wraps the authorization server's response in a signed JWT instead of sending raw code and state values through the browser. The client validates the signature and checks claims such as iss, aud, and exp before using the response. That gives the client a cryptographic basis for deciding that the response really came from the expected authorization server and was not altered in transit. Optional encryption can also hide response contents from browser or network observers. The mix-up defense comes from binding response provenance to the JWT claims rather than trusting URL delivery alone.

Practical implication: validate issuer, audience, and expiry on every JARM response before exchanging codes or accepting errors.

Why signed OAuth messages matter more than transport security alone

TLS protects the channel, but it does not prove that OAuth parameters remained intact across every hop in a browser-mediated flow. JAR and JARM add message-level assurance, which is what identity teams need when the risk includes tampering, replay, redirection, or response spoofing. They also complement PKCE rather than replace it: PKCE binds the authorization code to the client instance, while JAR and JARM protect the request and response envelopes themselves. For modern API authorization, the control boundary is the message object, not just the network path.

Practical implication: treat JAR, JARM, and PKCE as complementary controls and enforce them where OAuth is used for delegated access.

Threat narrative

Attacker objective: The attacker aims to manipulate OAuth authorization outcomes, intercept sensitive parameters, or weaken the trust relationship between client and authorization server.

1. Entry occurs when authorization parameters move through the browser as plain query strings or fragments, giving intermediaries and scripts a chance to observe or alter them.
2. Credential or token abuse follows when a modified request or spoofed response changes the authorization outcome, redirects the flow, or exposes code and state values to attackers.
3. Impact appears as tampered authorization decisions, leaked sensitive request data, or mix-up conditions that break trust in the OAuth exchange.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth trust has shifted from transport integrity to message integrity. JAR and JARM are not simply stronger formatting for OAuth parameters, they redefine what the security boundary is. Once request and response objects can be signed, and optionally encrypted, the identity programme is no longer depending on browser-delivered values staying untouched. The practical conclusion is that API authorization governance must now verify message provenance, not just session continuity.

Browser-visible OAuth parameters create a durable trust gap that PKCE does not close on its own. PKCE binds the authorization code exchange to the client instance, but it does not make the authorization request or response tamper-evident. That leaves a separate governance problem around request intent and response origin. JAR and JARM fill that gap by giving the client and server a cryptographic way to prove what was asked for and what was returned.

Mix-up resistance is an identity integrity problem, not just a protocol compatibility issue. The article shows that JARM's issuer and audience claims, together with signing, are doing governance work by binding the response to the expected party. That matters in federation and third-party access scenarios where response confusion can translate into access misdirection. The implication is that identity teams should treat mix-up defence as part of authorization assurance, not as an optional hardening add-on.

Named concept: authorization envelope integrity. The real control objective here is to protect the request and response envelopes that carry OAuth decisions, not only the channel that transports them. JAR and JARM make that envelope verifiable at each hop, which is why they matter wherever delegated access depends on trust in message origin and content. Practitioners should evaluate OAuth assurance by whether those envelopes are signed and validated end to end.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.

What this signals

Authorization envelope integrity: Identity teams should stop treating OAuth hardening as a single control choice and start treating request and response envelopes as separate trust objects. JAR and JARM matter because they make the authorization boundary verifiable even when the browser path is not.

For programmes that expose APIs to partners or external developers, the practical next step is to decide where signed request objects and signed responses become mandatory rather than optional. That decision belongs in the OAuth operating model, not only in application teams' implementation notes.

For practitioners

• Require signed authorization requests Mandate JAR for OAuth flows where client intent, redirect parameters, or requested scope could be altered in transit or exposed to intermediaries.
• Validate JARM claims before token exchange Check iss, aud, exp, and the JWT signature on every authorization response before accepting the code or proceeding with downstream token issuance.
• Pair JAR and JARM with PKCE Use PKCE alongside JAR and JARM so the code exchange is bound to the client instance while the request and response envelopes remain integrity-protected.
• Document key and metadata onboarding Publish the signing keys, certificates, response modes, and validation expectations that partners and developers need before they integrate OAuth flows.

Key takeaways

• OAuth flows can be tampered with or confused even when authentication is otherwise working, because the request and response objects themselves may still be exposed.
• JAR and JARM move authorization messages into signed JWTs, giving identity teams a stronger basis for validating intent, origin, and integrity.
• The control value is highest where delegated access, third-party integration, or browser-mediated hops make OAuth trust boundaries harder to defend.

Key terms

• JWT Secured Authorization Request: JWT Secured Authorization Request, or JAR, is an OAuth extension that places request parameters inside a signed JWT before they reach the authorization server. It protects request integrity by making the client’s authorization intent verifiable and harder to tamper with in transit.
• JWT Secured Authorization Response Mode: JWT Secured Authorization Response Mode, or JARM, is an OAuth extension that wraps authorization responses in a signed JWT. It lets the client verify that the response came from the expected authorization server and that the message was not altered before acceptance.
• Authorization Envelope Integrity: Authorization envelope integrity is the assurance that OAuth request and response messages arrive unchanged and from the expected party. It is a governance concept rather than a protocol name, and it becomes central when identity teams need to prove message origin, content fidelity, and trust across hops.
• Mix-Up Attack: A mix-up attack is an OAuth confusion flaw where a client talks to more than one authorization server and loses track of which response came from which issuer. The result can be codes or tokens being accepted under the wrong identity, especially when multiple identity providers or tenants are involved.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.