stacklok / toolhive / 26765698014

push

github

dcr: support RFC 8414 §3.1 path-insertion in discovery-URL → issuer derivation (#5395)

* dcr: support RFC 8414 §3.1 path-insertion in discovery-URL → issuer derivation

`deriveExpectedIssuerFromDiscoveryURL` recovers the issuer the upstream is
expected to claim in its discovery document. It already handled the
suffix-append form (e.g. https://mcp.atlassian.com/.well-known/oauth-authorization-server
→ https://mcp.atlassian.com) and the issuer-suffix multi-tenant style
(.../tenants/acme/.well-known/openid-configuration → .../tenants/acme),
but the comment block explicitly opted out of the RFC 8414 §3.1
path-insertion form — operators on that pattern had to fall back to
`dcr_config.registration_endpoint` to bypass discovery entirely.

That gap rejects providers that publish a path-component issuer per the
letter of the RFC. Datadog's MCP authorization server is one such
provider: its discovery URL
`https://mcp.us5.datadoghq.com/.well-known/oauth-authorization-server/v1/mcp`
declares issuer `https://mcp.us5.datadoghq.com/v1/mcp`, and DCR
discovery aborts with:

  issuer mismatch (RFC 8414 §3.3): expected
  "https://mcp.us5.datadoghq.com", got "https://mcp.us5.datadoghq.com/v1/mcp"

Recognise the path-insertion form by checking for the well-known segment
as a path *prefix* followed by a tenant path (HasPrefix(path, suffix+"/")),
trimming just the well-known segment to recover origin + tenant path.
Disambiguated from the existing suffix-append case by position: the
well-known segment at the end of the path is suffix-append; at the start
with more path following is path-insertion. The two cases cannot both
match a single URL.

Tests cover the new branch for both the OAuth and OIDC suffix variants
plus a multi-segment tenant. All existing cases continue to pass.

Per RFC 8414 §3 (the well-known URI is formed by inserting the
well-known suffix between host and path of the issuer) and RFC 8615
(well-known URI conventions).

Signed-off-by: Juzer Patanwala <juze... (continued)

10 of 10 new or added lines in 1 file covered. (100.0%)

65761 of 99802 relevant lines covered (65.89%)

64.21 hits per line