Skip to content

Add Initial Access Token Support for Dynamic Client Registration #772

New issue
New issue
Closed
Closed
Add Initial Access Token Support for Dynamic Client Registration#772
Labels
P2Moderate issues affecting some users, edge cases, potentially valuable featureauthIssues and PRs related to Authentication / OAuthenhancementRequest for a new feature that's not currently supportedready for workEnough information for someone to start working on

Description

@andormarkus
andormarkus
opened on Jul 16, 2025

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.

Activity

  1. andormarkus
    added
    enhancementRequest for a new feature that's not currently supported
    on Jul 16, 2025

  2. pcarleton commented on Jul 16, 2025

    @pcarleton
    pcarleton
    on Jul 16, 2025
    Member

    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)?

  3. andormarkus commented on Jul 16, 2025

    @andormarkus
    andormarkus
    on Jul 16, 2025
    Author

    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.

  4. felixweinberger
    added
    authIssues and PRs related to Authentication / OAuth
    ready for workEnough information for someone to start working on
    P2Moderate issues affecting some users, edge cases, potentially valuable feature
    on Dec 16, 2025
  5. JosephDoUrden
    added a commit that references this issue on Apr 10, 2026

    feat(client): add initial access token support for Dynamic Client Reg…

    4795c6a

  6. pcarleton commented on Apr 14, 2026

    @pcarleton
    pcarleton
    on Apr 14, 2026
    Member

    We've started recommending CIMD as a preferred alternative to DCR. I'll close this issue, but if you still need access token support on DCR endpoints, please re-open. The referenced PR #1874 is a good approach, but it's not clear to me if there is still demand for this.

  7. pcarleton
    closed this as completedon Apr 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Moderate issues affecting some users, edge cases, potentially valuable featureauthIssues and PRs related to Authentication / OAuthenhancementRequest for a new feature that's not currently supportedready for workEnough information for someone to start working on

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions