Client Auth: Client Registration Methods

[pcarleton]

Overview

Add conformance tests for all three OAuth client registration mechanisms: Client ID Metadata Documents (CIMD), Pre-registration, and Dynamic Client Registration (DCR).

Specification References

• Client Registration Approaches
• Client ID Metadata Documents
• Preregistration
• [Dynamic Client Registration](https://modelcontextprotocol.io/specification/draft/basic/authorization#dynamic-client-
• OAuth Client ID Metadata Document (draft-ietf-oauth-client-id-metadata-document-00)
• RFC 7591 - OAuth 2.0 Dynamic Client Registration Protocol

Key Requirements from Specification

Client ID Metadata Documents (SHOULD)

For MCP Clients:

• Clients MUST host metadata document at HTTPS URL following RFC requirements
• client_id URL MUST use "https" scheme and contain path component
• Metadata document MUST include: client_id, client_name, redirect_uris
• Clients MUST ensure client_id value in metadata matches document URL exactly
• Clients MAY use private_key_jwt for client authentication with appropriate JWKS configuration

For Authorization Servers:

• SHOULD fetch metadata documents when encountering URL-formatted client_ids
• MUST validate fetched document's client_id matches the URL exactly
• SHOULD cache metadata respecting HTTP cache headers
• MUST validate redirect URIs against those in metadata document
• MUST validate document structure is valid JSON and contains required fields
• SHOULD follow security considerations in CIMD spec Section 6

Pre-registration (SHOULD)

• Clients SHOULD support option for static client credentials
• Support hardcoded client ID or user-entered credentials
• Handle both confidential and public client types

Dynamic Client Registration (MAY)

• Clients and authorization servers MAY support RFC 7591
• Included for backwards compatibility with earlier MCP versions

Scenarios to Cover

Client ID Metadata Documents - Positive Tests

1. Client uses HTTPS URL as client_id
2. Client hosts valid metadata document with required fields
3. Client's client_id in metadata matches document URL
4. Authorization server fetches and validates metadata document
5. Authorization server caches metadata respecting HTTP headers
6. Client uses private_key_jwt authentication (optional)

Client ID Metadata Documents - Negative Tests

1. Client uses non-HTTPS URL as client_id
2. Client metadata document missing required fields
3. Client's client_id in metadata doesn't match document URL
4. Authorization server fails to validate redirect URIs
5. Metadata document contains invalid JSON
6. Client uses URL without path component

Pre-registration - Positive Tests

1. Client successfully uses pre-registered client ID
2. Client handles confidential client credentials
3. Client handles public client (no client secret)

Pre-registration - Negative Tests

1. Client uses invalid pre-registered credentials
2. Client fails to handle credential types correctly

Dynamic Client Registration - Positive Tests

1. Client successfully registers via RFC 7591
2. Client receives and stores client credentials
3. Client uses registered credentials in authorization flow

Dynamic Client Registration - Negative Tests

1. Client fails to handle registration errors
2. Client uses invalid registration request format

Implementation Notes

• Register spec references in src/scenarios/client/auth/spec-references.ts

• Build on existing auth scenarios in src/scenarios/client/auth/

• Follow patterns from basic-dcr.ts and basic-metadata.ts

• Include at least one negative test scenario per registration method

• We need to decide how to handle the https URL requirement for CIMD in tests:

  • in general, we don't want CI to have a dependency on an external URL
  • self-registered cert's seems annoying to set up
  • One option is have an HTTPS url passed in (e.g. https://conformance-test.local/metadata.json), but in the server, we just swap it to a different URL, like fake DNS. (i.e. do the non-compliant thing in the test, don't force the client to do anything).
  • one even simpler option is to require a fixed URL, which doesn't resolve to anything, and we just hardcode the client metadata, w/ the provided redirect_uri registered in it.

• One other issue we'll have to tackle is steering the conformance client in order to have it use pre-registered client credentials. One option, which is a fine first pass, is to have the pre-registered test client be a separate client. However, it would be convenient to be able to use 1 client for all auth tests, and be able to steer it during the test execution in order to simulate out-of-band behavior (e.g. pre-registration). This could be by always passing a 2nd optional JSON argument, and we assume that a scenario knows what to do with that based on the "suite". A suite is an informal idea so far where you can run a single client (or server) against multiple tests in a suite without having to modify the client, e.g. the behavior can all be there, and it's the other side of the connection that changes (e.g. the everything-server is a server that can be run through a suite of many different client behaviors and checks since it's possible to implement in 1 server).

Acceptance Criteria

• Test scenarios cover Client ID Metadata Documents per spec
• Test scenarios cover pre-registration flows
• Test scenarios cover Dynamic Client Registration per RFC 7591 (already implemented)
• Tests validate metadata document format and required fields
• Tests verify client_id matching between metadata and URL
• Tests cover security considerations (SSRF protection, localhost risks)
• At least one negative test included for each registration method
• Spec references registered in check definitions file
• All checks properly documented and follow existing patterns