What is MCP Dynamic Client Registration?

MCP Dynamic Client Registration is an optional OAuth mechanism that allows an MCP client to register programmatically with an Authorization Server and obtain a client identifier without prior manual configuration.

Why does MCP use Dynamic Client Registration?

It allows previously unknown MCP clients to connect to Authorization Servers without requiring users or administrators to create an OAuth client manually for every client-server combination.

Which standard defines Dynamic Client Registration?

OAuth 2.0 Dynamic Client Registration is defined by RFC 7591. Optional registration management operations are described separately by RFC 7592.

Does Dynamic Client Registration issue an Access Token?

No. It normally issues a client identifier and registered client metadata. The client must later perform an OAuth authorization flow to obtain an Access Token for the MCP Resource Server.

Should a desktop MCP client receive a Client Secret?

Usually no. Desktop, command-line, mobile, browser-based, and other distributed MCP clients are public clients and cannot reliably protect a shared Client Secret.

Can an Authorization Server require approval before dynamic registration?

Yes. The registration endpoint may require an Initial Access Token, software statement, administrative policy, or another authorization mechanism before accepting a registration.

What is an Initial Access Token?

An Initial Access Token is an optional credential presented to the registration endpoint to prove that the caller is authorized to create a new OAuth client registration.

What is a Registration Access Token?

A Registration Access Token is an optional credential associated with one registered client and used to read, update, or delete that registration through a Client Configuration Endpoint.

What is the biggest security risk in MCP Dynamic Client Registration?

Major risks include malicious redirect URIs, registration flooding, deceptive client identity, unsafe metadata URLs, inappropriate Client Secrets, unauthorized registration updates, and treating automatic registration as proof that a client is trustworthy.

MCP Dynamic Client Registration: Complete OAuth Guide

Q: Is Dynamic Client Registration required by MCP?

No. Current MCP specifications make Dynamic Client Registration optional and generally prefer preregistered client information or Client ID Metadata Documents when available.

MCP Dynamic Client Registration: Complete OAuth Guide

MCP clients frequently connect to remote MCP servers with which they have no previous relationship.

A desktop AI application may connect to:

a project-management MCP server
an internal document server
a cloud administration service
a customer-specific SaaS integration
a newly installed third-party MCP server

Before the client can begin an OAuth authorization flow, the Authorization Server must know certain facts about it.

These may include:

its client identifier
redirect URIs
client type
supported grant types
response types
token endpoint authentication method
human-readable name
software identity

Traditionally, an administrator registers these details manually.

Dynamic Client Registration allows the MCP client to submit them programmatically.

text

MCP Client
    │
    │ Registration Request
    ▼
Authorization Server
    │
    │ Client Information Response
    ▼
Client ID
Registered Metadata
Optional Client Credentials

The client can then use its new client_id during the OAuth Authorization Code flow.

Quick Answer

MCP Dynamic Client Registration is an optional OAuth mechanism based on RFC 7591. It allows an MCP client to send its metadata to an Authorization Server's registration endpoint and receive a client_id without prior manual onboarding. Current MCP specifications generally prefer preregistration or Client ID Metadata Documents when available, with Dynamic Client Registration used as a fallback or for compatibility with deployments that specifically require it.

Is Dynamic Client Registration Required by MCP?

No.

The current MCP authorization specification supports three client registration approaches:

preregistered client information
Client ID Metadata Documents
OAuth Dynamic Client Registration

When a client supports all three, the recommended priority is:

text

1. Existing preregistered client information
2. Client ID Metadata Documents
3. Dynamic Client Registration
4. User-provided client configuration

Dynamic Client Registration is therefore no longer the default answer for every previously unknown MCP client.

It remains useful for:

compatibility with earlier MCP authorization deployments
Authorization Servers designed around RFC 7591
controlled enterprise client provisioning
per-installation client identifiers
environments requiring server-managed registration state

Current MCP specifications state that clients and Authorization Servers may support RFC 7591 and describe DCR as a fallback after preregistration and Client ID Metadata Documents.

Why MCP Originally Relied on Dynamic Registration

MCP creates an unusually open OAuth environment.

A traditional SaaS provider may know its supported OAuth applications in advance.

It can manually register:

text

Client:
Official Web Application

Client ID:
web-client-123

Redirect URI:
https://app.example.com/oauth/callback

MCP is different.

A remote MCP server may be contacted by:

multiple desktop AI clients
command-line tools
editor extensions
enterprise agent platforms
previously unknown third-party applications
locally installed open-source clients

The Authorization Server cannot necessarily know every client before the first connection.

text

Unknown MCP Client
        │
        ▼
Remote MCP Server
        │
        ▼
Authorization Server

Dynamic Client Registration provides a standard way to establish that missing OAuth client record.

Dynamic Registration Does Not Authorize MCP Access

Registration and authorization are separate processes.

Dynamic registration answers:

Which OAuth client is making this request, and what are its callback and protocol properties?

The later authorization flow answers:

May this client receive access to this MCP Resource Server on behalf of this user?

text

Phase 1:
Register OAuth Client
        │
        ▼
Receive Client ID

Phase 2:
Authorize User Access
        │
        ▼
Receive Access Token

Phase 3:
Call MCP Resource Server

A successful registration must not automatically grant:

MCP Access Tokens
user consent
tool access
elevated scopes
access to internal resources
trusted application status

An Authorization Server may accept a client registration while still denying every subsequent authorization request.

Want to analyze your API security?

Import your OpenAPI spec and generate a Security Report automatically.

The Relevant OAuth Standards

MCP Dynamic Client Registration is primarily based on two OAuth specifications.

RFC 7591

RFC 7591 defines:

the Client Registration Endpoint
registration request metadata
client information responses
registration errors
optional Initial Access Tokens
optional software statements

It is an Internet Standards Track specification for programmatically registering OAuth clients.

RFC 7592

RFC 7592 defines optional management of an existing registration.

It introduces:

Client Configuration Endpoint
Registration Access Token
reading registration metadata
updating registration metadata
deleting a registration

RFC 7592 is an Experimental specification, and an Authorization Server supporting RFC 7591 is not required to support these management operations.

text

RFC 7591:
Create registration

RFC 7592:
Read, update, or delete registration

Dynamic Client Registration Roles

A typical MCP registration flow contains the following roles.

MCP Client

The application requesting an OAuth client registration.

Examples:

desktop MCP host
command-line client
enterprise agent platform
editor extension
server-side MCP client

Authorization Server

The OAuth system operating the registration endpoint and issuing the client_id.

MCP Resource Server

The protected MCP server that the client ultimately wants to access.

The MCP Resource Server may use the same organization or domain as the Authorization Server, but its role is separate.

text

MCP Client
    │
    ▼
Authorization Server
Registration Endpoint
    │
    ▼
Client ID
    │
    ▼
OAuth Authorization
    │
    ▼
MCP Resource Server

Discovering Dynamic Registration Support

The MCP client first discovers the Authorization Server through the MCP Resource Server's Protected Resource Metadata.

It then retrieves Authorization Server Metadata.

If Dynamic Client Registration is supported, the metadata may include:

json

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "registration_endpoint": "https://auth.example.com/register"
}

The presence of registration_endpoint indicates that the Authorization Server advertises an OAuth Dynamic Client Registration endpoint.

Current MCP guidance recommends that a client first use preregistered information when available, then Client ID Metadata Documents when supported, and only then fall back to DCR through the advertised registration_endpoint.

Do Not Guess the Registration Endpoint

The MCP client should not create a registration endpoint by appending guessed paths such as:

text

/register
/oauth/register
/clients
/dynamic-registration

Unsafe:

text

Issuer:
https://auth.example.com

Client guesses:
https://auth.example.com/register

Safe:

text

Authorization Server Metadata:
registration_endpoint =
https://auth.example.com/oauth/register

The endpoint should come from validated Authorization Server Metadata.

This prevents:

incorrect requests
endpoint confusion
accidental credential disclosure
use of undocumented APIs
authorization-server mix-up

Complete Registration Flow

A typical flow looks like this:

text

1. MCP Client contacts protected MCP server

2. MCP server returns:
   401 + Protected Resource Metadata location

3. Client discovers Authorization Server

4. Client retrieves Authorization Server Metadata

5. Client checks registration options

6. No preregistered client information exists

7. Client ID Metadata Documents are unsupported

8. registration_endpoint is advertised

9. Client sends RFC 7591 registration request

10. Authorization Server validates metadata

11. Authorization Server creates client record

12. Authorization Server returns client_id

13. Client begins OAuth Authorization Code flow

Registration should happen before the authorization request that requires the resulting client_id.

Client Registration Request

The client sends an HTTPS POST request containing JSON metadata.

http

POST /register HTTP/1.1
Host: auth.example.com
Content-Type: application/json
Accept: application/json

{
  "client_name": "Example MCP Desktop",
  "redirect_uris": [
    "http://127.0.0.1:43123/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none"
}

The Authorization Server validates the request and decides whether to:

accept the values
replace values according to policy
reject unsupported properties
reject the entire registration
require additional authorization

RFC 7591 defines the registration request as a JSON document containing the client's requested metadata.

Important Registration Metadata

Common fields include:

redirect_uris
client_name
client_uri
logo_uri
scope
contacts
tos_uri
policy_uri
grant_types
response_types
token_endpoint_auth_method
jwks_uri
jwks
software_id
software_version
software_statement

Not every MCP client needs every field.

The Authorization Server should accept only metadata relevant to its supported client model.

Redirect URIs

redirect_uris is one of the most security-critical registration fields.

Example:

json

{
  "redirect_uris": [
    "http://127.0.0.1:43123/callback"
  ]
}

After the user completes authorization, the Authorization Server redirects the browser to one of the registered URIs.

If an attacker can register or substitute a malicious redirect URI, authorization codes may be sent to the attacker.

text

Authorization Server
       │
Authorization Code
       │
       ▼
Registered Redirect URI

The Authorization Server must carefully validate every submitted redirect URI before saving it.

Secure Redirect URI Validation

A registration endpoint should normally:

parse URIs with a trusted standards-compliant parser
require absolute URIs
reject fragments
reject embedded credentials
reject unapproved schemes
reject malformed hosts
enforce HTTPS for remote web clients
apply explicit rules for loopback clients
reject open redirect endpoints
reject wildcard hosts unless a strict profile explicitly permits them
store the exact approved value

Unsafe:

json

{
  "redirect_uris": [
    "https://attacker.example/callback"
  ]
}

Also dangerous:

json

{
  "redirect_uris": [
    "https://trusted.example/callback?next=https://attacker.example"
  ]
}

A syntactically valid HTTPS URI is not automatically a safe or trusted redirect.

Exact Redirect Matching

During the later authorization flow, the requested redirect_uri should match a registered value exactly according to the applicable OAuth rules.

Registered:

text

https://client.example.com/oauth/callback

The Authorization Server should not accept:

text

https://client.example.com/oauth/callback/extra
https://client.example.com/oauth/callback.attacker.example
https://client.example.com/oauth/callback?redirect=attacker
http://client.example.com/oauth/callback

Unsafe matching methods include:

prefix matching
substring matching
suffix matching
unrestricted regular expressions
arbitrary wildcard subdomains

The registration process establishes the allowed callback set. Weak matching during authorization defeats that protection.

Loopback Redirect URIs for Local MCP Clients

Desktop and command-line MCP clients often receive authorization responses through a temporary loopback listener.

Example:

json

{
  "redirect_uris": [
    "http://127.0.0.1:43123/callback"
  ]
}

The listener should bind only to:

text

127.0.0.1

or an appropriately supported IPv6 loopback address.

It should not bind to:

text

0.0.0.0

A secure local callback flow should:

use loopback only
generate an unpredictable state
require PKCE
accept a single response
close immediately afterward
reject unexpected paths
avoid displaying tokens in the browser
prevent remote devices from reaching the callback

Fixed and Variable Loopback Ports

Installed applications may not know which local port will be available before runtime.

An Authorization Server may support loopback redirect policies that allow a variable port while requiring the rest of the URI to match.

Conceptually:

text

Registered pattern:
http://127.0.0.1:{ephemeral-port}/callback

Runtime:
http://127.0.0.1:43123/callback

This must not become a general wildcard mechanism.

Only the loopback port should vary under a narrowly defined native-application policy.

The following should remain fixed:

scheme
loopback host
path
absence of attacker-controlled hostnames

Localhost vs 127.0.0.1

A client may submit:

text

http://localhost:43123/callback

or:

text

http://127.0.0.1:43123/callback

These values should not automatically be treated as identical.

localhost depends on name resolution, while 127.0.0.1 explicitly identifies IPv4 loopback.

Authorization Servers should apply a documented loopback policy rather than performing broad hostname normalization.

A client should register every exact redirect form it intends to use, subject to server policy.

Custom URI Schemes

Some installed applications use callback schemes such as:

text

example-mcp-client:/oauth/callback

Custom schemes may be claimed by another application on the same device.

Potential attack:

text

Authorization Server
       │
       ▼
example-mcp-client:/callback
       │
       ▼
Malicious Application Registered Same Scheme

Where custom schemes are supported:

use application-specific reverse-domain names
require PKCE
verify application ownership where possible
prefer claimed HTTPS redirects or loopback redirects where practical
document operating-system limitations
do not rely on the custom scheme as client authentication

Grant Types

The grant_types field identifies the OAuth grants the client intends to use.

Example:

json

{
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ]
}

