Autenticación MCP en el cursor: OAuth, claves de API y configuración segura (Guía 2026)

La autenticación MCP determina cómo el agente de IA de Cursor demuestra quién es cuando se comunica con herramientas y servicios externos. Si no lo haces, todos los servidores de MCP funcionan de par en par o se basan en un token estático en texto plano. Si lo haces bien, el agente se conectará a GitHub, Slack o a tus API internas con credenciales con un alcance específico, rotativas y auditables.

El Especificación MCP obtuvo la autorización OAuth 2.1 estandarizada en su marzo de 2025 revisión. junio de 2025 seguido de la separación formal de los servidores MCP de los servidores de autorización y la exigencia de metadatos de recursos protegidos (RFC 9728). A continuación, el Revisión de noviembre de 2025 incorporó los documentos de metadatos de identificación de cliente (CIMD) como método de registro preferido e hizo que PKCE no fuera negociable para todos los clientes. Cursor incorporó el soporte de OAuth en v1.0 en junio de 2025, lo que lo sitúa entre los primeros IDE en ofrecer autenticación MCP basada en navegador.

Hay dos cosas que hacen que valga la pena entender el modelo de autenticación de Cursor: regula lo que tu agente puede tocar y define el radio de explosión cuando algo se rompe.

Cómo funciona la autenticación MCP

La autenticación MCP reside en la capa de transporte. El mecanismo que utilices depende de si el servidor se ejecuta de forma local a través de stdio o de forma remota a través de HTTP transmisible.

Servidores de estudio gestionar completamente la autenticación fuera del protocolo MCP. El proceso del servidor hereda las variables de entorno de Cursor (normalmente claves o tokens de API) y las usa para autenticarse en los servicios iniciales, como la API de GitHub, una base de datos o un proveedor de nube. La especificación MCP es explícita en este caso: las implementaciones de stdio deben obtener las credenciales del entorno, no de un flujo de OAuth.

Servidores remotos en Streamable HTTP seguir un camino diferente. La especificación MCP recomienda OAuth 2.1 y el protocolo de enlace involucra a tres partes:

El cursor desempeña el papel de cliente OAuth. El servidor MCP funciona como un servidor de recursos de OAuth 2.1: valida los tokens pero nunca los emite. Un servidor de autorización (Okta, Auth0, Azure AD o uno que ejecute el operador del servidor MCP) se encarga de la autenticación de los usuarios y distribuye los tokens.

Esta es la secuencia real. El cursor lanza una solicitud en el servidor MCP sin ningún token adjunto. El servidor vuelve con la etiqueta 401 Unauthorized y un encabezado WWW-Authenticate que apunta a su Metadatos de recursos protegidos documento. El cursor coge ese documento, determina con qué servidor de autorización hablar, se registra automáticamente (mediante el registro dinámico de clientes o CIMD) y lo deja en una ventana del navegador para iniciar sesión.

Una vez que autorices, el servidor de autorización emite un token de acceso. El cursor guarda ese token y lo adjunta a cada solicitud posterior.

PICAR (Proof Key for Code Exchange) recorre todo el flujo. El cursor genera un par code_verifier y code_challenge antes de empezar. Incluso si un atacante consigue interceptar el código de autorización en pleno vuelo, no puede cambiarlo por un token sin el verificador original.

Métodos de autenticación en el cursor

El cursor le ofrece tres maneras de autenticar los servidores MCP. Cada uno se asigna a un escenario de implementación diferente.

Variables de entorno para servidores de estudio

La mayoría de los servidores MCP locales prueban su identidad ante las API ascendentes mediante variables de entorno. El cursor las inyecta en el proceso del servidor en el momento del lanzamiento.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

El campo env acepta pares clave-valor. El cursor los lleva directamente al proceso generado. Tu token no aparecerá en la interfaz de usuario ni en los registros de Cursor. Pero sí se encuentra en texto plano dentro de mcp.json. Confirma ese archivo en Git y acabas de enviar tus credenciales a todos los colaboradores o, lo que es peor, a un repositorio público.

