OAuth Dynamic Client Registration Security Guide: Controlling Who Can Register Clients

An open OAuth registration endpoint lets anyone on the internet create a client that your users will see on a consent screen carrying your authorisation server's branding. Dynamic Client Registration (DCR), defined in RFC 7591, was designed so software could register itself without an administrator, and it became the default way MCP clients and AI agent platforms connected to new servers. That convenience comes with impersonation, consent phishing, redirect abuse and registration flooding risks, because almost all registration metadata is self-asserted. This guide explains how DCR and its management extension work, the threats specific to open registration, how to lock registration down with initial access tokens, software statements and policy, and where Client ID Metadata Documents now replace DCR. It is for identity platform owners, API and MCP server operators, and security architects.

Key takeaways

• Self-asserted metadata is the core risk. RFC 7591 notes that unless metadata comes in a trusted software statement, a client can claim any name, logo or URI, including another client's.
• Open registration should be the exception. Require an initial access token or a signed software statement wherever you know who your clients are.
• Constrain what a registered client can do, not just who registers. Enforce exact redirect URIs, allowed grant types, scopes and authentication methods server-side, overriding requested values.
• The registration access token is a long-lived credential. RFC 7592 makes it the only authentication for managing a client, so protect it like a secret and rotate it.
• MCP has moved on. The MCP authorisation specification (version 2026-07-28) marks DCR deprecated and recommends Client ID Metadata Documents, keeping DCR only for backwards compatibility.

How Dynamic Client Registration works

RFC 7591 (Proposed Standard, July 2015) defines a registration endpoint, advertised as registration_endpoint in authorisation server metadata. A client POSTs a JSON document of client metadata over TLS; on success the server returns HTTP 201 with a client_id, optionally a client_secret and its client_secret_expires_at, and the metadata it actually registered. Errors return HTTP 400 with codes such as invalid_redirect_uri, invalid_client_metadata, invalid_software_statement and unapproved_software_statement.

RFC 7591 lets the server ignore unknown metadata, replace requested values with its own defaults, or reject the request. Use that freedom: the registered client should reflect your policy, not the client's wishes.

Managing registered clients (RFC 7592)

RFC 7592 is an Experimental RFC (July 2015), so support varies. It returns a registration_access_token and a registration_client_uri; the client then reads (GET), updates (PUT with the complete metadata, omitted fields deleted) or deletes (DELETE, HTTP 204) its registration. On delete the client ID, secret and registration token are invalidated and the server should revoke associated grants and tokens. The registration access token is a long-term bearer credential and the only authentication for the configuration endpoint, so it must be protected, and the server may rotate it on read or update.

Threats specific to dynamic registration

OWASP ASVS 5.0 requirement V10.4.7 captures the baseline: if the authorisation server supports unauthenticated dynamic client registration, it must mitigate the risk of malicious client applications. In ATT&CK terms the end goal is usually T1528 Steal Application Access Token through a malicious application the user approves.

Locking registration down

Choose a registration mode

Initial access tokens in practice

RFC 7591 leaves the format and issuance of the initial access token to the authorisation server, so design it like any other privileged credential:

• Scope it: one token per partner, tenant or pipeline, limited to a number of registrations and an allowed set of redirect hosts and scopes, so a leaked token cannot register arbitrary clients.
• Expire it: issue tokens for days, not years; onboarding rarely needs more.
• Attribute it: record which token created each client, so every dynamic client has an accountable owner and can be traced in an incident.
• Keep it out of code: store it in a secrets manager, never in client source or public configuration where anyone can reuse it.

Policy controls to apply in every mode

• Override, do not accept: set grant_types, response_types, token_endpoint_auth_method and scope from policy, returning what you registered.
• Software statements: where used, require a JWT signed by an issuer on your trust list; RFC 7591 says values in a trusted statement take precedence over the JSON body. Reject statements from unknown issuers with unapproved_software_statement.
• Consent screen honesty: show dynamically registered clients as unverified, display the redirect host, and never render client_name as if it were verified.
• Sensitive scopes need admins: dynamic clients should only receive scopes a user may grant alone; anything touching mail, files or admin APIs needs administrator approval.
• Lifecycle: expire client secrets (client_secret_expires_at), delete clients with no successful token issuance in a set period, and revoke their grants on deletion.
• Bind credentials to the issuer: the MCP specification requires clients that persist DCR credentials to key them by the authorisation server's issuer and re-register if the server changes, which prevents credential reuse across servers.

DCR in MCP and agent platforms

Earlier MCP authorisation specifications made DCR the way an MCP client obtained a client ID from a server it had never seen, which pushed open registration endpoints into many new deployments. The current specification (version 2026-07-28, checked 27 October 2026) changes the order:

1. Use pre-registered client information if the client has it.
2. Use Client ID Metadata Documents if the authorisation server advertises client_id_metadata_document_supported.
3. Use Dynamic Client Registration as a fallback if the server advertises registration_endpoint.
4. Otherwise prompt the user to enter client information.

The specification states that DCR is deprecated, new implementations should use Client ID Metadata Documents, and authorisation servers and clients MAY support RFC 7591 for backwards compatibility. Clients using DCR with OIDC servers must send an appropriate application_type (native for desktop, CLI and localhost apps, web for remote browser apps). See the MCP Authorisation Specification Guide for the full flow.

