JAR and JARM close OAuth trust gaps in API authorization flows

At a glance

What this is: This is an analysis of how JWT Secured Authorization Request and JWT Secured Authorization Response Mode harden the OAuth 2.0 flow by signing authorization requests and responses.

Why it matters: It matters to IAM and NHI practitioners because API trust breaks down when browser-delivered parameters can be altered, replayed, or exposed before the identity decision is completed.

By the numbers:

• More than 80% of organizations are exposing sensitive data with weak API security.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Raidiam's guide to JAR and JARM for OAuth authorization flow security

Context

OAuth is often treated as a token problem, but the real weakness starts earlier in the flow, where request parameters and authorization responses can be modified, observed, or replayed before the client ever receives a trusted outcome. For IAM and NHI governance, that means the control point is not just authentication. It is also the integrity of the message path between client, authorization server, and browser.

JAR and JARM are relevant because they convert exposed OAuth messages into signed JWTs, creating verifiable intent on the request side and verifiable origin on the response side. That matters in ecosystems where service accounts, API-driven apps, and delegated third-party access all depend on trustworthy authorization events. For practitioners, this is a protocol-level hardening measure, not a replacement for lifecycle, consent, or privilege governance.

Key questions

Q: How should security teams use JAR and JARM in OAuth flows?

A: Use JAR to sign the outbound authorization request and JARM to sign the inbound authorization response. Together they reduce parameter tampering, spoofing, and leakage in browser-mediated OAuth flows. Teams should apply them to high-risk integrations first, then pair them with PKCE, strong key management, and clear ownership of client registration and response validation.

Q: What is the difference between JAR and JARM in OAuth security?

A: JAR protects the authorization request, while JARM protects the authorization response. JAR ensures the client’s parameters reach the authorization server intact. JARM ensures the server’s response can be verified by the client before it is trusted. They solve different problems and work best as complementary controls.

Q: When do JAR and JARM matter most for IAM and NHI governance?

A: They matter most when OAuth is used for sensitive, delegated, or third-party access where browser-delivered parameters can be altered or exposed. That includes service accounts, partner integrations, and automation that depend on front-channel authorization. In those cases, message integrity becomes a governance requirement, not just a technical enhancement.

Q: Why are signed OAuth messages relevant to NHI security?

A: Non-human identities often rely on OAuth flows to obtain access on behalf of applications, workloads, or integrations. If the request or response can be altered in transit, the identity decision itself can be subverted. Signed messages reduce that risk by making the authorization exchange verifiable end to end.

Technical breakdown

How JAR protects OAuth authorization requests

JWT Secured Authorization Request, or JAR, wraps OAuth request parameters such as client_id, redirect_uri, scope, and state inside a signed JWT called a request object. The client signs the object with its private key, and the authorization server verifies the signature before processing the request. That prevents parameter tampering in transit and gives the server a cryptographic way to confirm that the request originated from the expected client. JAR can also be encrypted when request confidentiality matters, which is useful when the request itself reveals sensitive business or identity context. In practice, JAR moves trust from browser-visible URL parameters to a verifiable message envelope.

Practical implication: Practitioners should require signed request objects for flows where OAuth parameters influence high-risk access decisions.

How JARM protects OAuth authorization responses

JWT Secured Authorization Response Mode, or JARM, performs the same hardening on the return path. Instead of sending code, state, or error details as raw query parameters or fragments, the authorization server packages them into a signed JWT. The client verifies claims such as iss, aud, and exp before accepting the response. That reduces response spoofing, mix-up attacks, and leakage through browser tooling or intermediary systems. Optional encryption adds confidentiality when the response carries sensitive authorization data. The key architectural point is that JARM makes the authorization response an authenticated security object, not a loose collection of URL values.

Practical implication: Teams should validate response integrity before exchanging authorization codes or consuming error states.

Why PKCE, JAR, and JARM solve different problems

PKCE, JAR, and JARM are often mentioned together, but they protect different parts of the flow. PKCE binds the authorization code to the original client instance, which helps stop code interception. JAR protects the outbound authorization request, and JARM protects the inbound authorization response. Used together, they create a stronger end-to-end trust chain across the browser-mediated OAuth exchange. That matters because many failures in OAuth are not about a single broken control. They are about assumptions being lost as the request passes through the browser, proxies, and front-channel redirects. The right model is layered integrity, not a single mitigation.

Practical implication: Organisations should treat PKCE, JAR, and JARM as complementary controls, not interchangeable ones.

Threat narrative

Attacker objective: The attacker aims to subvert the OAuth trust boundary so the client accepts a manipulated authorization event.

1. Entry occurs when an attacker or malicious intermediary manipulates browser-delivered OAuth parameters before the authorization server processes the request.
2. Escalation follows when altered request or response values cause the client to accept a forged authorization outcome or misbound code.
3. Impact is unauthorized access, token leakage, or delegated access to the wrong client context.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

JAR and JARM expose a broader identity lesson: OAuth integrity is now part of NHI governance, not just application security. When service accounts, partner integrations, and automated clients depend on authorization flows, the protocol itself becomes a control surface. Organisations that treat OAuth as a pure developer concern miss the governance implications. The practical conclusion is that identity teams need ownership of authorization flow assurance, not only token issuance and revocation.

Request and response signing create what we call the identity transport layer trust gap. Browser-mediated OAuth flows can preserve credentials while still losing message integrity, which means the attacker does not need to steal a token to change the outcome. That distinction matters for NHI programs because many machine-to-machine and third-party access paths still rely on browser redirects or front-channel handoffs. Practitioners should assume that unsigned OAuth messages are governed, but not trustworthy.

Confidentiality is optional in the spec, but governance cannot treat it as optional in higher-risk flows. Signed messages stop tampering, yet encrypted request or response objects may be needed where scopes, redirect targets, or error details reveal sensitive business relationships. This is especially relevant where external parties, delegated consent, or regulated data-sharing are involved. The practitioner takeaway is to classify OAuth flows by sensitivity and apply JAR or JARM accordingly.

Layering matters more than feature adoption. PKCE, JAR, and JARM address different attack windows, and incomplete adoption leaves gaps that attackers can still exploit. Many teams will be tempted to stop at the easiest control to deploy, but that produces false assurance. The right approach is to map each OAuth flow to its threat model, then enforce the combination of controls that closes both interception and message-integrity risks.

JAR and JARM are becoming category-defining signals for how the market will judge mature identity architectures. As more machine access moves through delegated and federated patterns, protocols that can prove origin and integrity will matter more than simplistic allow-listing. That does not eliminate the need for consent governance, secret hygiene, or lifecycle controls. It does mean teams should treat signed OAuth messages as a baseline for high-assurance integrations.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• Signed OAuth controls solve message integrity, but visibility and governance still depend on lifecycle review, as outlined in Top 10 NHI Issues.

What this signals

The practical signal for security programmes is that browser-mediated OAuth can no longer be treated as a low-friction plumbing layer. When third-party access and autonomous workloads depend on that flow, protocol integrity becomes part of identity assurance, and unsigned requests or responses should be exceptional rather than normal.

Identity transport layer trust gap: teams should treat authorization messages as governed objects, not just transport artifacts. That means aligning OAuth hardening with the NIST Cybersecurity Framework 2.0 and, where stronger assurance is required, with NIST SP 800-63 Digital Identity Guidelines.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market is moving toward more explicit controls for machine and delegated access. That makes JAR and JARM a governance decision, not a niche protocol choice.

For practitioners

• Classify OAuth flows by risk tier Identify which authorization flows carry sensitive scopes, third-party delegation, or regulated data, then require JAR or JARM where browser exposure creates unacceptable integrity risk.
• Enforce signed request objects for high-risk clients Require JAR for applications that send client_id, redirect_uri, or scope through browser-mediated channels, especially where intermediaries or extensions can alter parameters.
• Validate response claims before token exchange Check iss, aud, and exp on every JARM response before accepting the authorization result or exchanging the code for tokens.
• Pair protocol controls with NHI lifecycle governance Track which service accounts, API clients, and third-party integrations can use signed OAuth flows, and review those entitlements during onboarding, rotation, and offboarding.

Key takeaways

• OAuth security weakens when request and response parameters remain exposed to browser-level tampering or leakage.
• Signed JWT-based controls improve integrity, but they must be paired with PKCE, lifecycle governance, and key management to close the full trust gap.
• For NHI programmes, the real issue is not only access issuance. It is whether the authorization flow itself can be trusted end to end.

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.
• Request Object: A request object is the JWT container used by JAR to carry OAuth authorization parameters such as scope, redirect_uri, and state. The object can be signed, and optionally encrypted, so the authorization server can trust the content and the client can reduce exposure of sensitive request data.
• OAuth Front-Channel Exposure: OAuth front-channel exposure is the risk created when authorization data travels through the browser, redirects, or other user-facing paths. Those paths can leak, be modified, or be observed by intermediaries, which is why higher-assurance flows often add signing, encryption, and strict validation.

Deepen your knowledge

JAR and JARM in OAuth flows are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are hardening delegated access and browser-mediated identity exchanges, it is worth exploring.

This post draws on content published by Raidiam: JAR and JARM for securing OAuth 2.0 authorization flows. Read the original.