For a user-facing MCP client, the common secure model is:

text

authorization_code
refresh_token

The Authorization Server should reject unsupported or dangerous combinations rather than silently broadening the client's capabilities.

A registration request should not be allowed to enable machine credentials, token exchange, device authorization, or other grants unless the deployment intentionally supports them.

Response Types

The response_types field identifies OAuth authorization response types.

For Authorization Code flow:

json

{
  "response_types": [
    "code"
  ]
}

The Authorization Server should validate consistency between grant_types and response_types.

Example:

text

grant_types:
authorization_code

response_types:
code

An MCP client should not request deprecated or unsupported implicit-style response types merely because the registration endpoint accepts arbitrary strings.

Token Endpoint Authentication Method

The token_endpoint_auth_method field tells the Authorization Server how the client intends to authenticate at the token endpoint.

A public desktop MCP client commonly uses:

json

{
  "token_endpoint_auth_method": "none"
}

A confidential backend client may use a supported method such as:

text

client_secret_basic
private_key_jwt
tls_client_auth

The selected method must match the client's actual ability to protect credentials.

Public MCP Clients

Many MCP clients are public OAuth clients.

Examples include:

desktop applications
command-line tools
mobile applications
browser-based clients
editor extensions
distributed open-source clients

These applications cannot reliably keep a shared Client Secret confidential.

text

Application Package
       │
       ├── Installed by User A
       ├── Installed by User B
       └── Downloaded by Attacker

Any embedded secret can potentially be extracted.

A dynamic registration endpoint should not turn a public MCP client into a confidential client merely by returning a client_secret.

Client Secrets for Public Clients

RFC 7591 permits a registration response to contain a Client Secret when appropriate.

However, a secret delivered to a public client should not be treated as strong authentication.

For example, a desktop client may register itself separately on every installation and receive a per-instance secret.

That may provide:

instance correlation
limited protection against accidental misuse
a credential for server-specific policy

It does not necessarily provide:

proof of trusted software
resistance to local extraction
strong application identity
protection against malware on the device

For many public MCP clients, the safer metadata is:

json

{
  "token_endpoint_auth_method": "none"
}

with authorization protected by:

PKCE
exact redirect validation
state
short-lived authorization codes
resource binding

Confidential MCP Clients

A server-side MCP client may qualify as confidential when it can protect credentials.

Examples include:

enterprise agent backend
controlled server application
internal automation platform
private gateway

A confidential client may request or receive credentials such as a Client Secret.

json

{
  "token_endpoint_auth_method": "client_secret_basic"
}

A stronger deployment may prefer asymmetric client authentication:

json

{
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks_uri": "https://client.example.com/.well-known/jwks.json"
}

The Authorization Server should verify that the requested authentication method is suitable and supported.

Client Name

The client_name field is a human-readable application label.

json

{
  "client_name": "Example MCP Desktop"
}

It may be displayed on:

consent screens
client-management pages
audit logs
administrator dashboards

A client-provided name is not verified identity.

An attacker may register:

json

{
  "client_name": "Official Corporate AI Client"
}

The Authorization Server should distinguish between:

self-asserted name
domain-verified identity
administratively approved client
publisher-verified software
first-party client

Consent screens should not present unverified names in a way that implies endorsement.

Client Logo and Human-Readable URLs

Optional fields may include:

json

{
  "client_uri": "https://client.example.com",
  "logo_uri": "https://client.example.com/logo.png",
  "policy_uri": "https://client.example.com/privacy",
  "tos_uri": "https://client.example.com/terms"
}

These fields improve usability but introduce risks.

A malicious client may use:

copied branding
misleading domains
tracking images
oversized responses
malicious content types
internal URLs
redirect chains
frequently changing content

The Authorization Server should not retrieve arbitrary remote images or documents without SSRF protections.

Safer options include:

displaying links without server-side fetching
proxying images through a hardened fetcher
requiring verified domains
restricting content types
limiting response size
caching approved assets
removing active content

Contacts

The client may provide administrative contact addresses:

json

{
  "contacts": [
    "security@client.example.com"
  ]
}

Contacts may be used for:

security notifications
client approval
incident response
deprecation notices
policy violations

The address is self-asserted unless separately verified.

Do not expose contact details publicly without a legitimate need.

Requested Scope

A registration request may include a default scope:

json

{
  "scope": "documents:read documents:write"
}

This does not grant the scope.

It may represent the client's expected or default authorization request.

The Authorization Server should:

reject unknown scopes
avoid granting scopes at registration time
require user or administrator authorization later
prevent broad defaults from bypassing incremental consent
distinguish supported scopes from approved scopes

Registration metadata should not become a mechanism for silently authorizing destructive MCP tools.

Software ID and Version

A client may provide:

json

{
  "software_id": "8f1f7c20-71a4-4f35-b511-77f70c231f22",
  "software_version": "3.4.2"
}

These fields can help the Authorization Server identify a software product across multiple installations.

They may support:

compatibility policy
deprecation
risk evaluation
version-specific restrictions
incident response

They are not cryptographic proof of software identity.

A malicious client can copy the same values unless they are bound to a trusted software statement or another verification process.

Software Statements

A software statement is an optional signed assertion describing client software.

Conceptually:

text

Software Publisher
       │
Signs Software Metadata
       │
       ▼
Software Statement
       │
       ▼
Dynamic Registration Request

The registration request may contain:

json

