Wiki · Concept · Last reviewed June 25, 2026

OAuth Attestation-Based Client Authentication

OAuth Attestation-Based Client Authentication is a work-in-progress OAuth extension for proving that a particular client instance holds a key bound to attested properties, not merely that it knows a client identifier.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, attestation, client authentication, audit trails

Definition

OAuth Attestation-Based Client Authentication is an active IETF Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-09, by Tobias Looker, Paul Bastian, and Christian Bormann. The version reviewed here was published on May 26, 2026 and expires on November 27, 2026. It is work in progress, not an RFC.

The draft defines an OAuth 2.0 extension that lets a client instance present a key-bound attestation when interacting with an authorization server or resource server. The attestation is issued by a client attester and is bound to a key held by the deployed client instance. The client then proves possession of that key.

For AI agents, this matters because a client may be a local app, hosted workflow, browser extension, connector, sandbox, or tool gateway. The governance question is not only "which client name is this?" but "which deployed instance is requesting authority, under which attested properties, and with which proof key?"

How It Works

The draft separates several roles. A Client Instance is a deployed instance of client software. A Client Attester authenticates that instance and issues a Client Attestation JWT. An authorization server or resource server later validates the attestation and the proof that the instance controls the bound key.

A typical flow begins with the client instance generating an asymmetric Client Instance Key. The instance asks the client attester for a Client Attestation JWT. If the attester accepts the instance, it signs an attestation whose claims include the OAuth client identifier and confirmation material for the public key. The client then sends the attestation with either a Client Attestation Proof of Possession JWT or a DPoP proof.

The receiving server checks the attestation signature, expiration, required claims, local trust policy for the attester, and the proof that the presented key matches the key in the attestation. The draft also defines challenge handling, replay-oriented checks, error codes, and authorization server metadata values for supported attestation methods.

Agent Context

Agent platforms increasingly run code in many places: desktop copilots, cloud sandboxes, IDE agents, browser agents, background workers, and tool gateways. A token request from any one of those environments can look similar at the OAuth layer unless the server has instance-level evidence.

Attestation can help distinguish a managed enterprise agent runtime from a copied client ID, a known sandbox from an unknown host, or an approved connector from a script impersonating one. It also gives incident response a better handle on which instance asked for authority when the audit trail later matters.

But attestation is not a safety proof. A correctly attested client can still execute a harmful instruction, request too much authority, or be manipulated through prompt injection. Attestation speaks to instance provenance and key possession. It does not decide whether the task is wise, authorized by the user, or proportionate to the goal.

Governance and Safety

The governance value is narrower than identity and stronger than a label. Attestation gives a server evidence about a deployed instance, the attester that vouched for it, and the key that ties the instance to a request. It can be used as the OAuth client authentication mechanism or as an additional security signal beside another method.

Audit trails should preserve the attestation issuer, accepted attester trust path, client identifier, client instance evidence where available, key thumbprint or confirmation material, proof mechanism, audience, challenge or nonce result, receiving endpoint, policy decision, and final token or resource action. Those records should be minimized and retained according to privacy policy, because persistent instance identifiers can also become tracking material.

Failure modes are predictable: trusting too many attesters, accepting stale attestations, skipping replay checks, ignoring audience mismatches, treating attestation as user consent, or letting model-generated code choose security endpoints. The control is useful only when authorization policy says what attestation evidence is required and what happens when it fails.

Defense Pattern

Source Discipline

Claims about OAuth Attestation-Based Client Authentication should identify the draft version, attestation JWT, proof mechanism, attester trust policy, receiving server, and whether the evidence is used at the authorization server or the resource server. It should not be confused with OAuth Client ID Metadata Documents, sender-constrained tokens, OAuth Token Exchange, general device attestation, or a legal conclusion that a user consented.

Spiralist Reading

Spiralism reads client attestation as a small institutional demand: before authority moves, the machine should show what kind of instance it is and prove continuity with the key named in that claim.

That receipt is not moral intent. It is evidence about origin, state, and possession. A serious system checks it, limits what it can authorize, and remembers why it accepted or rejected the request.

Open Questions

Sources

Return to Wiki