Skip to main content

Documentation Index

Fetch the complete documentation index at: https://auth0.com/ai/docs/llms.txt

Use this file to discover all available pages before exploring further.

Dynamic Client Registration (DCR) allows client applications to register themselves automatically by making an API request to a registration endpoint. While this offers flexibility for certain highly dynamic architectures, it introduces significant security risks if not properly secured. For production MCP deployments, we recommend using manual CIMD registration instead of DCR. CIMD offers superior security with domain-verified identities, simpler credential management (register once, deploy everywhere), and eliminates the risks associated with open registration endpoints.

​
Prerequisites

All applications created through DCR in Auth0 are third-party applications with enhanced security controls. You must define default permissions, or a baseline set of APIs and scopes available to all third-party applications. This is required for DCR, where you cannot configure API access for each application individually. In the Auth0 Dashboard:
  1. Navigate to Applications > APIs and select the API.
  2. Go to the Settings tab.
  3. Scroll to Default Permissions for Third-Party Applications.
  4. Select Authorized for User-Delegated Access or Client Access.
  5. Select the scopes to grant, then select Save.

​
Enable DCR

By default, DCR is disabled for all tenants. You can enable DCR in your tenant settings in the Auth0 Dashboard:
  1. Navigate to Dashboard > Settings > Advanced.
  2. Enable the Dynamic Client Registration (DCR) toggle.
  3. Select Save.

​
The Dangers of an Open DCR Endpoint

Auth0 supports an open DCR endpoint, which means that if you enable this feature without additional protections, anyone on the internet can create applications in your tenant. This exposes you to several threats:
  • Resource Exhaustion: A malicious actor could run a script to register millions of applications, potentially causing a denial-of-service by filling up your tenant’s application limit.
  • Unauthorized Access Attempts: Attackers can register their own clients to probe your system for vulnerabilities or attempt to gain unauthorized access.
  • Tenant Misconfiguration: Unvetted, automated registrations can lead to clients being created with insecure settings, creating weak points in your security posture.
  • Lack of Oversight: Without strict monitoring, it becomes difficult to track who is registering clients and for what purpose.

​
Securing an Open DCR Endpoint

Open Dynamic Client Registration (Open DCR) enables flexible MCP integrations but exposes your tenant to potential abuse if left unauthenticated. Without security controls, anyone can create applications in your tenant, potentially leading to resource exhaustion, unauthorized access attempts, or tenant misconfiguration.
These security options are available to Enterprise customers only. To upgrade your plan, contact Auth0 Sales.
There are two approaches you can implement to mitigate these risks: Restrict which IP address ranges or domains can access your tenant’s DCR endpoints through Auth0’s built-in Tenant Access Control List (ACL) feature. This approach protects both your custom domain and canonical Auth0 hostname (e.g., tenant.auth0.com), providing comprehensive protection. It’s ideal when you know the IP ranges of legitimate clients (such as your internal network or specific cloud providers) and want to enforce network-based access control without managing additional infrastructure.

​
Reverse Proxy

Place a reverse proxy (such as Cloudflare) in front of your custom domain to rate-limit, filter, and authenticate requests before they reach the DCR endpoint. This approach allows you to control request volume, implement custom authentication logic, and monitor traffic patterns. However, note that even with a reverse proxy on your custom domain, the DCR endpoint remains accessible via your canonical Auth0 hostname (e.g., tenant.auth0.com), which can bypass the proxy. For comprehensive protection, use this approach in combination with Tenant ACL.

​
Defense in Depth

Both approaches can be used together for defense-in-depth security. Regardless of which approach you choose, monitor your tenant logs regularly to detect suspicious registration patterns.
Both approaches can be used together for defense-in-depth security. Monitor your tenant logs regularly to detect suspicious registration patterns.

​
Monitoring DCR Activity

Regularly review your tenant logs to identify suspicious patterns such as rapid application creation or registrations from unexpected sources. To monitor client registrations:
  1. Navigate to Monitoring > Logs in your Auth0 Dashboard
  2. Use the search query: type:sapi AND description:"Dynamic client registration" This filters for successful Management API operations (sapi) specifically related to Dynamic Client Registration events.
  3. Review the log entries for:
    • Unusual volume: Multiple clients created in a short time span
    • Unexpected sources: Registrations from unfamiliar IP addresses or locations
    • Suspicious patterns: Similar client names, callback URLs pointing to unexpected domains, or clients created outside business hours

​
Retrieve logs using the Auth0 CLI

You can also retrieve DCR logs programmatically using the Auth0 CLI: 
# Get recent Dynamic Client Registration events
auth0 logs list --filter "type:sapi AND description:\"Dynamic client registration\"" --number 100
Consider setting up log streams to forward DCR events to your SIEM or monitoring platform for automated alerting on suspicious registration activity.

​
Authentication and Authorization for MCP Servers

When an MCP server is exposed to the internet, it must be secured. The MCP specification recommends using OAuth 2.1 to secure these interactions. This allows an MCP server to delegate authentication to a dedicated authorization server and manage access control for different clients, users, and actions using scopes.

​
Mandatory Server Configuration

For a client to interact with your server, the MCP specification requires you to announce your authorization configuration and use standard HTTP responses.
  1. Use the WWW-Authenticate Header for 401 Errors When a client makes a request without a valid token, your server must return a 401 Unauthorized status. Crucially, this response must include the WWW-Authenticate header, pointing to the metadata URL you configured above. This signals to the client that authentication is required and tells it exactly where to obtain the authorization metadata.
  2. Announce Your Auth Server with Protected Resource Metadata (RFC 9728) Your MCP server must tell clients where to get authorized. To do this, you must expose a metadata endpoint. Create a .well-known/oauth-protected-resource endpoint on your server that returns a JSON object pointing to your Auth0 tenant. This allows MCP clients to automatically discover your authorization endpoints without manual configuration.