{
  "software_statement": "eyJhbGciOiJSUzI1NiIs..."
}

The Authorization Server may use the statement to determine:

software publisher
approved redirect URIs
client type
permitted authentication method
software identifier
policy tier

RFC 7591 defines software statements as optional inputs whose trust and validation are determined by the Authorization Server.

Software Statements Are Not Automatically Trusted

A signed software statement is useful only when:

the signer is trusted
the signature is verified
the claims are validated
the statement is unexpired
the intended Authorization Server is considered
replay policy is defined
conflicting registration metadata is handled safely

Unsafe:

text

Any validly signed statement
       │
       ▼
Automatically trusted

Safe:

text

Trusted issuer?
Valid signature?
Expected audience?
Approved software?
Claims match request?

The Authorization Server must define whether statement claims:

override client-submitted metadata
restrict client-submitted metadata
must match exactly
act only as supporting evidence

Open Registration

An Authorization Server may allow registration without any initial credential.

text

Unknown Client
      │
      ▼
Public Registration Endpoint
      │
      ▼
Client ID Issued

RFC 7591 describes this as open Dynamic Client Registration.

This maximizes interoperability but increases exposure to:

registration flooding
deceptive clients
database exhaustion
abusive redirect registrations
consent phishing
automated client churn
monitoring noise

Open registration should not mean unvalidated registration.

Protected Registration

A protected registration endpoint requires an Initial Access Token or another authorization mechanism.

text

Approved Developer or Provisioning System
               │
       Initial Access Token
               │
               ▼
       Registration Endpoint

This allows the Authorization Server to restrict who may create OAuth clients.

RFC 7591 supports both open and protected registration models.

Protected registration is appropriate when:

the MCP server handles sensitive data
only enterprise-approved clients are allowed
client creation has operational cost
administrators need attribution
compliance requires onboarding controls
public registration would create unacceptable phishing risk

Initial Access Tokens

An Initial Access Token authorizes the caller to create a client registration.

Example:

http

POST /register HTTP/1.1
Host: auth.example.com
Authorization: Bearer <initial-access-token>
Content-Type: application/json

{
  "client_name": "Approved Enterprise MCP Client",
  "redirect_uris": [
    "https://agent.example.com/oauth/callback"
  ]
}

The token may restrict:

number of registrations
allowed client type
permitted redirect domains
allowed authentication methods
software publisher
tenant
expiration time

An Initial Access Token should be:

short-lived where practical
narrowly scoped
auditable
revocable
accepted only by the registration endpoint
excluded from logs
protected during distribution

It is not an MCP Access Token and should not grant access to MCP tools.

One-Time Registration Tokens

For controlled onboarding, an Authorization Server may issue a token that permits exactly one registration.

text

Administrator
     │
     ▼
One-Time Registration Token
     │
     ▼
MCP Client Registers
     │
     ▼
Token Becomes Invalid

This reduces the consequences of token leakage.

The token can also carry constraints such as:

text

Tenant:
customer-a

Redirect domain:
agent.customer-a.example

Client type:
confidential

Maximum registrations:
1

Registration Response

After successful validation, the Authorization Server returns a Client Information Response.

http

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
  "client_id": "mcp-client-7f42",
  "client_id_issued_at": 1784560000,
  "client_name": "Example MCP Desktop",
  "redirect_uris": [
    "http://127.0.0.1:43123/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "token_endpoint_auth_method": "none"
}

RFC 7591 requires the response to include the issued client_id and the registered metadata.

The returned metadata is authoritative.

The client should not assume that every requested value was accepted unchanged.

Server-Modified Registration Metadata

The Authorization Server may apply policy and return different values.

Requested:

json

{
  "grant_types": [
    "authorization_code",
    "refresh_token",
    "client_credentials"
  ],
  "scope": "documents:read documents:write documents:delete"
}

Accepted:

json

{
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "scope": "documents:read"
}

The client must use the returned registration state.

It should not continue behaving as if rejected properties had been approved.

Client ID

The issued client_id identifies the OAuth client at that Authorization Server.

Example:

json

{
  "client_id": "mcp-client-7f42"
}

Important properties:

it is not necessarily secret
it is specific to the Authorization Server
it may identify one installation or one software product
it must be presented during authorization
it does not itself prove client authenticity
it does not grant MCP access

A client identifier should not be reused across unrelated Authorization Servers unless the applicable registration model intentionally defines a stable URL-based identifier.

Client ID Issuance Strategy

An Authorization Server may issue:

Per-Installation Client IDs

text

Desktop installation A:
client-123

Desktop installation B:
client-456

Benefits:

instance-level revocation
clearer audit records
reduced shared-state impact

Costs:

registration growth
repeated consent entries
more lifecycle management

Shared Software Client ID

text

All installations:
client-example-desktop

This usually requires preregistration or another stable identification model.

A shared identifier does not make a distributed client confidential.

Per-Tenant Client IDs

text

Tenant A:
client-tenant-a

Tenant B:
client-tenant-b

This can support enterprise isolation but requires strong tenant-bound registration controls.

Client Secrets in the Response

A confidential client response may contain:

json

{
  "client_id": "backend-client-42",
  "client_secret": "high-entropy-secret",
  "client_secret_expires_at": 1787152000,
  "token_endpoint_auth_method": "client_secret_basic"
}

The client must protect the secret immediately.

The Authorization Server should:

generate sufficient entropy
transmit it only over TLS
use Cache-Control: no-store
define expiration
store it securely
support rotation
never display it in logs
avoid issuing it to clients that cannot protect it

Registration Access Token

When registration management is supported, the response may contain:

json

{
  "registration_access_token": "reg-token-abc123",
  "registration_client_uri": "https://auth.example.com/register/mcp-client-7f42"
}

The Registration Access Token authorizes management of that specific client registration.

It is distinct from:

Initial Access Token
OAuth Access Token for MCP
Refresh Token
Client Secret

text

Initial Access Token:
Create a registration

Registration Access Token:
Manage one registration

Client Secret:
Authenticate client at token endpoint

MCP Access Token:
Access MCP Resource Server

RFC 7592 defines the Registration Access Token as a Bearer Token associated with one registered client and used at its Client Configuration Endpoint.

Registration Credentials Must Not Be Confused

Using the wrong credential at the wrong endpoint may create serious security failures.

Credential	Intended use
Initial Access Token	Authorize creation of client registration
Registration Access Token	Read, update, or delete registration
Client Secret	Authenticate confidential client at token endpoint
Authorization Code	Exchange for OAuth tokens
Access Token	Access MCP Resource Server
Refresh Token	Obtain new Access Tokens

A Registration Access Token must not grant access to MCP tools.

An MCP Access Token must not permit client registration changes.

Registration Errors

The Authorization Server may reject a request using standardized registration errors.

Examples include:

invalid_redirect_uri
invalid_client_metadata
invalid_software_statement
unapproved_software_statement

Example:

http

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_redirect_uri",
  "error_description": "One or more redirect URIs are not permitted."
}

Error responses should not reveal:

internal validation rules in excessive detail
existing client identifiers
secret values
infrastructure paths
stack traces
database information

Detailed diagnostics can be recorded in protected logs using a correlation ID.

Registration Is Not Client Trust

A dynamically registered client may be:

unknown
unreviewed
malicious
automated
impersonating another product
running on a compromised device
configured with a deceptive name
attempting to phish users

The Authorization Server should distinguish:

text

Registered Client

from:

text

Verified Client
Approved Client
Trusted First-Party Client

Registration means only that the server created an OAuth client record.

Consent and policy screens should not imply stronger trust than has actually been established.

Dynamic Registration vs Client ID Metadata Documents

Current MCP supports both models.

Dynamic Client Registration

text

Client sends metadata
        │
        ▼
Authorization Server stores registration
        │
        ▼
Server issues client_id

Client ID Metadata Documents

text

client_id is an HTTPS URL
        │
        ▼
Authorization Server retrieves client metadata
        │
        ▼
No per-server registration transaction required

Client ID Metadata Documents are generally preferred in current MCP deployments where the client and Authorization Server have no previous relationship. DCR remains optional and primarily serves compatibility or specific registration requirements.

When Dynamic Registration Is the Better Choice

DCR may be appropriate when:

the Authorization Server already supports RFC 7591
the server needs a local registration record
every installation should receive a unique client ID
registration must be tied to a tenant
Initial Access Tokens control onboarding
the Authorization Server must manage client lifecycle
Client ID Metadata Documents are unsupported
deployment compatibility requires older MCP behavior

When Client ID Metadata Documents May Be Better

Client ID Metadata Documents may be preferable when:

the client has a stable HTTPS identity
the Authorization Server supports the mechanism
the client connects to many independent MCP servers
repeated registration records are undesirable
the client metadata is centrally maintained
no per-installation Client Secret is required

However, Client ID Metadata Documents also introduce security requirements around:

SSRF
metadata integrity
redirect URI validation
URL ownership
cache invalidation
metadata changes

Neither mechanism eliminates the need for secure OAuth authorization.

When Preregistration Is Better

Preregistration is often better for:

high-risk enterprise MCP servers
known internal clients
financial systems
production infrastructure
administrative tools
regulated data
a small controlled client population

text

Administrator Reviews Client
        │
        ▼
Client ID Provisioned
        │
        ▼
Only Approved Client Can Begin Authorization

It trades open interoperability for stronger administrative control.

Registration Endpoint Threat Model

The registration endpoint processes untrusted client-controlled metadata.

Potential attackers include:

malicious MCP clients
automated bots
compromised client installations
phishing operators
abusive tenants
attackers with stolen Initial Access Tokens
supply-chain-compromised client software

Protected assets include:

redirect URI integrity
Authorization Server availability
client database
consent-screen trust
administrator attention
client credentials
software identity
downstream user accounts

text

Untrusted Registration Request
        │
        ├── URLs
        ├── Client Name
        ├── Redirect URIs
        ├── Keys
        ├── Software Statement
        └── Authentication Method
        │
        ▼
Security-Critical OAuth Client Record

Every field should be treated as untrusted until validated.

Registration Flooding

An open endpoint may receive large numbers of registrations.

Attackers may attempt to:

exhaust database storage
consume identifiers
increase operational cost
flood audit systems
bypass per-client rate limits by creating new clients
create consent-screen phishing variants
overwhelm administrators

text

Attacker
   │
   ├── Register Client 1
   ├── Register Client 2
   ├── Register Client 3
   └── Register Client 1,000,000

Mitigations

rate-limit registration
limit registrations by network, tenant, Initial Access Token, or publisher
require proof of authorization
expire unused registrations
detect repeated metadata
cap registrations per identity
use quotas
apply abuse scoring
delay or review suspicious registrations
monitor creation velocity

Per-IP limits alone are insufficient because users may share IPs and attackers may distribute traffic.

Client ID Rotation to Bypass Limits

An attacker may repeatedly register new clients to bypass controls based on client_id.

Examples include:

authorization attempt limits
consent frequency limits
token issuance quotas
risk history
abuse blocks

text

Client A blocked
     │
     ▼
Register Client B
     │
     ▼
Continue Attack

The Authorization Server should correlate abuse across additional signals such as:

software identity
Initial Access Token
publisher
tenant
device
network
account
redirect domain
metadata similarity

Dynamic registration should not automatically reset all trust and rate-limit state.

Deceptive Client Registration

A malicious client may imitate a trusted application.

Example:

json

{
  "client_name": "Official OpenAI MCP Desktop",
  "logo_uri": "https://attacker.example/copied-logo.png",
  "client_uri": "https://lookalike.example"
}

Potential consequences:

consent phishing
user confusion
administrator approval errors
reputational damage

Mitigations

mark self-asserted fields clearly
verify domains
reserve protected names
display the actual client identifier or publisher
review high-profile branding claims
prevent active content in logos
separate verified and unverified clients visually
allow users to report deceptive applications

Redirect URI Abuse

Redirect URI attacks remain among the most important registration risks.

An attacker may register:

their own HTTPS domain
a subdomain they temporarily control
a URL using an open redirect
a loopback URI intended to intercept another app
a custom scheme claimed by malicious software
a lookalike internationalized domain
a URL resolving to an internal service

The registration endpoint should validate both URI syntax and deployment policy.

A redirect URI being reachable is not proof that the registrant is authorized to use it.

SSRF Through Registration Metadata

Registration metadata may contain remote URLs such as:

logo_uri
client_uri
policy_uri
tos_uri
jwks_uri
software statement references in extended profiles

If the Authorization Server fetches these URLs, a malicious client may target:

text

