Add Initial Access Token Support for Dynamic Client Registration

[andormarkus]

Is your feature request related to a problem? Please describe.

The current MCP TypeScript SDK implementation of OAuth 2.0 Dynamic Client Registration does not support initial access tokens, which limits deployment flexibility for enterprise use cases. According to RFC 7591, authorization servers may optionally restrict client registration to only previously authorized parties using initial access tokens.

While open registration is perfectly acceptable for consumer applications and development scenarios, enterprise deployments often require this additional security layer. Without this optional support, enterprise MCP servers must either:

1. Implement custom workarounds outside the standard OAuth flow
2. Use third-party solutions
3. Pre-register all clients manually (defeats the purpose of dynamic registration)

This limitation prevents enterprise-grade deployments while maintaining current open registration capabilities for consumer applications.

Describe the solution you'd like

Add optional support for initial access tokens in the dynamic client registration flow. The implementation should:

1. Provide an easy configuration method such as:

   • Environment variables (e.g., MCP_INITIAL_ACCESS_TOKEN, OAUTH_INITIAL_ACCESS_TOKEN)
   • Configuration files
   • Constructor parameters
   • Other standard configuration approaches

2. Maintain backward compatibility - existing code should continue to work without changes

3. Follow RFC 7591 specification - when an initial access token is provided, include it as a Bearer token in the Authorization header of the registration request:

   Authorization: Bearer <initial_access_token>
   

4. Handle missing tokens gracefully - when no token is provided, proceed with open registration (normal behavior for consumer apps)

5. Provide clear error handling for cases where tokens are invalid (but remember that missing tokens are expected and valid for consumer apps)

Describe alternatives you've considered

• Custom middleware: Implementing initial access token validation as separate middleware, but this breaks the standard OAuth flow
• Third-party solutions: Using external libraries, but this adds complexity and dependencies
• Pre-registration: Manually registering all clients, but this eliminates the benefits of dynamic registration
• Open registration only: This works for consumer applications but doesn't meet enterprise security requirements

Additional context

• RFC 7591 compliance: The OAuth 2.0 Dynamic Client Registration Protocol supports initial access tokens as an optional feature for restricting registration access
• Enterprise flexibility: This provides an optional security layer for enterprise deployments without impacting consumer applications
• Industry standard: Authorization servers like Auth0, Keycloak, and others already support this feature
• Deployment options: This enables both open registration (consumer apps) and restricted registration (enterprise) from the same codebase

Implementation considerations

The maintainers can choose the most appropriate implementation approach, but it should be easy for developers to configure, such as:

• Setting an environment variable
• Adding a configuration option
• Providing the token through existing configuration mechanisms

Expected behavior

When an initial access token is configured:

• Include it as Authorization: Bearer <token> in the registration request
• Handle 401/403 responses appropriately when tokens are invalid

When no initial access token is configured:

• Proceed with open registration (current behavior)
• Maintain full backward compatibility

This enhancement would provide deployment flexibility for both consumer applications and enterprise deployments while bringing the TypeScript SDK closer to full RFC 7591 compliance.

[pcarleton]

Hi @andormarkus could you share a little more about the scenario you're trying to unblock?

I agree this is supported in the RFC, but I'm uncertain of the benefit it provides. When I've considered this before, if an AS needs to distribute this initial access token, why not distribute a client ID/secret instead (i.e. pre-register that client)?

[andormarkus]

Hi @pcarleton! Great question - I totally understand the confusion since on the surface they seem like they'd solve similar problems. Let me walk through the specific scenario that led me to implement this feature and why I've found initial access tokens work better than pre-registration for our use case.

The Challenge We're Facing

We're building a B2B MCP product where enterprise customers typically need multiple MCP clients per organization. For example:

• Customer A: 5 clients (dev, staging, prod, backup, monitoring)
• Customer B: 10 clients across different departments
• Customer C: 20+ clients for microservices architecture

With pre-registration, we'd end up manually creating and securely distributing 35+ different client credentials. That quickly becomes a lot of manual work on our end!

Why Initial Access Tokens vs Pre-registration

The Core Issue: Pre-registering clients moves us away from the self-service aspect that makes DCR so valuable in the first place.

Current workflow (pre-registration approach):

1. Customer emails us requesting client credentials  
2. We manually create credentials in our admin panel
3. We securely send credentials back to customer
4. Customer tests their integration
5. Customer needs staging environment? → back to step 1
6. Customer needs prod environment? → back to step 1 again

What we're hoping to enable (with initial access tokens):

1. We generate one scoped initial access token for customer
2. Customer can immediately run: mcp-client --register --token=<token>
3. Customer gets their client credentials right away
4. Customer can repeat this for all their environments without waiting on us

Technical and Operational Benefits

Enhanced Security Model:

• Tokens can be scoped ("max 10 clients", "expires in 30 days")
• Granular revocation capabilities tied to customer accounts
• Time-limited access vs long-lived credentials
• Better audit trails

Operational Efficiency:

• Pre-registration: We're in the loop for every single client credential request
• With tokens: One-time token generation, then customers are self-sufficient

Standards Compliance:
RFC 7591 actually designed initial access tokens for exactly this scenario:

"Authorization servers may optionally restrict client registration to only previously authorized parties"

Industry Precedent:
Auth0, Keycloak, and Azure AD all support this pattern for multi-tenant enterprise deployments. This is the standard way to handle "public internet but controlled registration."

Our Specific Requirements

We're building a product that's:

• ✅ Open to public internet (can't restrict by IP)
• ✅ Needs DCR benefits (automation, self-service)
• ✅ Requires access control (not open registration)
• ✅ Serves enterprise customers (multiple clients per org)

Without initial access tokens, we're forced to choose between:

1. ❌ Abandon DCR entirely (lose automation benefits)
2. ❌ Completely open registration (security risk)
3. ❌ Custom workarounds (break standards compliance)

Implementation Details

I've implemented this in PR #773 for TypeScript and PR #1154 for Python. The implementation provides:

• ✅ Backward compatible: Existing code unchanged
• ✅ Standards compliant: Follows RFC 7591 exactly
• ✅ Flexible config: Environment variables, config files
• ✅ Graceful degradation: Works with/without tokens
• ✅ Proper error handling: 401/403 responses when tokens invalid

When an initial access token is configured, my implementation includes it as Authorization: Bearer <token> in the registration request. When no token is configured, it proceeds with open registration (current behavior).

Summary

This is why I implemented initial access token support in both the TypeScript and Python SDKs. It solves the "controlled self-service" problem that pure pre-registration cannot, enabling DCR's automation benefits while maintaining enterprise security controls - exactly what RFC 7591 designed this feature for.

Really appreciate you taking the time to review this! Happy to clarify any implementation details or adjust the approach based on your feedback.