--- title: "OAuth en un servidor MCP remoto: la API key ya no alcanza" excerpt: "Un servidor MCP HTTP que actúa sobre datos de usuarios necesita saber para qué recurso sirve un token, qué permisos trae y cómo se obtuvo. OAuth para MCP añade esas piezas; EMA reduce el consentimiento repetido, no la responsabilidad del servidor." date: "2026-09-08T12:00:00.000Z" category: "Inteligencia Artificial" tech_article: true author: name: "angel cruz" picture: "/images/me/angel-cruz.png" ogImage: url: "/images/open-graph/mcp-opengraph-image.png" seo_title: "OAuth para servidores MCP remotos: PKCE, resource y scopes" seo_description: "Cómo encaja OAuth en un servidor MCP por HTTP: Protected Resource Metadata, resource indicators, PKCE, scopes y autorización empresarial." --- **Una API key compartida no es una identidad suficiente para un servidor MCP remoto.** Cuando un cliente conecta herramientas que leen o modifican datos de personas, el servidor necesita distinguir el recurso al que va destinado el token, los permisos concedidos y el usuario o carga de trabajo que actúa. La especificación de autorización de MCP se apoya en OAuth. No convierte el protocolo en un proveedor de identidad, pero define cómo un cliente descubre el servidor de autorización y cómo presenta un token dirigido al servidor MCP correcto. ## Hay tres actores, no uno En una integración HTTP hay un cliente MCP, un authorization server y tu servidor MCP, que es el resource server. El error frecuente es configurar solo el proveedor de OAuth y asumir que la tool ya está protegida. El servidor debe publicar metadata de recurso protegido para que el cliente descubra qué authorization server usar. Al pedir un token, el cliente incluye el parámetro `resource`, que identifica al servidor MCP destinatario. Así un token emitido para otro recurso no debería ser aceptado por accidente. ```text Cliente descubre metadata del servidor MCP Cliente obtiene un token para ese resource con PKCE Cliente llama al servidor MCP con el token Servidor valida emisor, audiencia, scopes y sujeto ``` PKCE protege el intercambio del código de autorización, y la especificación lo exige a todo cliente MCP, no solo a los que no pueden guardar un secreto. Evita que quien intercepte el código lo canjee como si fuera el cliente legítimo. El método debe ser `S256`, y el cliente tiene que comprobar en la metadata del authorization server que hay soporte (`code_challenge_methods_supported`) antes de seguir: si el campo no está, la especificación dice que no continúe. ## Los scopes no reemplazan la autorización de negocio Un scope como `invoices:read` puede permitir que el cliente llame a una tool. Todavía debes comprobar que ese sujeto pueda leer *esa* factura en *ese* tenant. OAuth contesta "quién trae este token y para qué capacidad general"; tu dominio contesta "¿puede hacer esta operación sobre este registro?". Por eso una tool no debe aceptar un `tenant_id` enviado por el modelo y convertirlo directamente en una consulta. Deriva el tenant del token o de la sesión autenticada y filtra en el servidor. El modelo puede proponer argumentos, pero no inventar un límite de autorización. ## Qué cambia Enterprise-Managed Authorization Enterprise-Managed Authorization (EMA) es una extensión estable para el caso en que cliente y servidor MCP entran por el mismo single sign-on corporativo. Aplica el Identity Assertion JWT Authorization Grant: el cliente cambia con el proveedor de identidad el ID Token que ya tiene por un ID-JAG dirigido a ese servidor, y con ese grant pide el access token al authorization server del recurso. El usuario deja de conectar y autorizar a mano cada servidor de la organización, y el cliente puede renovar tokens sin interacción. El administrador, a cambio, gana visibilidad y control sobre qué servidores se pueden usar dentro de la empresa. EMA mueve el onboarding y la confianza entre partes, no los controles. Tu servidor sigue validando el token y aplicando scopes, tenant y políticas de negocio en cada tool. ## Evita mezclar transportes Estas reglas son para servidores MCP remotos sobre HTTP. Un servidor `stdio` que corre localmente tiene otro modelo de confianza y no debería fingir que implementa OAuth solo porque comparte herramientas con su versión remota. Documenta qué transporte expones y diseña sus credenciales para ese contexto. Para una primera implementación, empieza por una tool de solo lectura, con un scope estrecho y logs que muestren el sujeto, el recurso y el resultado. Después agrega escritura, siempre acompañada de una confirmación humana explícita o de una política de dominio inequívoca. ## Preguntas frecuentes ### ¿Necesito OAuth si mi MCP es local por stdio? No por las mismas razones que un servidor HTTP remoto. El proceso local se autentica y aísla de otra manera; no trasplantes una guía HTTP sin revisar el modelo de amenaza. ### ¿Un scope basta para limitar el acceso? No. Es un límite amplio del token. Aún debes validar el recurso concreto, el tenant y las reglas del negocio. ### ¿EMA elimina las pantallas de consentimiento para siempre? Centraliza la autorización en organizaciones que lo adopten. No elimina vencimientos, revocación ni la validación del token por el servidor. ## Fuentes - [Especificación MCP: autorización](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) - [Extensión Enterprise-Managed Authorization](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization.mdx) - [Servidor MCP para Laravel](/post/mcp-para-laravel) --- ## Sitemap Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md) Canónico HTML: [https://www.angelcruz.dev/post/oauth-servidor-mcp-remoto](https://www.angelcruz.dev/post/oauth-servidor-mcp-remoto)