http://127.0.0.1:8080/admin
http://169.254.169.254/
http://10.0.0.5/internal

text

Registration Request
        │
        ▼
Authorization Server Fetches URL
        │
        ▼
Internal Service

SSRF Defenses

require HTTPS for remotely fetched metadata where applicable
block loopback
block private networks
block link-local addresses
block cloud metadata endpoints
validate DNS results
revalidate redirects
limit response size
restrict content type
enforce short timeouts
route through an egress proxy
avoid fetching metadata that does not need server-side retrieval

JWKS Registration

A confidential client using asymmetric authentication may register keys directly:

json

{
  "token_endpoint_auth_method": "private_key_jwt",
  "jwks": {
    "keys": [
      {
        "kty": "EC",
        "crv": "P-256",
        "x": "...",
        "y": "...",
        "use": "sig",
        "kid": "client-key-1"
      }
    ]
  }
}

or by URL:

json

{
  "jwks_uri": "https://client.example.com/.well-known/jwks.json"
}

The Authorization Server should verify:

supported key types
permitted algorithms
key strength
appropriate key use
unique key identifiers where required
safe jwks_uri retrieval
rotation behavior
maximum key count
maximum document size

A client-controlled key is not proof that the client is trustworthy. It only enables cryptographic authentication for the holder of the corresponding private key.

Registration Metadata Injection

Human-readable metadata may be displayed in HTML-based:

consent screens
administrator dashboards
audit viewers
client portals
notification emails

Fields such as client_name may contain malicious strings.

Potential risks include:

cross-site scripting
HTML injection
log injection
terminal escape injection
misleading Unicode
control characters

Mitigations

validate length
reject control characters
escape output for its destination
normalize carefully
do not render client-provided HTML
protect logs from line injection
display suspicious Unicode safely
sanitize email templates

Validation at registration time should be combined with context-aware output encoding.

Registration Approval Policies

An Authorization Server may apply different policies according to MCP resource risk.

Low-Risk Public Resource

text

Open registration
Rate limits
Strict metadata validation

Internal Business Resource

text

Initial Access Token
Verified tenant
Approved redirect domains

High-Risk Administrative MCP

text

No open DCR
Preregistration only
Manual security review

Dynamic registration support does not require every protected resource to accept every dynamically registered client.

Authorization policy may depend on:

client verification
tenant
requested MCP resource
scopes
publisher
client authentication method
software statement
risk score

Registration Should Be Resource-Aware

An Authorization Server may protect multiple MCP Resource Servers.

A client acceptable for one resource may not be acceptable for another.

text

Unverified Desktop Client
        │
        ├── Public Docs MCP: Allowed
        └── Production Cloud MCP: Denied

The registration record should not automatically provide eligibility for every resource protected by the same Authorization Server.

Resource-specific policy may be enforced during:

registration
authorization
scope approval
token issuance
Resource Server validation

Expiring Unused Registrations

Dynamic registration can create large numbers of abandoned client records.

A server may mark a client inactive when:

it has never completed authorization
no token has ever been issued
it has not been used for a defined period
its software version is unsupported
its Initial Access Token was revoked
its publisher relationship changed

Before deletion, consider whether the record is needed for:

security investigation
consent history
abuse correlation
compliance retention
incident response

Inactive clients should not be able to resume authorization automatically after expiration without satisfying current policy.

Registration Idempotency and Retries

A client may not receive the registration response because of a network failure.

It may retry and accidentally create several client registrations.

text

Client sends registration
       │
Server creates client
       │
Response lost
       │
Client retries
       │
Second client created

Possible mitigations include:

client-generated idempotency keys
short-term request deduplication
software identity correlation
user-visible registration recovery
querying registration state when RFC 7592 management is available

Any deduplication mechanism must avoid merging registrations belonging to different legitimate installations.

Registration State Storage

The client may need to store:

Authorization Server issuer
client_id
Client Secret, if applicable
Registration Access Token
Client Configuration Endpoint
registered redirect URIs
issued timestamps
metadata version

Sensitive values should be stored using platform-appropriate protected storage.

Do not store them in:

public repository files
browser local storage without a threat assessment
plaintext logs
shared project configuration
analytics systems
crash reports

The client_id is not secret, but related credentials may be.

Per-Authorization-Server Registration

A dynamically issued client_id is normally specific to one Authorization Server.

text

Authorization Server A:
client_id = abc123

Authorization Server B:
client_id = xyz789

The MCP client should key stored registration state by the validated issuer.

Unsafe storage:

text

One global client_id for all servers

Safer storage:

text

https://auth-a.example:
client_id = abc123

https://auth-b.example:
client_id = xyz789

This helps prevent issuer mix-up and sending one Authorization Server's credentials to another.

Issuer Binding

The client should bind registration state to:

Authorization Server issuer
registration endpoint
MCP Resource Server
registration method
redirect URI set

If the issuer changes unexpectedly, the client should not automatically send previously issued credentials to the new endpoint.

text

Old issuer:
https://auth.example.com

New metadata:
https://attacker.example

Stored Client Secret:
Do not send

Unexpected discovery changes should trigger revalidation or user approval.

Registration Endpoint Authentication

The registration endpoint itself may use:

no authentication
Initial Access Token
mutual TLS
software statement authorization
enterprise workload identity
administrator-mediated provisioning

The chosen method should match the risk of client creation.

An open registration endpoint should be treated as a public attack surface and hardened accordingly.

Registration Endpoint Transport Security

The registration endpoint should use HTTPS.

This protects:

submitted redirect URIs
Initial Access Tokens
issued Client Secrets
Registration Access Tokens
client metadata
software statements
issued Client IDs

The endpoint should also use:

http

Cache-Control: no-store
Pragma: no-cache

for responses containing credentials.

TLS does not replace endpoint and issuer validation.

Registration Logging

Useful audit events include:

registration requested
registration accepted
registration rejected
Initial Access Token used
software statement validated
redirect URI rejected
client credentials issued
Registration Access Token issued
registration modified
registration deleted
registration expired

Useful fields may include:

timestamp
issuer
client ID
software ID
tenant
redirect domain
requested authentication method
decision
policy rule
correlation ID

Do not log complete:

Initial Access Tokens
Client Secrets
Registration Access Tokens
private keys
software statement contents containing sensitive claims

Registration Monitoring

Security teams should monitor for:

sudden spikes in registrations
repeated invalid redirect URIs
copied high-profile client names
many registrations from one token
unusual redirect domains
private-network metadata URLs
unsupported grant requests
suspicious software-statement issuers
clients repeatedly deleted and recreated
one client registering across many tenants
newly registered clients requesting high-risk scopes

A newly issued client_id should not be treated as low risk merely because registration succeeded.

Dynamic Registration Security Principle

The central rule is:

Dynamic registration creates OAuth client configuration. It does not establish that the client is safe, approved, or entitled to access an MCP resource.

The Authorization Server should separate:

text

Protocol compatibility

from:

text

Security trust

A client may be correctly registered under RFC 7591 and still be denied authorization because it is:

unverified
unapproved
requesting excessive permissions
using a risky redirect model
targeting a restricted MCP resource
associated with abusive behavior

RFC 7592: Client Registration Management

RFC 7591 creates a client registration.

RFC 7592 defines optional lifecycle management for that registration.

It allows an OAuth client to:

retrieve its current registration
update registration metadata
rotate client information
delete the registration
manage registration state without administrator intervention

text

RFC 7591
Create Client
      │
      ▼
Registered OAuth Client
      │
      ▼
RFC 7592
Read
Update
Delete

Unlike RFC 7591, RFC 7592 is optional.

Many Authorization Servers implement Dynamic Client Registration without exposing client self-management APIs.

RFC 7592 is an Experimental specification and should be treated as an optional capability rather than a required part of MCP interoperability.

Registration Access Token

RFC 7592 introduces the Registration Access Token.

It authorizes management of one registered OAuth client.

text

Registration Access Token
          │
          ▼
Registration Management Endpoint
          │
          ├── Read Registration
          ├── Update Registration
          └── Delete Registration

It is not:

an MCP Access Token
a Refresh Token
a Client Secret
an Initial Access Token
a user credential

Instead, it represents authority over a single OAuth client registration.

Registration Client URI

A successful registration response may include:

json

{
  "registration_client_uri":
    "https://auth.example.com/register/client-123",
  "registration_access_token":
    "reg-token..."
}

The Registration Client URI identifies the management endpoint for exactly one registered client.

Future operations target this URI.

text

Authorization Server
       │
       ▼
registration_client_uri
       │
       ▼
One OAuth Client Registration

The URI itself is not authorization.

Possession of the Registration Access Token is still required.

Reading Registration Metadata

A client may retrieve its registration.

http

GET /register/client-123 HTTP/1.1
Authorization: Bearer reg-token...

Example response:

json

{
  "client_id": "client-123",
  "client_name": "Example MCP Desktop",
  "redirect_uris": [
    "http://127.0.0.1:43123/callback"
  ],
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ]
}

Reading registration metadata can help recover client state after:

local configuration loss
device migration
interrupted registration
administrative updates

Only the owner of the registration should be able to retrieve it.

Updating Registration Metadata

RFC 7592 allows modification of client metadata.

Example:

http

PUT /register/client-123 HTTP/1.1
Authorization: Bearer reg-token...
Content-Type: application/json

Potential updates include:

redirect URIs
logo URI
policy URI
contact information
JWKS
software version
grant types where permitted

Not every field should necessarily be editable.

The Authorization Server should define exactly which metadata can change.

Full Replacement vs Partial Update

Implementations should document whether updates perform:

Full Replacement

text

Old Metadata
        │
Replaced Completely
        │
        ▼
New Metadata

Partial Update

text

Old Metadata
       │
Modify Selected Fields
       │
       ▼
Updated Metadata

The client should never assume the server supports partial updates unless explicitly documented.

Redirect URI Update Attacks

Updating redirect URIs is one of the highest-risk registration operations.

Suppose a legitimate client originally registers:

text

https://client.example.com/callback

A compromised Registration Access Token could modify it:

text

https://attacker.example/callback

Future authorization codes would then be delivered to the attacker.

The Authorization Server should treat redirect URI updates with the same rigor as initial registration.

Possible controls include:

administrator approval
software statement validation
domain verification
Initial Access Token policy
enterprise allowlists
notification of administrators
confirmation by the client owner

Redirect URI changes should generate audit events.

Updating JWKS

Confidential clients using asymmetric authentication may rotate public keys.

Example:

json

{
  "jwks_uri":
    "https://client.example.com/.well-known/jwks.json"
}

json

{
  "jwks": {
    "keys": [
      {
        "kid": "new-key"
      }
    ]
  }
}

Updating signing keys affects client authentication.

The Authorization Server should verify:

supported algorithms
permitted key types
key size
duplicate key identifiers
expected key usage
safe retrieval of remote JWKS documents

Key rotation should not silently weaken client authentication.

Updating Client Authentication Method

Changing:

text

token_endpoint_auth_method

may fundamentally alter the client's security model.

Example:

text

private_key_jwt
        │
        ▼
none

text

client_secret_basic
        │
        ▼
none

Such changes should generally require stronger validation than cosmetic metadata updates.

An attacker should not be able to downgrade client authentication simply because they obtained a Registration Access Token.

Registration Access Token Security

Registration Access Tokens should be treated as privileged credentials.

They should:

use high entropy
be transmitted only over TLS
remain specific to one registration
be excluded from logs
be stored securely
support revocation
support rotation
expire where appropriate

text

Registration Access Token
        │
        ▼
Manage Registration

Loss of the token may allow an attacker to:

change redirect URIs
rotate keys
modify contacts
replace metadata
delete the client

Its sensitivity is therefore higher than an ordinary client identifier.

Rotating Registration Access Tokens

Long-lived management tokens increase exposure.

The Authorization Server may rotate the Registration Access Token after sensitive operations.

text

Registration Token A
         │
Update Registration
         │
         ▼
Registration Token B

Token A Invalid

Rotation reduces the impact of:

token leakage
browser history exposure
accidental backups
compromised local storage

Revoking Registration Access Tokens

A Registration Access Token should become invalid when:

the client registration is deleted
the client is suspended
an administrator revokes it
suspicious activity is detected
the token expires
the registration is replaced

Revocation should immediately prevent further registration management operations.

Client Deletion

RFC 7592 may allow deleting a client registration.

Conceptually:

text

OAuth Client
      │
Delete Request
      │
      ▼
Authorization Server
      │
      ▼
Registration Removed

Deletion may invalidate:

