SW-MCP-003: OAuth dynamic client registration (deprecated; use Client ID Metadata Documents)

What it detects

The rule reads the authorization server metadata that the probe fetched after the server answered 401 or 403. It fires when that metadata lists a registration_endpoint and does not declare client_id_metadata_document_supported as the JSON value true. The check on that field is strict: the string "true" does not count.

The order of the classification matters. Support for Client ID Metadata Documents is tested first, so a server that offers both methods is classified as using them and is not matched. A server that offers the JWT bearer grant and no registration endpoint is classified separately and is not matched either. The evidence is the registration endpoint's address, on the server's endpoint.

Why it matters

With dynamic client registration, any client can create a new client record at the authorization server by posting to an open endpoint. Over time the server collects registrations nobody reviews, and a user is asked to approve a client whose name and redirect address the client chose itself. The 2026-07-28 specification moves to Client ID Metadata Documents, where the client's identity is a document at an address it controls. The scanner maps this rule to OWASP MCP07, Insufficient Authentication & Authorization, and to NIST SP 800-53 control IA-5, Authenticator Management.

Example

This recorded probe shows a server that publishes resource metadata and an authorization server with a registration_endpoint, and with client_id_metadata_document_supported set to false:

probe.json

{
  "endpoint": "https://mcp.example.invalid/mcp",
  "reachable": true,
  "unauthenticated_status": 401,
  "www_authenticate": "Bearer resource_metadata=\"https://mcp.example.invalid/.well-known/oauth-protected-resource\"",
  "resource_metadata": {
    "resource": "https://mcp.example.invalid/mcp",
    "authorization_servers": [
      "https://auth.example.invalid"
    ]
  },
  "auth_server_metadata": {
    "issuer": "https://auth.example.invalid",
    "metadata_url": "https://auth.example.invalid/.well-known/oauth-authorization-server",
    "registration_endpoint": "https://auth.example.invalid/register",
    "client_id_metadata_document_supported": false,
    "grant_types_supported": [
      "authorization_code"
    ]
  }
}

A server check judges what a probe recorded, not files. The recorded probe above is read the way the scanner's README describes under Evaluating an MCP server probe.

How to fix

Enable Client ID Metadata Documents at the authorization server and publish client_id_metadata_document_supported as true in its metadata. You can keep the registration endpoint for older clients for a while: once the metadata declares the new method, this rule stops matching. The migration checklist names the related steps.

If it is a false positive

If you do not run the authorization server, for example because it is a hosted identity service, the change is the provider's to make. Accept the finding with a note that names the provider and the date you asked for the change.

If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.

Related rules

• SW-MCP-002: Static key authentication instead of OAuth
• SW-MCP-010: No protected resource metadata, or issuer not validated