Skip to content

Client Auth: Resource Parameter Validation #33

@pcarleton

Description

@pcarleton

Overview

Add conformance tests for OAuth Resource Indicators (RFC 8707) implementation, ensuring clients correctly specify target resources and use canonical server URIs.

Specification References

Key Requirements from Specification

Resource Parameter (MUST)

  • Clients MUST implement Resource Indicators per RFC 8707
  • resource parameter MUST be included in both authorization and token requests
  • resource parameter MUST identify the MCP server the client intends to use the token with
  • resource parameter MUST use the canonical URI of the MCP server
  • Clients MUST send this parameter regardless of whether authorization servers support it

Canonical Server URI (SHOULD)

  • Clients SHOULD provide the most specific URI for the MCP server
  • Canonical form uses lowercase scheme and host components
  • Implementations SHOULD accept uppercase scheme/host for robustness

Resource Identifier Options

The resource identifier can be either:

  1. The full MCP request URL (e.g., https://mcp.example.com/public/mcp)
  2. The base URL (e.g., https://mcp.example.com)

This aligns with the resource parameter in RFC 9728 and the Protected Resource Metadata discovery requirements.

Valid Canonical URI Examples

  • https://mcp.example.com/mcp
  • https://mcp.example.com
  • https://mcp.example.com:8443
  • https://mcp.example.com/server/mcp

Invalid Canonical URI Examples

  • mcp.example.com (missing scheme)
  • https://mcp.example.com#fragment (contains fragment)

URI Trailing Slash

  • Both https://mcp.example.com/ and https://mcp.example.com are valid
  • Implementations SHOULD consistently use form without trailing slash unless semantically significant

Scenarios to Cover

Positive Tests

  1. Client includes resource parameter in authorization request
  2. Client includes resource parameter in token request
  3. Client uses correct canonical URI format (full MCP request URL)
  4. Client uses correct canonical URI format (base URL)
  5. Client handles URIs with port numbers correctly
  6. Client handles URIs with path components correctly
  7. Client normalizes scheme and host to lowercase

Negative Tests

  1. Client omits resource parameter from authorization request
  2. Client omits resource parameter from token request
  3. Client uses invalid URI (missing scheme)
  4. Client uses invalid URI (contains fragment)
  5. Client uses inconsistent URIs between requests
  6. Client fails to normalize canonical URI properly

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 requirement
  • Test both full URL and base URL as resource identifiers

Acceptance Criteria

  • Test scenarios cover resource parameter implementation per spec
  • Test scenarios cover canonical server URI requirements
  • Tests validate resource parameter presence in both authorization and token requests
  • Tests verify correct URI format and normalization
  • Tests cover both full MCP request URL and base URL as resource identifiers
  • At least one negative test included for each major requirement
  • Spec references registered in check definitions file
  • All checks properly documented and follow existing patterns

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions