Skip to content

Add a CIMD showcase fixture that serves its own client metadata document #2306

Description

@cliffhall

Summary

Add test-servers/configs/oauth-cimd-http.json and teach the composable test server to host a CIMD client metadata document, so URL-based client IDs (SEP-991) can be exercised against a local server.

Why

In CIMD the client_id is a URL that the authorization server dereferences to learn the client's metadata. Nothing in this repo served such a document, so a fixture could advertise client_id_metadata_document_supported and still be unusable — exercising CIMD meant standing up a second host by hand.

That is why #2242 shipped verified by its tests alone. The v2.6.0 release smoke recorded it as the one contribution with an observable UI surface (Connection Info reporting the registration kind) that could not be reached, and named this fixture as the missing piece.

Scope

  • oauth.clientMetadata / oauth.clientMetadataPath config, and a route serving the document when supportCIMD is on. The document's client_id is derived from the request, not from a configured issuer, so it stays correct when the harness picks the port.
  • oauth-cimd-http.json, with supportDCR: false — see below.
  • An integration test covering the fixture's own invariants.
  • docs/test-servers.md section.

supportDCR: false is the load-bearing choice

With DCR available, a CIMD failure silently succeeds via dynamic registration and the reproduction proves nothing. This is not hypothetical: while building this, a misconfigured run connected happily and reported Dynamic (DCR) with a test_client_… id, which looks like success until you read the client id. With DCR off, CIMD is the only path that can complete, so reaching a connected state is itself the assertion.

The integration test pins this (expect(metadata.registration_endpoint).toBeUndefined()) precisely so nobody "helpfully" turns DCR on later.

What this does not fix

The Inspector requires the CIMD metadata URL to be HTTPS with no loopback exemption, so this server's own http:// document is not a usable clientMetadataUrl. Driving the UI end to end still needs a self-signed HTTPS listener plus NODE_TLS_REJECT_UNAUTHORIZED=0 for the test server's own fetch. That asymmetry is #2305; this issue delivers the fixture, and #2305 is what makes it pleasant to use.

Verified with that workaround during the v2.6.0 smoke: Connection Info read Client registration — Client ID Metadata (CIMD) with the client id equal to the metadata URL, against a server advertising no registration endpoint.

Acceptance

  • oauth-cimd-http.json boots and serves /client-metadata.json
  • The document's client_id equals the URL it was fetched from
  • The document is not served when supportCIMD is false
  • AS metadata advertises CIMD and no registration_endpoint
  • docs/test-servers.md documents the fixture, the install-level client.json location, and the HTTPS constraint
  • npm run local:gate passes

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

authIssues and PRs related to authorizationenhancementNew feature requestv2Issues and PRs for v2

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions