add OAuth authorization support to HTTP McpServer

Abierto
  • ¿Algo no está bien?
#10,402 0 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@effect-bot ya está trabajando en esto.

Desde el 5/11/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.
Lenguaje dominante
TypeScript
Estrellas
16.7k
Forks
808
Merge medio
12 h 16 min
PR fusionados (30 d)
809

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Effect-TS/effect

Todos los issues de Effect-TS/effect

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.