feat: sign in to OAuth-protected MCP servers

[jibraaan]

Follow-up to #52.

Workflow

Many MCP servers, such as Google, GitHub or Notion style services, ask you to sign in rather than paste a bearer token. With this change, the owner adds the server without a token. If it requires an account, the connection shows needs sign-in:

1. Sign in opens the service's sign-in and consent page in a new tab.
2. After approval, the service redirects back to OpenDots, which shows "Signed in to …".
3. The Dot settings update on their own and list the service's tools. Everything from feat: per-Dot MCP connections with owner approval for non-read-only tools #52 then applies: per-tool access, Ask first, and the stored-request approvals.

Access tokens refresh automatically. If the service stops accepting them, the connection asks the owner to sign in again, and its tools are hidden from the Dot until they do. Sign out forgets the tokens and stops the Dot's active turn, like other access changes.

How it works

• The official MCP SDK runs the spec flow: protected-resource and authorization-server discovery, dynamic client registration, PKCE, code exchange and refresh. StoredOAuthProvider (src/server/connection-oauth.ts) persists the SDK's state per connection in mcp_oauth, and the transport gets it as authProvider.
• POST /api/connections/:id/sign-in (owner-only) returns the authorization URL, and only http(s) URLs are accepted. The client opens the tab during the click so popup blockers allow it. If a blocker stops it anyway, a visible "Open sign-in" link appears. The settings poll until the connection is signed in.
• GET /oauth/mcp/callback sits outside /api, because a browser redirect can't carry the owner token. A single-use state that expires after 10 minutes ties it to an owner-started sign-in. Background refreshes during tool calls never create or replace that state. The result page escapes all text.
• Tokens and client registrations stay server-side and are never returned to the browser. The UI only sees authMode and signedIn.
• New, optional PUBLIC_URL, validated at startup: http(s), no credentials. It sets the callback base when OpenDots runs behind a proxy or on a hosted domain. Without it, the callback uses the origin the owner's browser is on. The dev proxy forwards /oauth to the API server.

Verification

• npm run check-format, lint, typecheck, test (306 passing) and build all pass.
• tests/connection-oauth.test.ts runs a real OAuth-protected MCP server: the SDK's mcpAuthRouter and bearer middleware, plus a demo provider extended with refresh tokens and a 401 invalid_token for expired tokens. It covers:
  • full sign-in through the consent redirect
  • tools discovered after sign-in
  • tokens never returned
  • a tool call, then a silent refresh after access tokens expire
  • replayed, forged and denied callbacks
  • escaping on the callback page
  • sign-out hiding tools and prompting a new sign-in
  • PUBLIC_URL validation
• Live, in the app on this branch, against that server run locally: add, sign in, consent, callback ("Signed in to Calendar"), then settings showing "signed in" with the tool listed, with PUBLIC_URL set. Earlier testing in my fork also covered the popup-blocked fallback link.
• Dependencies: express and @types/express are dev dependencies for the test fixture (express was already installed via the MCP SDK). package-lock.json differs from main only by those two root entries.
• Not covered: a real third-party OAuth provider's consent screen, since none was available here. The flow follows the MCP authorization spec through the SDK.

🤖 Generated with Claude Code