Client ID Metadata Documents (draft-ietf-oauth-client-id-metadata-document-02, an active OAuth working group Internet-Draft on the Standards Track, last updated 6 July 2026) replace registration with a URL: the client_id is an HTTPS URL with a path that serves the client's metadata, the document's client_id must match the URL exactly, shared secrets are not allowed, and the authorisation server must not follow redirects and must block fetches to special-use IP addresses. The draft is still changing, so avoid depending on details beyond these. See the OAuth Client ID Metadata Documents Guide.

Where identity fits

Every dynamically registered client is a non-human identity: it holds a client ID, often a secret or key, and receives tokens. Agent platforms can create them faster than anyone reviews them. Include dynamic clients in your NHI inventory with an owner (the registering user, tenant or software statement issuer), and alert when one acquires high-risk scopes. See the Unsanctioned AI Agents and MCP Servers Guide.

Decision guidance

• Workforce identity provider: disable open DCR. Register enterprise applications statically, and use protected DCR only for automation you control.
• Public API or MCP server with unknown clients: support Client ID Metadata Documents first; if you must keep DCR, run it open but with minimal scopes, unverified-client consent screens, rate limits and expiry.
• Partner ecosystem: use software statements from a registry you control, or initial access tokens issued per partner.
• Small organisations: you will rarely need DCR at all; check that your identity provider has it switched off unless a product explicitly requires it.
• Large organisations and platforms: treat the registration endpoint as an internet-facing API with its own threat model, WAF rules, quotas and monitoring.

Implementation and rollout

1. Discover: check every authorisation server's metadata for registration_endpoint and test whether it accepts unauthenticated requests. Many teams discover open endpoints they did not know about, often on test or MCP authorisation servers stood up quickly.
2. Inventory clients: export dynamically registered clients with creation date, creator, redirect URIs, scopes and last token issuance.
3. Clean up: delete clients with no token activity in 90 days and revoke their grants; review any with sensitive scopes.
4. Apply policy in audit mode: log registrations that would be rejected or modified under the new policy for two to four weeks.
5. Enforce: switch on initial access tokens or software statement requirements, server-side metadata overrides and rate limits.
6. Offer the alternative: add Client ID Metadata Document support where your platform and clients allow it, and plan DCR retirement for MCP use cases.
7. Rollback: keep policy changes behind configuration flags so open registration can be restored for a named client population while issues are fixed.

Detection and measurement

Log every registration request with source IP, initial access token or software statement issuer, requested and registered metadata, and outcome. Alert on registrations whose client_name resembles a known application, bursts of registrations from one source, redirect URI changes via RFC 7592, and a new dynamic client receiving consent from many users quickly.

• Open endpoints: number of authorisation servers accepting unauthenticated registration, target zero outside deliberate cases.
• Dormant dynamic clients: clients with no token issuance in 90 days.
• High-risk scope grants to dynamic clients: count per month, each reviewed.
• Policy rejections: registrations rejected or modified, trended to spot probing.
• CIMD adoption: share of MCP client connections using Client ID Metadata Documents rather than DCR.

Framework mapping

Common failure patterns

• Open by default: an authorisation server or MCP server template ships with an unauthenticated registration_endpoint enabled, and nobody notices because no legitimate client ever calls it. Attackers who read the published metadata do.
• Accepting requested metadata as-is: clients register implicit grants, wildcard redirects or broad scopes because the server never overrides them.
• Verified-looking consent for unverified clients: users see a familiar name and logo and approve a malicious client.
• No lifecycle: thousands of dynamic clients accumulate, each a potential token holder, with no owner and no expiry.
• Registration tokens stored in plain configuration: a leaked registration_access_token lets an attacker repoint a trusted client's redirect URIs.
• Building new MCP integrations on DCR: designing around a mechanism the MCP specification now marks deprecated.

Practitioner checklist

• Find every registration_endpoint and test whether it accepts unauthenticated requests.
• Require initial access tokens or trusted software statements wherever clients are known.
• Override grant types, response types, authentication method and scopes from server policy.
• Enforce exact redirect URIs (HTTPS or loopback) and PKCE for public clients.
• Mark dynamic clients as unverified on consent screens and require admin consent for sensitive scopes.
• Rate-limit registration and expire unused clients and secrets.
• Protect and rotate registration access tokens; alert on redirect URI changes.
• Add dynamic clients to the NHI inventory with an owner.
• Prefer Client ID Metadata Documents for new MCP and agent integrations.

Standards and references

• IETF: RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol
• IETF: RFC 7592 OAuth 2.0 Dynamic Client Registration Management Protocol
• IETF: OAuth Client ID Metadata Document (Internet-Draft)
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• Model Context Protocol: Authorization, Client Registration
• Model Context Protocol: Authorization specification
• OWASP: Application Security Verification Standard 5.0

Related NHI Mgmt Group resources: Machine-to-Machine OAuth (Client Credentials) Guide · OAuth Client ID Metadata Documents Guide · MCP Authorisation Specification Guide · Consent Phishing and Illicit OAuth Grants Guide · MCP Security Guide