Mitigación: Haga referencia a las variables de entorno a nivel del sistema con la sintaxis $ {env:variable_name} en lugar de pegar valores sin procesar:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_TOKEN}"
      }
    }
  }
}

Ahora el token real reside en tu perfil de shell o en un administrador de secretos. El archivo mcp.json contiene solo un puntero, por lo que puedes controlar su versión de forma segura.

Encabezados estáticos para servidores remotos

Algunos servidores remotos no admiten OAuth. En esos casos, puedes introducir una clave API estática o un token portador en los encabezados HTTP. El cursor envía estos encabezados junto con cada solicitud al punto final del servidor.

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

La sintaxis de referencia de la variable de entorno también funciona en los encabezados:

{
  "mcpServers": {
    "internal-api": {
      "url": "https://mcp.internal.company.com/v1",
      "headers": {
        "Authorization": "Bearer ${env:INTERNAL_API_KEY}"
      }
    }
  }
}

Los encabezados estáticos son muy fáciles de configurar. También tienen todas las desventajas de las credenciales de larga duración: no caducan, no tienen un alcance por sesión y, al rotarlas, tendrás que tocar el archivo de configuración de cada desarrollador.

OAuth 2.1 para servidores remotos

OAuth es lo que la especificación MCP realmente recomienda para los servidores remotos, y Cursor v1.0 trajo soporte nativo. Así es como se ve la experiencia de principio a fin:

1. Coloque la URL de un servidor remoto en mcp.json, sin necesidad de encabezados de autenticación.
2. Abrir Configuración del cursor → Herramientas y MCP. El servidor aparece con un color azul. Conectar botón y la etiqueta «Necesita autenticación» debajo de su nombre.
3. Golpear Conectar. El cursor abre el navegador predeterminado y abre la página de inicio de sesión del servidor de autorización.
4. Inicie sesión y conceda los permisos que solicita.
5. Tras la autorización, el navegador redirige a cursor: //anysphere.cursor-mcp/oauth/callback. Tu sistema operativo devuelve la llamada a Cursor, que intercambia el código de autorización por los tokens a través de PKCE con S256.
6. Las herramientas del servidor aparecen en la lista de herramientas de MCP, listas para que el agente las llame.

La configuración de JSON para un servidor respaldado por OAuth parece mínima porque es mínimo:

{
  "mcpServers": {
    "linear": {
      "url": "https://mcp.linear.app/mcp"
    }
  }
}

Sin fichas. Sin encabezados. Cursor se encarga de todo a través del flujo de detección de la especificación: los metadatos de los recursos protegidos del servidor indican a Cursor a dónde ir y PKCE bloquea el intercambio de tokens.

Los enlaces profundos con un solo clic también funcionan muy bien con OAuth. Si haces clic en el enlace «Añadir al cursor» de la página de documentos de un servidor, el cursor activará el flujo de OAuth de inmediato si el servidor lo necesita.

Riesgos de seguridad de autenticación

La autenticación MCP abre una superficie de ataque en cada punto del ciclo de vida de las credenciales: cómo las almacena, las envía, las intercambia y las revoca. Varias vulnerabilidades graves lo pusieron de manifiesto a lo largo de 2025.

CVE-2025-6514: Inyección de comandos mediante OAuth Discovery

Investigación de seguridad de JFrog encontró una falla crítica (CVSS 9.6) en mcp-remote, un popular paquete de npm que reenviaba conexiones OAuth para clientes MCP (incluido Cursor). ¿Cuál es el problema? El paquete capturó la URL authorization_endpoint de cualquier servidor MCP al que se conectara y nunca la desinfectó.

Un operador de servidor no autorizado podría incluir comandos de shell en la URL de ese punto final. Cuando mcp-remote intentaba abrir la URL en un navegador, el sistema operativo ejecutaba los comandos incrustados en lugar de cargar una página web.

