Wiki · Concept · Last reviewed June 25, 2026

OAuth Dynamic Client Registration

OAuth Dynamic Client Registration is the protocol pattern that lets a client register metadata with an authorization server and receive a client identifier before it asks for tokens.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, dynamic registration, client metadata, audit trails

Definition

OAuth Dynamic Client Registration is the Standards Track protocol defined in RFC 7591, OAuth 2.0 Dynamic Client Registration Protocol, by Justin Richer, Michael B. Jones, John Bradley, Marius Machulak, and Phil Hunt. RFC 7591 was published in July 2015. It defines how an OAuth 2.0 client or client developer can send client metadata to an authorization server and receive registration information for later OAuth use.

The central output is a client_id that is unique at the authorization server. Depending on policy, the response can also include registered metadata and client credentials such as a client secret. The request can be unauthenticated, protected by an initial access token, supported by a software statement, or shaped by a deployment-specific profile.

For AI agents, the useful point is administrative fit. Agent clients, local connectors, cloud workflow runners, and tenant-specific tool gateways often appear where manual preregistration with every authorization server is operationally heavy. Dynamic registration gives onboarding a protocol surface instead of leaving it to pasted secrets or improvised forms.

How It Works

RFC 7591 describes a simple flow. The client or developer may obtain an initial access token and may obtain a software statement. It sends a registration request containing desired metadata, and the authorization server returns either a client information response or an error response.

The metadata registry includes fields such as redirect_uris, token_endpoint_auth_method, grant_types, response_types, client_name, scope, contacts, policy_uri, jwks_uri, jwks, software_id, and software_version. For redirect-based flows, OAuth clients must register their redirection URI values, and servers that support dynamic registration for those flows must support redirect_uris.

Software statements are JWTs that assert metadata about client software. RFC 7591 requires a software statement used in registration to be signed or MACed and to contain an issuer claim. If the authorization server trusts the software statement and a metadata name appears both in the statement and in the plain request, the statement value takes precedence.

RFC 8414 later made discovery easier by defining registration_endpoint as optional authorization server metadata. A client can learn the dynamic registration endpoint from the issuer's metadata document when the server publishes that field. RFC 7592, an Experimental RFC published the same month as RFC 7591, extends registration with read, update, and delete operations at a client configuration endpoint; not every authorization server that supports registration supports those management methods.

Agent Context

Agent systems make old OAuth registration problems sharper. A fleet of connectors may need to appear, rotate, and retire across many tenants and resources. Shared credentials make incident response muddy; unconstrained self-registration turns the authorization server into a vending machine for authority.

Dynamic Client Registration sits between those failures. It lets the authorization server decide which client classes can register, which metadata it accepts, which authentication method is allowed, and whether a secret or public-key method is appropriate. It also gives the agent platform a durable record of the client identity used for a connector.

The boundary is important: registration is not user consent, not token issuance, and not proof that a tool action is safe. A registered agent client still needs authorization grants, scopes, audience checks, token controls, and application-level policy before it acts.

Governance and Safety

Governance starts with separating identity evidence from identity claims. A client_name or logo_uri is display metadata, not proof of organizational control. A software_id can identify software across instances, while a client_id is issued by the authorization server. A software statement can carry attested metadata only if the server trusts the issuer.

Audit trails should preserve the issuer, registration endpoint, client_id, accepted redirect URIs, requested and granted scopes, token endpoint authentication method, jwks_uri or JWK thumbprints, software statement issuer and digest if present, initial access token subject if present, timestamp, policy decision, and later RFC 7592 changes.

Practical failures include open registration without rate limits, weak redirect validation, broad default scopes, self-asserted metadata treated as verified identity, prompt-controlled registration URLs, long-lived shared secrets for ephemeral agent clients, abandoned registrations, and updates that silently expand authority.

Defense Pattern

Source Discipline

Claims about OAuth Dynamic Client Registration should identify the authorization server, endpoint, response, client_id, accepted metadata, software statement handling, initial access token policy, and RFC 7592 operations if used. Do not collapse it into OAuth Authorization Server Metadata, OAuth Client ID Metadata Documents, OAuth Protected Resource Metadata, token issuance, or user consent.

Spiralist Reading

Spiralism reads dynamic registration as the bureaucracy of machine identity. Before an agent receives authority, someone has to say what kind of client it is, where it returns users, which keys it controls, who is responsible for it, and how it can be reached.

The ritual is not trust. It is paperwork with protocol teeth. Its value is that the record can be inspected later, especially when an agent action crosses organizations.

Open Questions

Sources

Return to Wiki