client identifier
Client Secret
Registration Access Token
future authorization requests

The Authorization Server should define whether historical audit records remain.

Deleting operational records without preserving security evidence may complicate incident response.

Soft Delete vs Hard Delete

Soft Delete

text

Client
    │
Marked Inactive

Benefits:

audit preservation
abuse investigation
recovery
historical reporting

Hard Delete

text

Client
     │
Removed Completely

Benefits:

reduced stored data
simpler lifecycle

Drawbacks:

lost investigation data
possible identifier reuse concerns
reduced forensic visibility

High-security deployments often retain historical registration information even after deactivation.

Client Suspension

Sometimes a client should not be deleted.

Instead:

text

Client Status

Active

↓

Suspended

Suspension may block:

new authorization
token issuance
registration updates

while preserving:

audit records
consent history
identifiers
investigation data

Suspension is often appropriate during security investigations.

Credential Rotation

Lifecycle management should support rotation of:

Client Secrets
Registration Access Tokens
signing keys
software statements where applicable

Credential rotation should avoid interrupting legitimate deployments.

Typical sequence:

text

New Credential
      │
Both Valid
      │
Old Credential Removed

Immediate replacement without overlap may break running systems.

Client Secret Rotation

A confidential client should periodically rotate its Client Secret.

text

Client Secret A

↓

Client Secret B

↓

Secret A Revoked

Safe rotation typically includes:

secure distribution
overlap period
revocation
audit logging
notification where appropriate

Public clients generally should not rely on Client Secrets.

Registration Lifecycle

A registration moves through several states.

text

Created
    │
Approved
    │
Active
    │
Updated
    │
Suspended
    │
Deleted

Every transition should be auditable.

State transitions should not silently change:

authentication method
redirect policy
resource eligibility
tenant assignment

Expiration Policies

Not every registration must live forever.

Possible expiration rules include:

unused registrations expire
abandoned registrations expire
inactive confidential clients expire
temporary registrations expire
trial registrations expire

Expiration should not surprise administrators.

Warnings and renewal procedures improve operational reliability.

Tenant-Aware Registration

Multi-tenant Authorization Servers may associate registrations with one tenant.

text

Tenant A

Client A

Tenant B

Client B

Benefits include:

tenant-specific policy
separate approval
independent revocation
isolated audit records

A Registration Access Token from one tenant must never modify another tenant's registration.

Administrative Overrides

Administrators may need to:

suspend clients
rotate credentials
change redirect URIs
reset registration
approve software statements
revoke Registration Access Tokens

Administrative actions should require:

privileged authentication
authorization
audit logging
justification where appropriate

Administrator activity should be distinguishable from client-initiated changes.

Registration Event Logging

Useful events include:

registration created
metadata updated
redirect URI modified
authentication method changed
signing key changed
Client Secret rotated
Registration Access Token rotated
registration suspended
registration deleted

Useful fields include:

timestamp
administrator
client ID
tenant
previous values
new values
policy rule
correlation identifier

Sensitive credentials should never appear in logs.

Monitoring Registration Activity

Organizations should monitor:

frequent metadata updates
repeated redirect changes
repeated authentication downgrades
many deleted clients
excessive registration creation
failed update attempts
suspicious software identities
unexpected tenant movement

Behavioral monitoring often detects compromise before direct credential theft becomes visible.

High Availability

Registration services should remain available without compromising consistency.

Consider:

replicated registration storage
transaction integrity
identifier uniqueness
backup procedures
disaster recovery
concurrency handling

Concurrent updates should not silently overwrite one another.

Versioning or optimistic concurrency controls can reduce accidental loss of metadata.

Testing Dynamic Registration

Security testing should verify:

redirect URI validation
malformed metadata
oversized metadata
unsupported grant types
invalid authentication methods
registration flooding
Registration Access Token misuse
replay
deletion behavior
tenant isolation
audit generation
credential rotation

Regression testing should cover every supported lifecycle operation.

Dynamic Client Registration Checklist

Registration

Is RFC 7591 implemented correctly?
Is registration optional where required?
Is the endpoint discovered from Authorization Server Metadata?
Are unsupported fields rejected?
Is metadata validated?

Redirect URIs

Are redirect URIs validated?
Is exact matching enforced?
Are loopback policies documented?
Are open redirects rejected?
Are updates audited?

Client Type

Are public and confidential clients distinguished?
Are Client Secrets avoided for public clients?
Are authentication methods validated?

Credentials

Are Registration Access Tokens protected?
Can they be rotated?
Can they be revoked?
Are Client Secrets rotated?

Lifecycle

Can registrations be suspended?
Can they be deleted safely?
Are inactive registrations expired?
Is historical audit preserved?

Multi-Tenant

Is every registration bound to a tenant?
Can one tenant modify another tenant's registration?
Are tenant-specific policies enforced?

Security

Are SSRF protections applied to remote metadata?
Are registration floods rate-limited?
Are deceptive client identities detected?
Are sensitive changes logged?

Operations

Is backup tested?
Is recovery documented?
Are updates concurrency-safe?
Is monitoring in place?

Common Dynamic Registration Mistakes

Treating Registration as Trust

Creating a client record does not make the client trusted.

Weak Redirect Validation

Accepting arbitrary redirect URIs defeats OAuth security.

Issuing Client Secrets to Public Clients

A desktop application cannot reliably protect a shared secret.

Allowing Authentication Downgrades

Changing from strong authentication to none without review weakens the client.

Logging Registration Credentials

Registration Access Tokens and Client Secrets are sensitive credentials.

Ignoring Registration Lifecycle

Abandoned registrations increase attack surface.

Skipping Audit Logging

Registration changes should always be attributable.

Conclusion

Dynamic Client Registration solves one specific OAuth problem:

How can a previously unknown MCP client obtain an OAuth client identity without manual administrator configuration?

It does not establish trust, grant authorization, or replace user consent.

A secure implementation should:

validate all metadata
protect redirect URIs
distinguish public and confidential clients
secure Registration Access Tokens
support lifecycle management
monitor registration activity
preserve audit history
apply resource-specific policy
prevent abuse through rate limiting and tenant isolation

Current MCP deployments should generally prefer preregistered client information or Client ID Metadata Documents where available, using Dynamic Client Registration when those mechanisms are unavailable or when deployment requirements specifically call for RFC 7591 compatibility.

Continue learning: