Skip to content

Add support for initial access tokens in OAuth 2.0 Dynamic Client Registration #575

Closed as not planned

Description

@andormarkus

Summary

The MCP Inspector currently does not support initial access tokens when performing OAuth 2.0 Dynamic Client Registration (DCR), which limits its ability to work with authorization servers that require authentication for client registration.

Problem

According to RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol), authorization servers may optionally require an initial access token to authorize client registration requests. The MCP Inspector's current implementation only supports open registration (no authentication required).

Current Behavior

  • Dynamic client registration works only with authorization servers that allow open registration
  • No way to provide an initial access token during the registration process
  • Registration fails with authorization servers that require pre-authorization

Expected Behavior

  • Support for providing an initial access token during dynamic client registration
  • Ability to register with protected client registration endpoints
  • Support for both open and protected registration scenarios
  • Environment variable support for secure token configuration

Use Case

Many production OAuth 2.0 authorization servers implement protected dynamic client registration for security reasons. This is especially common in:

  • Enterprise environments
  • Financial services (Open Banking)
  • Healthcare systems
  • CI/CD pipelines and automated deployments
  • Any environment requiring strict client management

Technical Details

RFC 7591 Specification

According to RFC 7591, Section 1.2:

"Initial Access Token: OAuth 2.0 access token optionally issued by an authorization server to a developer or client and used to authorize calls to the client registration endpoint."

The token should be sent in the Authorization header:

POST /register HTTP/1.1
Authorization: Bearer <initial_access_token>
Content-Type: application/json

Current Implementation

In client/src/lib/oauth-state-machine.ts, the registration step calls:

const fullInformation = await registerClient(context.serverUrl, {
  metadata,
  clientMetadata,
});

Proposed Solution

  1. Environment Variable Support: Add support for MCP_OAUTH_INITIAL_ACCESS_TOKEN environment variable
  2. UI Configuration: Add an optional initial access token field to the client configuration UI
  3. Priority Logic: Environment variable takes precedence over UI input for security
  4. Update the OAuth state machine to include the token in registration requests
  5. Modify the registerClient call to support the initial access token parameter
  6. Update the MCP SDK if necessary to support this parameter

Configuration Methods (in order of priority)

  1. Environment Variable: MCP_OAUTH_INITIAL_ACCESS_TOKEN=your_token_here
  2. UI Input: Optional field in the OAuth configuration section
  3. Config File: Include in inspector configuration (if applicable)

Additional Context

This enhancement would make MCP Inspector compatible with a broader range of OAuth 2.0 authorization servers and enable usage in:

  • Enterprise environments that require protected client registration
  • CI/CD pipelines where UI input is not feasible
  • Automated deployments and testing scenarios
  • Containerized environments where configuration via environment variables is standard

References

Activity

  1. MOmarMiraj commented on Jun 30, 2025

    @MOmarMiraj

    +1 for this.. Also need this for testing in my MCP server. Would you know any MCP client that currently does implement the logic for an initial access token?

  2. andormarkus commented on Jul 16, 2025

    @andormarkus
    Author
  3. added
    authIssues and PRs related to authorization
    on Aug 3, 2025
  4. cliffhall commented on Aug 1, 2026

    @cliffhall
    Member

    Closing: v1 is deprecated.

    Thank you for reporting this, and apologies for the long wait for a response.

    v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.

    If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTING.md.

    Thanks for taking the time to report it.

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

    authIssues and PRs related to authorizationclosed-v1-deprecatedClosed: v1 is deprecated and accepting security fixes onlyenhancementNew feature requestv1waiting on sdkWaiting for an SDK feature

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions