A software agent can suggest, prepare or initiate a tool connection, but it must not turn a human authorization flow into an unreviewed permission grant. OAuth JWT-Secured Authorization Request, known as JAR, gives a client a way to package authorization-request parameters in a cryptographically protected Request Object. Under RFC 9101, the object is signed, or signed and then encrypted, so the authorization server can validate a coherent request rather than trusting scattered browser-visible query parameters.
The practical answer is to identify the human, client, authorization server, redirect endpoint and permission request as separate actors and values. Construct the Request Object from a reviewed set of parameters; sign with a client-associated key; validate the object at the server; reject incompatible or unexpected parameters; and continue with ordinary OAuth and human-consent controls. JAR is not an access token and does not itself give a model permission to act.
The series title describes engineering of agent systems, not proof that artificial superintelligence exists. Today’s tools can automate preparation and orchestration of permission requests. That makes their boundaries more important, not less. A mistaken scope or altered callback can give an ordinary program a serious security problem even when no advanced artificial intelligence is involved.
Contents
What JAR protects and what it cannot promise
↳ The OAuth actors in a controlled workflow
↳ Issuer and audience are not decorations
↳ Client identity and registered redirect destinations
Signed, encrypted and nested JWT forms
↳ Algorithms and cross-JWT confusion
JAR by value: the request parameter
↳ Why duplicate parameters deserve a dedicated test
JAR by reference: the request_uri parameter
↳ Entropy and reference lifetime by the numbers
JAR and PAR solve related but different problems
↳ A transaction boundary the agent must not cross
Expiration, time and replay boundaries
An end-to-end illustrative authorization case
↳ Failure case: the agent asks for too much
↳ Failure case: a valid key signs the wrong audience
↳ Failure case: the outer URL modifies the scope
Why logs must not become a credential leak
↳ Operational metrics with meaningful denominators
Testing the entire validation boundary
↳ Testing wrong-purpose tokens
Diagnostics and repair when authorization fails
↳ Depth, load and transfer probes
A changed-context transfer problem
↳ A second transfer problem: signed but overprivileged
Implementation limitations and deployment boundaries
↳ Questions about failures and scope
Verified sources and related paths
What JAR protects and what it cannot promise
An ordinary authorization request may convey values such as client_id, response_type, redirect_uri, scope, state and PKCE parameters through a browser redirect. These are meaningful instructions. If an attacker or an intermediary can tamper with them without detection, the server may receive a request that differs from what the client intended. A signed Request Object binds the chosen claims cryptographically to a key the authorization server associates with the client.
A signature answers an integrity and provenance question: did the protected request come from a holder of the appropriate signing key without alteration? It does not prove that every requested permission is appropriate, that a human freely consented, that the resource server will enforce limits correctly, or that the agent’s future actions will be safe. Those require separate policy, authorization and execution controls.
Encryption is different again. Signed JAR protects claims from undetected changes, while JWE encryption can protect sensitive details from observers who might see the object. RFC 9101 allows a signed object or a signed-and-encrypted object, with signing before encryption. Sending sensitive data in plain signed claims merely because the signature verifies would confuse integrity with confidentiality.
The OAuth actors in a controlled workflow
A resource owner is the person or entity whose resources are involved. The client is the application asking for authorization. The authorization server authenticates the user and handles the authorization transaction. The resource server later receives access-token-bearing requests and protects the actual resources. An agent may operate inside the client application, but that placement does not merge these separate trust roles.
For example, an assistant helping a teacher connect a calendar could prepare a request for read-only access. The application remains responsible for generating legitimate OAuth parameters, the authorization server remains responsible for validation and consent, and the calendar API remains responsible for token and scope enforcement. A natural-language sentence such as “organise next week’s schedule” is not a substitute for any of those steps.
A useful architecture records who requested the connection, what capability was proposed, which client configuration authorizes the request, and whether a person approved the precise scope. The agent’s planning output should never be treated as a privileged source for cryptographic keys, redirect allowlists or arbitrary authorization-server endpoints.
Inside the JWT Request Object
A Request Object is a JSON Web Token whose claims carry OAuth authorization-request parameters. The standard’s example includes values for issuer, audience, response_type, client_id, redirect_uri, scope and state, with optional extension values such as nonce and max_age. A production system constructs this claims set from configuration and transaction state, not from free-form text copied from a web page or generated without validation.
The Request Object must contain the authorization parameters needed to process the request, apart from the special outer request and request_uri parameters. The client_id inside the JWT must agree with the client_id in the outer authorization request. Even if the outer URL repeats a scope or redirect_uri value for compatibility, an RFC 9101 authorization server must use the Request Object’s protected values rather than treating the outer duplicate as authoritative.
It is helpful to think of the signed JWT as the envelope carrying a complete, reviewable instruction set. The server still has to open the envelope safely, identify the signer, validate required claims and check the request against client registration and security policy. An envelope with a valid seal can contain a request the recipient should still refuse.
Issuer and audience are not decorations
RFC 9101 says that a signed Request Object should include iss and aud, with aud normally set to the authorization server’s issuer identifier. In a tightly controlled deployment, make issuer and audience validation part of the server’s profile and documented policy. The issuer identifies the claimed origin of the JWT, while the audience says which recipient the claims are intended for.
Imagine two authorization servers: one serving a test environment and one serving the real account system. A request intended for the test server must not silently acquire meaning on the production server because both accept the same signing algorithm. The audience separates those contexts. A validated audience claim is one important barrier against cross-service JWT confusion; it does not replace client identification or all other OAuth checks.
If a deployment supports multiple issuer aliases or endpoints, use documented, explicit comparison rules rather than fuzzy string matching. The OAuth server’s discovery metadata is a source for the expected issuer and capabilities. Avoid normalising away differences that actually distinguish separate trust domains. Where a specification permits flexibility, narrow it deliberately in the local security profile.
Client identity and registered redirect destinations
The outer client_id identifies the OAuth client in the authorization exchange, while the claim inside the signed object should agree with it. A signature made by an unrelated key must not be accepted merely because the JWT header presents a familiar key identifier. The server needs a verified association between the client and the key used to check the signature.
Redirect destinations determine where the browser returns after the authorization flow. In a hypothetical application, https://calendar.example.test/callback might be registered. A generated request for https://calendar-attacker.example.test/callback is not acceptable just because the text resembles the expected hostname. The actual server’s exact redirect validation rules must be enforced independent of the agent’s narrative.
Do not insert a previously unseen redirect URI because an assistant argues it is more convenient. Client registration and approved deployment configuration are the authority for callback addresses. Where RFC 9126 PAR introduces additional possibilities for authenticated per-request redirects, implement only the circumstances and checks that standard and local policy actually permit.
Signed, encrypted and nested JWT forms
JWS signing provides an integrity-protected JWT. JWE encryption protects the payload’s confidentiality. RFC 9101’s encrypted construction is a nested JWT: sign the request object first, then encrypt the signed result. At the authorization server, successful decryption reveals a signed object that must still pass signature validation. Decrypting without verifying the signature is not equivalent to accepting a compliant JAR request.
A design review should list what each layer proves. The outer encrypted container helps limit disclosure of sensitive claims to the intended decryptor. The inner signature associates the protected instruction set with the client. TLS protects transport channels. None of these replaces authorisation policy or the user consent screen, and no single layer provides a general guarantee against all token theft or user deception.
If the authorization-request parameters do not contain confidential details and exposure risks are acceptable, a signed-only design may be suitable. If claims include sensitive personal or transaction information, assess whether encryption or a server-side pushed-request mechanism is required. The right choice depends on threat model, metadata support, client capabilities and data minimisation, not on which acronym sounds stronger.
Algorithms and cross-JWT confusion
A JWT header can specify an algorithm and sometimes a kid key identifier. The receiver must not let untrusted header values choose arbitrary algorithms or unrelated keys. RFC 9101 directs signature validation through the JWS specification and the JWT Best Current Practices in RFC 8725. Configure acceptable algorithms and establish a trusted mapping from client to verified key material.
Consider a service that accepts tokens for authentication, signed software statements and OAuth Request Objects. All may resemble three-part JWT strings, but their meanings are different. Treating a signed access token as if it were an authorization request is a cross-JWT confusion failure. Distinguish token purposes by context, expected claims, keys and, where appropriate, explicit type indicators.
A responsible test suite must include wrong alg, unknown kid, mismatched client_id, valid signature from another client, wrong audience and a token of the wrong purpose. Each should fail closed. A successful parse is only the beginning of validation: base64url decoding, JSON parsing and cryptographic verification are different stages with different error modes.
JAR by value: the request parameter
In the by-value mode, the browser-facing authorization request carries the signed JWT in a request query parameter. This gives the server the Request Object itself, avoiding the need to retrieve a separate object over the network. Because the JWT can be lengthy, URL size, exposure in logs and browser history, and intermediary behaviour need attention. Do not print full signed requests into analytics logs by default.
The client must include the complete authorization instruction set inside the signed claims. RFC 9101 allows some duplicates in the outer query parameters for backward compatibility but requires a compliant server to use the protected object. If an attacker changes only the unprotected scope from read-only to read-write, a server enforcing the rule continues to process the signed scope rather than the replacement.
A careless implementation might merge the outer parameters into the verified object, letting the last parsed value win. That defeats the meaning of the signature. Maintain a strict division between data used to route the request and data used to decide what authorisation was requested. Tests should demonstrate the outcome when the two disagree.
Why duplicate parameters deserve a dedicated test
Construct an illustrative signed Request Object whose scope is calendar.read, then add an outer scope=calendar.write. The expected secure behaviour is not to silently broaden the request. The authorization server must derive authorization parameters from the verified object, check the inner and outer client_id match, and reject any request that fails its policy checks.
An inverse mismatch is equally useful: signed calendar.write but outer calendar.read. A server that chooses whichever parameter happens to look narrower may still be doing the wrong thing, because it has created an undocumented merge rule. The correct semantics are determined by the verified Request Object and the server’s explicit validation rules, not by an improvised ranking of values.
Record this as a reproducible test case with fictional clients and inert domains. Do not point tests at real third-party account providers or use actual bearer tokens in fixtures. Automated checks should assert the parsed, validated request fields and the final denial or consent behaviour without relying on a brittle string search in logs.
JAR by reference: the request_uri parameter
The second route passes a reference through request_uri. The server obtains the Request Object from the referenced resource, or from its own trusted storage if the reference was issued through an appropriate mechanism. For an externally supplied reference, RFC 9101 specifies HTTPS and additional retrieval constraints. A reference is not a licence for arbitrary network fetching.
An externally hosted Request Object creates operational questions: which hosts may serve objects, how the server validates TLS identity, how redirects are handled, how much data can be fetched and how long the object remains valid. A backend allowed to fetch any URL named by a browser could become a server-side request-forgery pathway. Strict host and scheme policies matter.
Where the server itself issues an opaque reference to previously accepted request data, its storage and expiry rules become part of the trust boundary. A guessed or replayed reference should not grant broad access. References must not be used as permanent public identifiers for a person’s authorisation activity.
Entropy and reference lifetime by the numbers
Suppose a hypothetical request reference uses 128 independent uniformly random bits. There are 2^128 possible values, approximately 3.4 × 10^38. If an attacker could make one billion independent guesses during its validity window, the chance of guessing one specific reference would be roughly 10^9 ÷ 2^128, or 2.9 × 10^-30 under this simplified model. This illustrates the scale of an appropriate random identifier, not a substitute for rate limits or network controls.
Real systems can still fail because references are leaked into logs, reused across people or accepted after expiry. A weak random generator or predictable timestamp prefix can dramatically reduce effective entropy. For sensitive external request references, RFC 9101 discusses short validity and strong entropy, including a general guidance example of under a minute and 128 random bits in its privacy considerations.
Choose expiry based on the actual protocol and human flow. If a reference expires while a person is reading a consent explanation, fail gracefully and start a fresh transaction; do not silently prolong an unsafe reference. Record whether expiry was calculated at issuance or at receipt, and account for bounded clock variation where the relevant profile requires it.
JAR and PAR solve related but different problems
Pushed Authorization Requests, specified in RFC 9126, let a client send authorization parameters directly to a server-side PAR endpoint and receive a short reference for the later browser redirect. JAR specifies the JWT format and cryptographic protection of a request object. They can be combined, but they are not two names for the same mechanism. A site may support PAR with ordinary pushed parameters or a profile requiring signed requests.
JAR addresses authenticated integrity of authorization parameters through a signed object. PAR addresses moving the request payload through a direct backchannel and establishing the corresponding reference. An implementation can benefit from both while still needing proper user consent, PKCE, redirect validation and resource-server token enforcement. Using one does not automatically complete the entire security design of the other.
For a detailed explanation of the pushed endpoint, read Agent OAuth PAR — Pushed Requests, Client Binding and Expiring Request URIs. This article deliberately concentrates instead on the signed Request Object’s construction, recipient binding, verification and error handling.
A transaction boundary the agent must not cross
An agent may be instructed, “Connect our reporting app to my drive account.” It can propose a narrow file-reading scope, explain why the scope is needed and prepare the application workflow. It should not choose an unrestricted scope merely because doing so might make a future task easier, and it cannot substitute its generated explanation for the resource owner’s authorisation decision.
The user should see the actual authorization server’s consent and grant details through a genuine flow. The application should bind the initiation and the response to the correct browser session using state and other relevant protections. The authorization server and client should reject attempts to reuse a completed transaction or attach the response to a different initiating user.
A safe architecture makes it straightforward for a person to decline, cancel or revoke access later. Audit records should describe proposed permissions, approved permissions and later API actions separately. A cryptographic request signature is useful evidence of what the client asked for; it is not evidence that every downstream action was endorsed.
Expiration, time and replay boundaries
JWT formats can carry timing claims such as exp, nbf and iat. A server can use its documented profile to enforce a bounded acceptance period, account for constrained clock skew and reject expired or not-yet-valid requests. Do not invent a universal JAR lifetime from a particular product’s configuration; verify the authorization server’s published requirements and the deployed policy.
Replay deserves separate attention. A valid signed object may still be copied and presented again unless the surrounding transaction, optional identifiers and server policy prevent an unwanted repeat. A unique jti with appropriate replay tracking can be part of a specific local design, but it should not be misrepresented as a universal mandatory JAR field. PKCE, state, nonce where relevant and one-time reference controls protect different portions of the overall flow.
A server may see legitimate retries caused by network loss or a user refreshing a browser. Its behaviour should be specified and tested rather than guessed. The goal is to prevent an old or altered authorization transaction from being accepted as a fresh independent grant, without creating confusing failures that tempt operators to disable verification.
A checked timing example
Imagine an application issues a signed Request Object at 10:00:00 local time with a policy-defined expiration at 10:05:00. The intended validity span is five minutes, or 300 seconds. An authorization request presented at 10:04:30 arrives 270 seconds after issuance and is within that simple window. One presented at 10:05:30 arrives 330 seconds after issuance and is 30 seconds beyond it.
A real server must evaluate absolute timestamps consistently, typically Unix time, with a precisely documented skew allowance if one is used. A local clock that is 90 seconds wrong can confuse the analysis if tests look only at display times. Record the reference clock, not just a vague human phrase such as “about five minutes later.”
The calculation by itself says nothing about whether a request was already used, whether it has the right audience or whether the user has approved it. Time validity is one necessary gate among several. A system that passes the timing check but fails client identity validation should reject the request.
An end-to-end illustrative authorization case
Consider a hypothetical assistant inside a school’s administrative application. A teacher asks to view available calendar events, not to edit or delete them. The registered OAuth client is school-scheduler; its approved callback is https://school.example.test/oauth/callback; the selected authorization server issuer is https://login.example.test. These are invented documentation domains, not live endpoints.
The client prepares a Request Object containing client_id=school-scheduler, a code flow response type, the registered redirect, a narrowly documented calendar.read scope, state bound to this transaction, and an aud matching the issuer. Depending on the exact provider profile, it also includes appropriate PKCE parameters and timing claims. A protected signing operation creates the JWS; the user is then directed to the expected authorization server.
The server verifies the signature against the key associated with school-scheduler, checks the JWT purpose and claims, compares client IDs, validates redirect and scope policy and authenticates the teacher. The teacher can decline. If consent is granted and the authorization response arrives, the client validates its transaction binding before exchanging an authorization code through the provider’s required flow. The agent receives only capabilities permitted by the resulting connection.
Failure case: the agent asks for too much
Suppose an assistant predicts that future school tasks will require calendar deletion and therefore proposes calendar.read and calendar.delete. That proposal conflicts with the user’s current read-only request. A correctly signed JAR would faithfully protect the overbroad request, not repair it. Cryptographic integrity ensures the request was not changed; it does not prove the original request was appropriate.
The repair is upstream: map natural-language intent to a reviewed scope catalogue, require a narrow default, display the proposed access and obtain explicit human approval where necessary. Policy can forbid high-impact scopes in a low-risk workflow. Tool permissions should be checked again at execution, because a broad access token may remain available even when a specific agent task should not invoke its full capabilities.
This distinction prevents a subtle confidence failure. Teams sometimes assume a security standard means an automated action is automatically safe. Standards reduce particular attack surfaces when correctly implemented. Safety emerges from the whole workflow, including human choices, least privilege, revocation and independent enforcement.
Failure case: a valid key signs the wrong audience
Imagine a JWS produced by the correct application key but carrying an audience for the staging authorization server. The production server should not accept the signed request merely because the key is familiar. It must validate the intended audience under its profile. Without that separation, an object intended for one environment can acquire meaning in another.
The defect can be hidden by poorly configured tests that use the same issuer string or key sets everywhere. Distinct environment identifiers and explicit audience tests make the boundary visible. Review whether the authorization server expects its issuer identifier, a specific endpoint or other documented values according to the protocol in use.
The same discipline applies when one company uses several identity providers for customers, employees and partners. A client signing key does not confer universal authority across all those domains. Treat each issuer, client registration and key association as an explicitly scoped relationship.
Failure case: the outer URL modifies the scope
A signed object says scope=calendar.read, but an intermediary appends scope=calendar.write to the outer authorization URL. A correctly implemented RFC 9101 authorization server uses the verified request object’s scope rather than the outer duplicate. If it takes the more permissive unprotected value, the server’s parsing logic has broken the core integrity guarantee.
A regression test should assert three outputs: the JWT signature still verifies, the effective scope remains calendar.read, and the server records any inconsistent parameters according to its policy. Logging the entire JWT or access token is unnecessary and hazardous; record safe identifiers, classifications and rejection reasons instead. The point is to verify semantics, not expose credentials.
More broadly, the system should never let “helpful” client-side merges override a cryptographic boundary. Library wrappers, API gateways and framework middlewares may normalise query parameters in unexpected ways. Integration tests should exercise the complete request path rather than only a signing function in isolation.
Why logs must not become a credential leak
Authorization requests can include state, nonce, identity hints and sensitive application details. Some may not be bearer credentials by themselves, but indiscriminate logging can still reveal identities, relationships or transaction context. A signed JWT is not encrypted. Anyone who obtains it may be able to decode its claims even without possessing the key to alter the signature.
For operational visibility, record whether the signature passed, which client registration was selected, what class of error occurred and how a transaction progressed. Prefer short random correlation identifiers over full objects in routine logs. Apply access controls, retention limits and redaction to any diagnostic records that must contain claim details.
If a reference or token-like value appears in a support ticket, treat it as potentially sensitive rather than publishing it for convenience. Reproduction steps should use fictional request objects and test keys. A good incident report explains the failed validation gate without inadvertently distributing data that could help replay or track real users.
Operational metrics with meaningful denominators
Suppose a service processes 12,000 authorization requests in one day. Of these, 60 fail Request Object validation: 25 invalid signatures, 15 wrong audiences, 10 mismatched client IDs and 10 malformed objects. The total failure rate is 60 ÷ 12,000 = 0.005, or 0.5 percent. The invalid-signature share among failures is 25 ÷ 60 ≈ 41.7 percent.
These rates measure observed validation outcomes, not the prevalence of malicious activity. Clients can make honest configuration mistakes; an attacker can also craft invalid requests. Count unique clients, environments and routes before interpreting spikes. If one malfunctioning test client accounts for 50 failures, the overall count may not describe widespread security pressure.
Be precise about units and time windows. Requests per day, unique transactions per day and individual users per day are different denominators. A retrying browser can cause multiple validation events for one attempt. Dashboards should preserve both request-event counts and deduplicated transaction counts where possible.
Signature keys and rotation
Each client signing key has an identity, supported algorithm and lifecycle. Rotation requires the authorization server to recognise a newly approved key without accepting arbitrary new keys solely because a header supplies a new kid. JWKS distribution and trust establishment are separate from a single Request Object’s validity; keys may need overlap during a planned rotation while old keys are retired safely.
The security engineering questions include who can register or replace a client’s key, how key exposure is detected, whether private keys are exportable, and which request objects remain valid after compromise. Public keys can be distributed, but private signing keys must remain controlled by the legitimate client-side signing environment. Agents should not receive private keys in ordinary prompts or logs.
For the distinct mechanics of algorithm pinning, key selection and key rollover, see Agent JWKS Key Rotation — kid, Algorithm Pinning and Verified JWTs. This JAR guide applies those trust principles to authorization-request claims rather than restating a general JWT verification tutorial.
Testing the entire validation boundary
A useful test matrix starts with a valid baseline object and changes one dimension at a time. Change the signature without changing the payload; try an unrelated client’s signing key; alter the audience; provide conflicting inner and outer client IDs; replace the registered redirect; use an unsupported algorithm; expire the request; and introduce a claim not permitted by local policy. Verify an explicit refusal in every negative case.
Then test interactions. Can a trusted reverse proxy rewrite the host? Does an authentication restart lose the state binding? Does a browser retry reuse an old request reference? Can a malformed nested encrypted object bypass inner JWS validation? Does the server fetch arbitrary third-party hosts when processing external request_uri values? Security behaviour may fail at component boundaries that individual unit tests never cover.
Use inert example clients and synthetic identities. Record exact expected status, OAuth error semantics and observable safe log fields for each test. Tests should also verify the legitimate path, including user cancellation, so a fix does not make normal authorization impossible and encourage unsafe emergency workarounds.
Testing wrong-purpose tokens
A system may handle many kinds of JWTs: identity tokens, access tokens, signed requests, software statements and application session data. A token that is valid for one purpose should not be accepted in another context. Build tests that submit a genuine test identity token where a Request Object is expected and ensure the authorization server rejects it.
The parser may see familiar fields such as iss and aud in both tokens. Those overlaps are not enough. Expected claims, audience semantics, registered client keys, type indicators, endpoint context and allowed algorithms should collectively distinguish the use case. RFC 8725 provides general guidance about preventing substitution and confusion across JWT contexts.
When reviewing an SDK, look beyond whether a helper method is named verifyJWT. Ask exactly what it verifies and what the caller must still check. An API that validates a cryptographic signature but leaves audience, issuer, lifetime or purpose checking to the application can be safe only if the application performs the remaining work.
Diagnostics and repair when authorization fails
A failure should be classified before it is “fixed.” Invalid signature suggests a key association, algorithm or payload modification problem. Wrong audience suggests environment configuration or issuer mismatch. Incorrect redirect points to client registration or transaction construction. Invalid or expired Request Object suggests timing, lifecycle or stale reference handling. A generic retry of the unchanged request may not address any of these causes.
An engineer should first reconstruct the transaction from safe metadata, verify the expected issuer and client registration, and reproduce with test credentials. Then repair the specific configuration or code path and rerun positive and negative tests. Never treat a failed security check as permission to turn off signature validation, widen redirect allowlists globally, or accept unsigned objects just to restore service.
For an automated agent, the correct response to an authorization validation failure is usually to stop the relevant action and show a bounded, understandable explanation. It may offer to start a new approved connection flow. It must not try a series of increasingly permissive scopes, different identity providers or alternate credentials without a legitimate user or administrator decision.
Depth, load and transfer probes
Depth asks whether the implementer understands why signed inner claims take precedence over duplicate outer parameters, and can distinguish JAR from PAR and access tokens. Load asks whether the team can keep those validations correct during peak traffic, retries, key rotations and partial outages. Transfer asks whether the design remains sound when moved from a calendar integration to a document store or when several authorization servers are introduced.
A depth failure often appears as a glossary-only implementation: code uses JWTs but never checks audience or client-key association. A load failure appears when timeouts trigger insecure fallback. A transfer failure appears when a once-correct single-provider assumption is copied into a multi-provider service where the same trust mapping no longer works.
Repair those failure classes differently. Depth needs a smaller explicit threat model and test fixtures. Load needs bounded retries, monitoring, key-rotation rehearsals and fail-closed resilience. Transfer needs fresh issuer, audience, scope and callback maps for the new environment. Publishing a checklist alone does not demonstrate that the system will pass any of those probes.
A changed-context transfer problem
A firm extends an agent from one identity provider to two. Both providers use JWT signatures, but Provider A’s issuer is https://login-a.example.test and Provider B’s issuer is https://login-b.example.test. The agent prepares 400 authorisation attempts in a day, 250 intended for A and 150 for B. During testing, 12 of the 150 B-intended objects incorrectly carry A’s audience. What proportion of B-intended requests has a binding error, and what should the system do?
The error rate within B’s requests is 12 ÷ 150 = 0.08, or 8 percent. Across the combined 400 attempts the error rate is 12 ÷ 400 = 3 percent. Both figures are arithmetically valid but answer different operational questions. The B-specific denominator is more useful for locating the broken environment mapping. Provider B should reject objects that fail its configured audience requirements, regardless of whether A’s key and signature happen to be valid.
The repair is to tie construction to an explicit provider configuration, regenerate affected objects after correcting the audience, and test both A and B with deliberately cross-routed requests. Do not “fix” the problem by allowing every issuer string at every endpoint. The changed-context lesson is that cryptographic validity must remain bound to the intended recipient.
A second transfer problem: signed but overprivileged
An assistant originally helps archive documents with scope=documents.read. Later a team adds an automated retention workflow and wants documents.delete. The developer updates a single shared configuration so that every signed authorization request now includes both scopes. Signature checks continue passing. Is JAR working correctly? In the narrow cryptographic sense, yes: it protects the new claim set from tampering.
The wider authorization design may nevertheless be wrong. A read-only task still should not receive deletion powers by default. Separate task profiles, require appropriate approval and use downscoped or distinct tokens where the provider supports them. Review downstream audit and confirmation gates before any destructive operation.
This answer is deliberately different from the audience-mismatch case. One failed validation of intended recipient; the other was a potentially unsafe permission request that remained cryptographically valid. Mature agent systems need both controls rather than expecting one technical standard to solve all forms of unwanted action.
Implementation limitations and deployment boundaries
Not every authorization server supports JAR, the same algorithms or every optional parameter. Consult actual server metadata and vendor documentation rather than assuming an RFC number means a feature is enabled in a particular tenant. Profiles can add requirements, restrict methods or mandate PAR. A safe client detects unsupported configurations and fails with a clear explanation rather than inventing a compatible-looking fallback.
A signed Request Object does not remove the need for TLS, PKCE where applicable, redirect checks, state handling, session protection, consent or token lifecycle controls. Its protection is concentrated on the authorization request parameter set. It does not provide reliable proof that an agent’s proposed task is ethical, necessary or within the user’s intention, and it does not guarantee subsequent tool calls are harmless.
Complexity has a cost. Key management, encryption, reference retrieval and error handling introduce additional operational work. For a low-risk integration supported by a simpler secure OAuth profile, JAR may not be essential. For high-assurance workflows it may be required by the relevant profile. The design decision belongs to a documented threat model and provider capabilities.
Frequently asked questions
Does a signed Request Object replace user consent? No. It verifies the integrity and approved source of authorization-request claims; the authorization server still authenticates the user, applies policy and manages consent where required. Can an LLM generate a signed JWT on its own? A model can format a proposed claim set, but a trusted cryptographic component using protected key material should perform signing under reviewed application policy.
Is JAR the same as DPoP? No. DPoP demonstrates possession of a key during certain token and resource requests; JAR protects the parameters of an OAuth authorization request. They can coexist within a larger design. See Agent DPoP Tokens for the different replay and proof context.
Can JAR eliminate replay attacks? Not alone. Replay resistance depends on transaction binding, timing, reference rules, nonce/state or other profile-specific checks and server policy. Is encrypted JAR always required? RFC 9101 permits signed or signed-and-encrypted Request Objects; confidentiality requirements and deployed profile determine what is appropriate.
Questions about failures and scope
What if the signature is valid but the redirect URI is not registered? Reject the request under client and OAuth validation policy. A cryptographic signature does not override registration. What if a client sends scope both inside and outside? A server implementing RFC 9101 must derive its authorization parameters from the verified Request Object, not from a conflicting outer duplicate.
Should an agent store old signed Request Objects for later use? It should avoid reusing expired or completed authorization transactions and minimise retention of sensitive artifacts. If audit evidence is needed, preserve safe metadata and authorised access to records rather than indefinitely stockpiling replayable objects. Any actual retention rule depends on the provider, policy and applicable law.
How should a system respond when one provider is down? Preserve the separation of trust domains. Queue or report work according to approved operational policy, but do not send Provider A’s requests to Provider B or weaken audience checks merely to keep the workflow moving.
Verified sources and related paths
The normative foundation is IETF RFC 9101, The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request: https://www.rfc-editor.org/rfc/rfc9101.html. Its sections on Request Objects, parameter precedence, validation and security threats support the mechanisms explained here. It is a standard, not evidence that a particular deployment implements every option.
Related primary specifications are RFC 9126 on Pushed Authorization Requests (https://www.rfc-editor.org/rfc/rfc9126.html), RFC 8725 on JWT Best Current Practices (https://www.rfc-editor.org/rfc/rfc8725.html), RFC 8414 on Authorization Server Metadata (https://www.rfc-editor.org/rfc/rfc8414.html), and RFC 7636 on PKCE (https://www.rfc-editor.org/rfc/rfc7636.html).
For a broader engineering pathway see How Super Intelligence Works, then the sibling work on PAR, JWKS and DPoP linked above. All clients, issuer hosts, transaction totals and error rates in this article are labelled teaching examples rather than observed activity. No real authorization server was tested, no production key was accessed and no artificial superintelligence is claimed to exist.