mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-26 18:31:34 +01:00
DottaandClaude Opus 5
a98c363a92
An unknown standards-compliant MCP endpoint could discover an OAuth challenge but never complete one: `ensureOAuthClient` only reached registration when a gallery `AppDefinition` method listed `ownershipModes: ["dcr"]`, so a URL-only connection died on "OAuth client id is not configured". Replace that gate with the registration preference the current MCP client-registration guidance recommends — a client the deployment preconfigured for the issuer, then a Client ID Metadata Document, then dynamic registration, then client credentials the operator preregistered — and allow a generic connection to register only after protected-resource/authorization-server discovery actually produced a metadata document. Client material is bound to issuer, MCP resource, callback URI and company, and re-registers when any of those move; a manually supplied client refuses to auto-re-register and asks the operator instead. Bring the broker in line with current guidance along the way: RFC 8707 `resource` on authorization, token and refresh requests; RFC 8414 and OIDC path-aware `.well-known` variants for pathful issuers, with the issuer in the document validated against the one used to build the URL; RFC 9207 `iss` validated on the callback when returned; `application_type: web` on DCR; and `authKind`/issuer/resource persisted so refresh, reconnect, revoke and diagnostics stop treating a generic connection as `authKind: none`. Header names and values from a pasted config are re-checked here, at the last point before they become real request headers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>