Las versiones 0.0.5 a 0.1.15 se vieron afectadas. Más de 437 000 descargas. Cloudflare, Hugging Face y Auth0 habían apuntado a mcp-remote en sus documentos de integración con MCP. La solución llegó en la versión 0.1.16.

En esencia, la vulnerabilidad se remonta al modelo de confianza de OAuth: el cliente MCP preguntó a un servidor que no era de confianza «¿a dónde debo enviar a mi usuario para que inicie sesión?» y luego siguió ciegamente la respuesta. El parche agregó la validación y desinfección de las URL antes de que nada pasara a los controladores del sistema.

Toma de control de cuentas con un solo clic en servidores MCP remotos

Seguridad de obsidiana eliminó una serie de vulnerabilidades relacionadas con la apropiación de cuentas con un solo clic en los servidores MCP de producción gestionados por organizaciones conocidas. El denominador común a todas ellas es que la mayoría de los servidores MCP funcionan también como proxies de OAuth: cogen un código de autorización de Cursor y lo intercambian por fichas con el servicio principal.

Lo que salió mal fue estructural. Estos servidores no pudieron vincular los parámetros de estado de OAuth a las sesiones de usuario. No aplicaron el consentimiento de forma adecuada. Un atacante podía crear un enlace que canalizara un código de autorización a un URI de redireccionamiento controlado por el atacante.

Obsidian presentó los informes entre julio y agosto de 2025. Los vendedores los repararon antes de septiembre. La actualización de la especificación MCP de noviembre de 2025 añadió directrices de seguridad explícitas que cubrían exactamente estos patrones de ataque. Cabe destacar que, en aquel momento, solo 3 de los 78 servidores de autorización MCP que Obsidian probó eran compatibles con CIMD. La adopción de las nuevas funciones de especificación ha sido lenta.

Vulnerabilidades del cliente MCP mediante flujos de OAuth

Obsidian también está marcado errores críticos en los propios clientes de MCP: Gemini-CLI, VS Code, Windsurf y Cherry Studio tenían problemas (CVE-2025-54074 y tres CVE relacionados). La categoría de fallos era la ejecución remota de código mediante un manejo descuidado de las URL de autorización.

Cuando un cliente MCP abría un authorization_endpoint creado mediante el controlador de URL del sistema, un atacante podía ejecutar comandos arbitrarios del sistema operativo en la máquina del desarrollador. La especificación de autorización de MCP no restringe los esquemas de URL, por lo que los esquemas file://, javascript: o específicos de la plataforma podrían funcionar si el cliente omitiera la validación.

Credenciales en texto plano en mcp.json

El riesgo más común no necesita un número CVE. Cualquier clave de API que coloques en mcp.json se encuentra en texto sin cifrar en tu sistema de archivos. Si ese archivo termina en el directorio de un proyecto y alguien lo guarda en Git, la credencial se filtra a todos los colaboradores y, posiblemente, a todas las personas de Internet si se trata de un repositorio público. Las variables de entorno requieren al menos acceso al shell. Pero mcp.json es un archivo de configuración versionado que los desarrolladores comparten de forma rutinaria, sin pensárselo dos veces.

Cómo evolucionó la especificación de autenticación MCP

La especificación de autorización de MCP pasó por tres reescrituras importantes en 2025. Cada una de ellas abordó las fallas reales descubiertas en la versión anterior.

La revisión de junio de 2025 fue la más importante. Antes de ese cambio, cada desarrollador de servidores MCP tenía que crear sus propios puntos finales de autorización. De hecho, eso obligó a todos los creadores de servidores a convertirse en implementadores de OAuth, una idea terrible si te preocupa la seguridad. La especificación actualizada transfirió la emisión de tokens a proveedores de identidad dedicados (Okta, Auth0, Azure AD), tal y como ha funcionado la autenticación empresarial durante años.

En noviembre de 2025 se abordó de frente el registro de clientes. El DCR había supuesto un quebradero de cabeza porque la mayoría de los servidores de autorización empresariales no lo habilitan de forma inmediata. CIMD evita ese problema: cada cliente publica un documento de metadatos en una URL conocida, y los servidores de autorización toman decisiones de confianza basándose únicamente en el dominio. Más limpio, más práctico y más amigable para los entornos empresariales confinados.

Autenticación empresarial con una puerta de enlace MCP

Un solo desarrollador puede realizar un seguimiento de un puñado de claves de API sin muchos problemas. Un equipo no puede. Diez desarrolladores, cada uno con cinco servidores MCP, crean cincuenta configuraciones de credenciales diferentes: no hay una visibilidad centralizada sobre quién puede acceder a qué, sin rotación automática de claves ni registro de auditoría.

Un MCP Gateway reúne todo eso en un solo lugar. La puerta de enlace MCP de TrueFoundry admite tres métodos de autenticación al registrar servidores MCP ascendentes:

• Sin autenticación: Para entornos de demostración o API públicas. No es adecuado para la producción.
• Autenticación de cabecera estática: Para servidores que usan claves de API o tokens estáticos. La pasarela almacena la credencial de forma centralizada y la inyecta en cada solicitud saliente.
• OAuth2 y DCR: Para servidores que implementan OAuth. La puerta de enlace ejecuta todo el flujo de OAuth, almacena los tokens por usuario y los actualiza automáticamente antes de que caduquen.

El modelo operativo se parece al inicio de sesión único, pero para MCP. Los desarrolladores se autentican una vez con TrueFoundry, ya sea mediante un token de acceso personal (PAT) o mediante el proveedor de identidad de su organización (Okta, Azure AD). La puerta de enlace asigna esa identidad a la credencial descendente correcta para cada servidor MCP. Los desarrolladores individuales nunca tocan directamente un token de OAuth.

Desde el punto de vista administrativo, organizas los servidores en Grupos de servidores MCP y asigne el acceso por equipo o rol. Un desarrollador junior puede obtener acceso a GitHub de solo lectura. Un ingeniero sénior obtiene acceso completo de escritura y GitHub a JIRA. La puerta de enlace impone esos límites a nivel de protocolo, no a través de los archivos de configuración del sistema de honor.

Aquí hay un tutorial detallado para configurar la autenticación OAuth2 de Okta con servidores MCP a través de la puerta de enlace, que abarca el aprovisionamiento del servidor de autorización, la administración del alcance y la configuración de actualización de tokens.

Mejores prácticas para la autenticación MCP en Cursor

• Nunca envíe secretos a mcp.json. Usa la sintaxis de referencia $ {env:var} para los servidores de estudio. Usa OAuth en servidores remotos. Si los encabezados estáticos son tu única opción, haz referencia también a las variables de entorno en esos encabezados.
• Prefiere OAuth a los tokens estáticos para cualquier cosa remota. Los tokens de OAuth caducan. Puedes analizarlos. Puedes revocarlas. Los tokens estáticos no hacen nada de eso.
• Fija tu versión de mcp-remote si dependes de ella. El CVE-2025-6514 demostró que un proxy OAuth sin parches puede comprometer todo tu entorno de desarrollo. Ejecuta npx -y mcp-remote @0 .1.16 o una versión posterior, nunca @latest en producción.
• Restrinja los alcances de los tokens de forma agresiva. Cuando Cursor te guíe por un flujo de OAuth, otorga lo mínimo. Es de solo lectura para la búsqueda de código. Escriba el acceso solo cuando el agente realmente necesite crear problemas o fusionar relaciones públicas.
• Audite sus servidores conectados de forma regular. Ir a Configuración del cursor → Herramientas y MCP y revisa lo que está activo. Mata todo lo que ya no uses. Cada servidor conectado es una credencial activa que se almacena en la memoria.
• Mantenga el cursor actualizado. Cada versión incluye mejoras de gestión de OAuth y parches de seguridad. Una versión obsoleta de Cursor significa que se está ejecutando un código de autenticación desactualizado en su máquina.

