add OAuth authorization support to HTTP McpServer

Aperta
  • Qualcosa non va?
#10,402 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@effect-bot ci sta già lavorando.

Dal 5/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

enhancement
What is the problem this feature would solve?

I've been waiting on this every since I heard there were going to be some Auth primatives to build upon, but with #9174 slowly taking shape I think its good to now open this issue for discussion

With the McpClient and McpServer, plus Auth, we should now be able to protect an MCP endpoint, expose its verified caller to handlers, and enforce application permissions in an elegant and extensible way.

Looking at how @yielded/auth already provides OAuth scopes, bearer middleware, request-local access, and JOSE-backed verification. This should work by reuse similar APIs while addressing external issuers and MCP-specific permission checks.

What is the feature you are proposing to solve the problem?

The plan should be to add complementary server and client integrations using the shared auth primitives being migrated into Effect. Keep token verification and OAuth exchanges in the auth packages, with MCP handling protocol-specific discovery and challenges.

Server authentication

Let applications configure a trusted issuer, MCP resource identifier, token verifier, and scopes. The McpServer can then publish protected-resource metadata, validate audience-bound tokens per request, and provide verified access to handlers. Support operation-specific HTTP 401 and 403 challenges, both HTTP server lifecycles, and composition with existing authentication.

The integration entry point can follow existing HTTP middleware composition:

const ProtectedMcp = McpServer.layerHttp({
  name: "Documents",
  version: "1.0.0",
  path: "/mcp",
  protocols: [McpProtocol.v2026_07_28],
  registrations: DocumentTools
}).pipe(Layer.provide(ResourceAuthLive))

ResourceAuthLive represents auth-owned middleware configured with the issuer, resource, verifier, and scopes. Reuse Yielded's middleware and access context, scope declarations, and JOSE where applicable. External-issuer token mapping and per-operation scope declarations still need design.

Client authentication

Let McpClient discover resource and authorization-server metadata, complete authorization-code flows using PKCE, and attach tokens to requests. Should support refresh and bounded retries for insufficient-scope challenges. Applications supply browser or native sign-in interaction, callback handling, and secure credential storage.

An auth-aware HTTP client is one possible integration entry point:

const DocumentClient = McpClient.layerHttp({
  name: "document-client",
  version: "1.0.0",
  url: "https://docs.example.com/mcp",
  protocol: McpProtocol.v2026_07_28
}).pipe(Layer.provide(OAuthHttpClientLive))

OAuthHttpClientLive represents an application-composed HTTP client using the auth package's OAuth primitives and application interaction and storage hooks. Its construction and whether MCP needs a dedicated auth-provider hook remain open.

Dependencies and specifications

Coordinate with #9884, extracted from #9174. Reuse its authorization-code, PKCE, and refresh primitives for the client. The server also needs agreement on resource-facing APIs beyond that PR's current scope. JOSE #9883 has merged; reuse Yielded's access-token verification without assuming its token profile fits every issuer.

Follow MCP 2026-07-28 authorization, discovery, client registration, and security requirements, accounting for supported HTTP revisions. Will need to double check what this means for the AdapterProtocols, but it should be that the protocol schema can manage any discrepencies.

A new authorization server, upstream account management, and enterprise grant exchanges are separate work.

What alternatives have you considered?
  • Application-owned HTTP middleware already works, as shown by T3 Code, but leaves discovery, challenges, and auth adaptation to each application.
  • Yielded's hosted OAuth server example is useful prior art. Requiring that full issuer setup would add login, signing keys, and grant storage to applications that only need to accept externally issued tokens.
Lingua principale
TypeScript
Stelle
16.7k
Fork
808
Merge medio
11h 40m
PR unite (30g)
827

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Effect-TS/effect

Tutte le issue di Effect-TS/effect

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.