Support CIMD OAuth for API sources#1177
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-marketing | ae8cb60 | Commit Preview URL Branch Preview URL |
Jun 28 2026, 09:56 AM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-cloud | ae8cb60 | Jun 28 2026, 09:56 AM |
RhysSullivan
force-pushed
the
support-posthog-cimd-oauth
branch
from
3d5505c to
74f1186
Compare
@executor-js/cli
@executor-js/config
@executor-js/execution
@executor-js/sdk
@executor-js/codemode-core
@executor-js/runtime-quickjs
@executor-js/plugin-file-secrets
@executor-js/plugin-graphql
@executor-js/plugin-keychain
@executor-js/plugin-mcp
@executor-js/plugin-onepassword
@executor-js/plugin-openapi
executor
commit: |
Cloudflare previewTorn down — the PR is closed. |
Detect OAuth Client ID Metadata Document (CIMD) support on an API's authorization server (client_id_metadata_document_supported) and use the client-id-as-URL public PKCE flow instead of Dynamic Client Registration, so adding PostHog's API connects without minting a provider-side app. - oauth-discovery: parse client_id_metadata_document_supported from AS metadata - oauth-client: carry supportsClientIdMetadataDocument + RFC 8707 resource - openapi plugin: derive/preview CIMD auth and wire the add-source flow - serve the client-id metadata document; add-account + oauth-client-form UI - tests across core/sdk, core/api, openapi, and react
An OpenAPI source declares the full per-operation scope catalog (PostHog declares ~200). Those are requested broadly to unlock as many tools as possible, but a provider that narrows the grant to the user's actual access is healthy, not in need of reconnect. Only treat custom (user-configured) scopes as required, never the spec catalog, via reconsentRequiredScopes. Also fixes a garbled reconnect message in the accounts list.
Greptile SummaryThis PR adds CIMD (Client ID Metadata Document) OAuth support so an API source like PostHog can be connected without Dynamic Client Registration or a manually-registered provider app — instead, the host's metadata-document URL is used directly as the
Confidence Score: 3/5The CIMD and OpenAPI discovery paths are well-tested and look correct, but the reconnect-suppression change uses The CIMD orchestration, provider-error short-circuit, and scope-pruning logic are solid and well-covered by tests. The concern is packages/react/src/plugins/oauth-reconnect.ts and packages/react/src/components/accounts-section.tsx need a second look to confirm the intent is to suppress reconnect for all spec-declared OAuth methods, not only OpenAPI spec sources. Important Files Changed
Sequence Diagram%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant UI as AddAccountModal
participant Plugin as OpenAPI Plugin
participant Probe as oauth.probe
participant AS as Authorization Server
participant DB as OAuth Client Store
participant Popup as OAuth Popup
UI->>Plugin: previewSpec(specUrl)
Plugin->>Probe: probe(candidate URL)
Probe->>AS: GET /.well-known/oauth-authorization-server
AS-->>Probe: "{ client_id_metadata_document_supported: true }"
Probe-->>Plugin: "OAuthProbeResult { clientIdMetadataDocumentSupported: true }"
Plugin-->>UI: SpecPreview with DiscoveredOAuth2 preset
UI->>UI: "isCimd = true (skip DCR)"
UI->>UI: handleCimdConnect()
UI->>DB: "createOAuthClient({ clientId: metadataDocUrl, clientSecret: "" })"
DB-->>UI: OAuthClientSlug
UI->>Popup: "oauth.start({ client: slug, ... })"
Popup->>AS: "GET /oauth/authorize?client_id=metadataDocUrl"
AS->>AS: Fetch client metadata document
AS-->>Popup: authorization code
Popup-->>UI: Connection created
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant UI as AddAccountModal
participant Plugin as OpenAPI Plugin
participant Probe as oauth.probe
participant AS as Authorization Server
participant DB as OAuth Client Store
participant Popup as OAuth Popup
UI->>Plugin: previewSpec(specUrl)
Plugin->>Probe: probe(candidate URL)
Probe->>AS: GET /.well-known/oauth-authorization-server
AS-->>Probe: "{ client_id_metadata_document_supported: true }"
Probe-->>Plugin: "OAuthProbeResult { clientIdMetadataDocumentSupported: true }"
Plugin-->>UI: SpecPreview with DiscoveredOAuth2 preset
UI->>UI: "isCimd = true (skip DCR)"
UI->>UI: handleCimdConnect()
UI->>DB: "createOAuthClient({ clientId: metadataDocUrl, clientSecret: "" })"
DB-->>UI: OAuthClientSlug
UI->>Popup: "oauth.start({ client: slug, ... })"
Popup->>AS: "GET /oauth/authorize?client_id=metadataDocUrl"
AS->>AS: Fetch client metadata document
AS-->>Popup: authorization code
Popup-->>UI: Connection created
|
RhysSullivan
force-pushed
the
support-posthog-cimd-oauth
branch
from
74f1186 to
ae8cb60
Compare
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const filterAuthorizationCodeScopes = ( | ||
| client: LoadedOAuthClient, | ||
| requestedScopes: readonly string[], | ||
| ): Effect.Effect<readonly string[], never> => | ||
| Effect.gen(function* () { | ||
| if (requestedScopes.length === 0) return requestedScopes; | ||
| const resource = client.resource | ||
| ? yield* discoverProtectedResourceMetadata(client.resource, discoveryOptions).pipe( | ||
| Effect.catch(() => Effect.succeed(null)), | ||
| Effect.provide(httpClientLayer), | ||
| ) | ||
| : null; | ||
| const issuer = | ||
| resource?.metadata.authorization_servers?.[0] ?? new URL(client.authorizationUrl).origin; | ||
| const as = yield* discoverAuthorizationServerMetadata(issuer, discoveryOptions).pipe( | ||
| Effect.catch(() => Effect.succeed(null)), | ||
| Effect.provide(httpClientLayer), | ||
| ); | ||
| return intersectScopes(requestedScopes, as?.metadata.scopes_supported); | ||
| }).pipe(Effect.catch(() => Effect.succeed(requestedScopes))); |
There was a problem hiding this comment.
Effect.catch does not cover synchronous URL-constructor throws
The new URL(client.authorizationUrl).origin call on line 381 sits inside Effect.gen. If authorizationUrl is ever an invalid URL string, it throws synchronously; Effect.gen wraps that as an Effect defect (die), which Effect.catch (typed-error handler) does not intercept — only Effect.catchCause would. In normal operation authorizationUrl is validated at client creation, so this path is almost unreachable, but swapping the outer catch to Effect.catchCause would make the best-effort guarantee unconditional.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| export function reconsentRequiredScopes( | ||
| method: | ||
| | { | ||
| readonly source: "spec" | "custom"; | ||
| readonly oauth?: { readonly scopes?: readonly string[] }; | ||
| } | ||
| | undefined, | ||
| ): readonly string[] | undefined { | ||
| if (method == null || method.source === "spec") return undefined; | ||
| return method.oauth?.scopes; | ||
| } |
There was a problem hiding this comment.
reconsentRequiredScopes returns undefined whenever method.source === "spec". Because authMethodFromDescriptor unconditionally assigns source: "spec" to every catalog-declared auth method — including GitHub, Linear, Notion, or any other non-OpenAPI integration — this change silently disables the "Reconnect to grant access" banner for those integrations too. If a non-OpenAPI plugin adds a new required scope later, existing connections will never be flagged for re-consent.
The intent per the PR description is to prevent spurious reconnect prompts specifically for OpenAPI sources that declare hundreds of opportunistic scopes. A narrower guard — e.g. checking for a scopePolicy: "opportunistic" flag on the oauth descriptor, or comparing the method's template prefix — would achieve that without suppressing reconnect for every other integration.
| const filterAuthorizationCodeScopes = ( | ||
| client: LoadedOAuthClient, | ||
| requestedScopes: readonly string[], | ||
| ): Effect.Effect<readonly string[], never> => | ||
| Effect.gen(function* () { | ||
| if (requestedScopes.length === 0) return requestedScopes; | ||
| const resource = client.resource | ||
| ? yield* discoverProtectedResourceMetadata(client.resource, discoveryOptions).pipe( | ||
| Effect.catch(() => Effect.succeed(null)), | ||
| Effect.provide(httpClientLayer), | ||
| ) | ||
| : null; | ||
| const issuer = | ||
| resource?.metadata.authorization_servers?.[0] ?? new URL(client.authorizationUrl).origin; | ||
| const as = yield* discoverAuthorizationServerMetadata(issuer, discoveryOptions).pipe( | ||
| Effect.catch(() => Effect.succeed(null)), | ||
| Effect.provide(httpClientLayer), | ||
| ); | ||
| return intersectScopes(requestedScopes, as?.metadata.scopes_supported); | ||
| }).pipe(Effect.catch(() => Effect.succeed(requestedScopes))); |
There was a problem hiding this comment.
authorization_code OAuth start
filterAuthorizationCodeScopes issues up to two external HTTP requests (protected-resource metadata, then authorization-server metadata) on every oauth.start call for clients that have a resource URL configured. This is unconditional for the "declare" scope policy, meaning BYO OAuth apps and CIMD clients with a resource are also affected, not just the stale-scope pruning path. A slow or unreachable server adds latency to the user-visible "Connecting…" state; the silent fallback (returning the original scopes) means the pruning silently does nothing on failure, which is safe but hard to observe.
1 participant
What
Adds OAuth Client ID Metadata Document (CIMD) support so an API source can be
connected without Dynamic Client Registration or a manually registered app.
When an authorization server advertises
client_id_metadata_document_supported,the connect flow uses a public PKCE client whose
client_idis this host'smetadata-document URL. The provider fetches that document to learn the client's
name and redirect URIs, so there is no provider-side app to create. This is what
lets a provider like PostHog be connected directly from its API spec.
Changes
client_id_metadata_document_supportedfrom RFC 8414authorization-server metadata; carry
supportsClientIdMetadataDocumentand theRFC 8707 resource indicator on the auth method and probe result.
client; the existing metadata-document route serves the client document.
it through the add-source path.
(an OpenAPI source can declare hundreds). They are requested broadly but not
individually required, so a provider that narrows the grant to the user's
actual access is healthy. Only custom (user-configured) scopes stay required,
so large API sources no longer show a spurious "reconnect to grant access".
Tests
Unit coverage across core SDK (discovery, scope handling), core API (client
metadata document), the OpenAPI plugin, and React (add-account, client form,
reconnect).
bun run typecheckand the affected package tests pass.Notes
Verified by hand against a live provider: detection, document fetch, and the
authorize handshake work. A full redirect round-trip needs the host's metadata
document to be publicly reachable (a loopback or tunneled origin), since the
provider fetches the
client_idURL.