Conclusión

La autenticación MCP en Cursor abarca una amplia gama, desde una clave de API de texto plano en un archivo JSON hasta un flujo completo de OAuth 2.1 con PKCE, registro dinámico y actualización automática de tokens. La elección del método correcto depende del modelo de despliegue del servidor y de la seriedad con la que te tomes la seguridad.

Para el desarrollo local, las variables de entorno combinadas con la sintaxis $ {env:var} mantienen las credenciales fuera del control de versiones. En el caso de los servicios remotos, OAuth elimina por completo la administración manual de los tokens de la ecuación. Y para equipos o empresas, un MCP Gateway como True Foundry centraliza el almacenamiento de credenciales, impone el acceso basado en roles y le brinda un registro de auditoría completo en cada conexión de MCP.

Explorar La puerta de enlace MCP de TrueFoundry o reserve una demostración para ver la autenticación MCP centralizada en acción.

Preguntas frecuentes

¿Qué métodos de autenticación admite Cursor para los servidores MCP?

Cursor ofrece tres: variables de entorno inyectadas en los procesos del servidor de estudio local, encabezados HTTP estáticos (tokens de portador o claves de API) para servidores remotos y OAuth 2.1 con PKCE para servidores remotos que ejecutan la especificación de autorización MCP. La compatibilidad con OAuth está disponible desde la versión 1.0 de Cursor, que se lanzó en junio de 2025.

¿Cómo funciona OAuth para MCP en Cursor?

Al agregar un servidor MCP remoto que requiere OAuth, el cursor sigue las especificaciones de autorización de MCP. Busca el servidor de autorización a través de los metadatos de recursos protegidos (RFC 9728), se registra como cliente, abre el navegador para que puedas iniciar sesión y conceder permisos y, a continuación, intercambia el código de autorización por tokens mediante PKCE. El cursor guarda los tokens de forma segura y los actualiza por sí solo cuando están a punto de caducar.

¿Es seguro almacenar las claves de API en mcp.json?

Poner claves de API sin procesar en mcp.json significa almacenar las credenciales en texto plano en el disco. Si ese archivo pasa al control de versiones, la clave se filtra. Cambie en su lugar la sintaxis de referencia $ {env:variable_name}, ya que extrae valores del entorno de su sistema durante el tiempo de ejecución. Para los servidores remotos, prefiera OAuth, que elimina por completo las credenciales estáticas.

¿Cuál era la vulnerabilidad de mcp-remote?

El CVE-2025-6514 era un error crítico de inyección de comandos (CVSS 9.6) en el paquete mcp-remote npm, que afectaba a las versiones 0.0.5 a 0.1.15. JFrog Security Research descubrió que el paquete reenviaba las URL de los puntos finales de autorización de OAuth a los responsables del sistema sin ningún tipo de desinfección. Un servidor MCP malintencionado podía crear una URL que ejecutara comandos arbitrarios del sistema operativo en la máquina del desarrollador. La versión 0.1.16 incluía la corrección.

¿Cómo gestionan las empresas la autenticación MCP a escala?

Con un MCP Gateway que se encarga de toda la administración de credenciales. La pasarela de TrueFoundry almacena y actualiza los tokens de OAuth para cada usuario, asigna las identidades organizacionales a las credenciales MCP posteriores y aplica políticas de acceso basadas en roles. Los desarrolladores inician sesión una vez y no vuelven a utilizar los tokens individuales de un servidor MCP.

¿Cursor admite CIMD para el registro de clientes de OAuth?

Todavía no, a principios de 2026. El cursor sigue recurriendo al registro dinámico de clientes (DCR) para sus flujos de OAuth. La especificación MCP de noviembre de 2025 introdujo el CIMD como el método de registro preferido, pero las publicaciones en los foros de la comunidad publicadas en enero de 2026 sugieren que la función no está disponible. Mientras tanto, el DCR sigue funcionando bien en la mayoría de los servidores MCP compatibles con OAuth.