Guía de autenticación MCP en Claude Code 2026

¿Qué es el MCP?

El MCP (Model Context Protocol) es un estándar abierto desarrollado por Anthropic que permite a Claude Code comunicarse con sistemas externos de forma estructurada.
En lugar de incluir la lógica de la herramienta en el mensaje, MCP crea una capa de middleware clara. Claude llama a la herramienta en un formato estándar. El servidor MCP recibe la solicitud y la reenvía al sistema real que la respalda, como una base de datos, una API interna, un servicio en la nube o un sistema de administración de tickets.

Puede pensar en el servidor MCP como una capa adaptadora. Un lado es Claude Code. El otro lado es su infraestructura física. Ayuda a ambas partes a entenderse sin tener que volver a escribir todo desde cero cada vez que se produce una integración.

Sin MCP, Claude Code solo respondía al texto. Con MCP, comienza a interactuar con el sistema real. Y a partir de ese momento, ya no es solo «la IA responde por diversión».

Por qué es importante la autenticación MCP

A medida que MCP se hace más popular, veo que muchas personas usan Claude Code para conectarse directamente a los sistemas internos. Algunos simplemente lo llaman pruebas de API. Otras se conectan directamente a los servicios que se ejecutan en AWS con una IAM estricta.

El problema es que, tan pronto como Claude puede llamar a la herramienta, representa algún tipo de identidad dentro de su sistema.

Si la configuración de autenticación no es correcta, el riesgo no aparecerá de inmediato. Es insidioso. Como cuando depuré una configuración de CloudFront en. No era más que una regla de reenvío de encabezados aparentemente inofensiva. Sin 500 errores, sin tiempo de inactividad. Pero, en realidad, el límite de acceso se amplió más de lo esperado. Debe examinar cuidadosamente los registros para encontrar el problema.

Lo mismo se aplica a MCP. Si elige un método de autenticación incorrecto, podría, sin darse cuenta:

• Exponga su clave de API a largo plazo
• Distribuya las claves de acceso a varios usuarios diferentes
• Otorga a Claude demasiados privilegios de los necesarios.

La conexión a una base de datos de fabricación o un sistema financiero en AWS ya no será un problema menor

Por lo tanto, elegir el método de autenticación correcto no se trata solo de «hacer que la conexión funcione». Puede determinar la seguridad y la coherencia de todo el sistema que lo sustenta.

¿Por qué la autenticación es lo primero que hay que tener en cuenta?

Estas herramientas externas están lejos de ser «inofensivas». Pueden contener código fuente, registros de clientes, datos de producción y tickets internos. Pero cuando Claude se conecta a través de MCP, no solo lee por diversión. Actúa como una identidad verificada en lo más profundo de su sistema. Si la autenticación es débil, podrías ser atacado. No es necesario ningún ataque complejo. Una clave de API filtrada es todo lo que se necesita para que las cosas salgan mal muy rápido.

La situación que encontré fue similar. El servicio solo proporciona un único token para los entornos de desarrollo y producción. Todo estaría bien si la información de ese token no se filtrara durante las pruebas de un repositorio. Por lo tanto, necesitamos cambiar las credenciales de inicio de sesión tanto en el entorno de producción como en el de desarrollo para evitar que surjan problemas tan pronto como se descubran. Por lo tanto, el problema no es el sistema en sí mismo; la cuestión crucial radica en la forma en que se administran los permisos. La autorización no es solo un complemento; determina lo que Claude puede hacer dentro del ámbito permitido, lo que evita los riesgos de seguridad.

¿A qué se refiere este artículo?

Claude Code admite varios métodos de autenticación diferentes. Por ejemplo:

• Clave de API
• Símbolo de portador
• OAuth
• Credencial de AWS (clave de acceso o asunción de rol)

Es confuso a primera vista. Cada método existe por su propia razón. No existe una «forma correcta para todos los casos».

Elegir el método incorrecto puede llevar a:

• Exposición de credenciales
• Necesidad de volver a configurar a mitad de camino
• Equipo que pierde tiempo arreglando flujos de trabajo

Una vez configuré un servidor MCP que se ejecutaba detrás de una API Gateway en AWS.

Al principio, usé claves de acceso a largo plazo para acelerar el acceso. Sin embargo, me di cuenta de que esto no era lo ideal en comparación con compartir las claves con varios evaluadores para facilitar el acceso. Al final, cambié a suposiciones basadas en roles para definir los permisos con mayor claridad.

Este artículo profundizará en cada punto y explicará cuándo usar cada método diferente. El objetivo es ayudarte a tomar la decisión correcta desde el principio, evitando futuras modificaciones.

Instalación de Claude Code

Si aún no has instalado Claude Code, puedes configurarlo rápidamente.

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Solo macOS

brew install --cask claude-code

Ahora pase a las siguientes secciones sobre la seguridad de la autenticación

Definición de la seguridad en un entorno de CLI

Al ejecutar una CLI en una máquina local, muchas personas solo piensan en HTTPS. En realidad, el mayor problema radica en la forma en que mantienes tus credenciales.

HTTPS solo protege los datos durante la transmisión. No ayuda si el token está expuesto en tu máquina. En un entorno de CLI, los principales problemas son:

• ¿Dónde guardas la llave?
• ¿Cuánto dura el token?
• ¿Quién puede usarlo?

Baja seguridad es cuando dejas una clave de API a largo plazo en un archivo de configuración de texto sin formato. Si ese archivo se guarda accidentalmente en el repositorio, se ha acabado. Esa clave está esencialmente fuera de control. Y como es una llave de larga duración, tienes que girarla manualmente.

Una vez me encontré con una situación similar al depurar un problema de entorno con ECS. Estaba usando el servidor MCP de Amazon ECS con una clave de acceso y una clave secreta. Después de eso, me olvidé de esas credenciales. Unos días más tarde, le pedí a Claude que investigara algunos problemas en otro entorno, pero este seguía usando las credenciales antiguas, por lo que terminó realizando muchas acciones en el entorno de producción.

Alta seguridad es diferente. Usas fichas a corto plazo. O haciendo referencia a través de variables de entorno. O usar mecanismos de autenticación a nivel de servicio, como los roles de IAM. Por ejemplo, cuando se utiliza el SSO de AWS, los tokens tienen una fecha de caducidad clara. Tras la caducidad, debe volver a iniciar sesión. Si la máquina se ve comprometida, el atacante solo tiene un período muy corto para hacer algo. Este método no es perfecto. Pero minimiza el daño si algo sale mal.

A continuación se muestran cuatro métodos de configuración de autenticación comunes para los servidores MCP en Claude Code. Cada método es adecuado para un contexto diferente.

1. Encabezados HTTP estáticos (claves de API y tokens portadores)

Este es el método más sencillo para empezar. De este modo, funcionará bien con muchos servicios de terceros que utilizan claves de API a largo plazo o tokens de acceso privado (PAT).

Configuración de línea de comandos

Si desea agregar rápidamente un servidor MCP con un encabezado de autenticación, simplemente use»claude mcp añadir» y pase «--encabezado»

# Add a weather service MCP server with Bearer Token authentication
claude mcp add weather-service \
    --transport http \
    --header "Authorization: Bearer secret-token-123" \
    https://api.weather-data.com/mcp

Cuando se complete el proceso, Claude escribirá automáticamente la configuración para usted. No se necesitan pasos manuales. »Claude/settings.json». Este método es muy conveniente para comprobar rápidamente un servicio externo.

La uso a menudo cuando necesito probar una API antes de integrarla oficialmente en el sistema. Solo recuerda una cosa: no pegues el token real en el comando y luego guardes el historial del shell en algún lugar. Eso ocurre con más frecuencia de lo que piensas.

Archivo de configuración (.claude/settings.json)

Si no quieres incluir el código del token en el archivo como texto sin formato, puedes usar una variable de entorno.

Claude leerá»$ {ENV_VAR}» y sustitúyalo por el valor real cuando se inicie la CLI.

Por ejemplo:

{
  "mcpServers": {
    "data-tool": {
      "url": "https://api.myservice.com/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

Este método es más seguro que escribir el token directamente en el archivo. Solo necesita exportar la variable de entorno antes de ejecutar Claude.

Una vez vi un repositorio interno enviar accidentalmente un token a la configuración. Al principio, pensé que era un repositorio privado, así que estuvo bien. Luego, el repositorio se compartió con otro equipo para probarlo. También se incluyó el token de producción. El uso de variables de entorno no resuelve todos los riesgos. Pero al menos reduce la posibilidad de quedar expuestos a factores clave cuando se comete un error.

Ventajas:

• Fácil de configurar.
• Adecuado para una rápida integración con servicios externos.

Desventajas:

• El token sigue siendo un tipo a largo plazo.
• Si está expuesto, debe girarlo manualmente.

2.1 Credenciales de AWS MCP

2.1 Clave de acceso y clave secreta (para servidores MCP alojados en AWS)

Si su servidor MCP está ubicado en AWS, esto es mucho más práctico. Puede usar las credenciales de inicio de sesión de AWS existentes en su máquina. Por lo general, esto se configura mediante AWS configure o AWS SSO. Claude heredará variables como:

• AWS_ACCESS_KEY_ID
• CLAVE DE ACCESO SECRETO DE AWS
• AWS_SESSION_TOKEN
• AWS_PROFILE

Esto está muy disponible cuando el servidor MCP se ejecuta detrás de una puerta de enlace de API. O cuando el backend está en Lambda o ECS y la autenticación de IAM está habilitada.

Por ejemplo, configurar un proxy MCP para firmar solicitudes con Signature V4:

{
  "mcpServers": {
    "cloud-logger": {
      "command": "node",
      "args": ["/path/to/aws-mcp-proxy.js"],
      "env": {
        "AWS_PROFILE": "my-dev-profile",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://my-mcp-service.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

O, más simplemente, exporte las variables de entorno antes de ejecutar Claude:

# Establezca las credenciales de AWS antes de ejecutar Claude Code

export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-southeast-1

# Inicie Claude Code: el servidor MCP utilizará estas credenciales claude

Claude no necesita saber los detalles clave. Solo usa el contexto de AWS en el que ha iniciado sesión.

Recuerdo haber depurado un servidor MCP interno que se ejecutaba detrás de una API Gateway. Las solicitudes arrojaban 403 errores de forma constante. En ese momento, pensé que era una cuestión de política. Pero luego descubrí que el certificado SSO de AWS de mi máquina había caducado. Simplemente ejecutando el»inicio de sesión como sso» el comando volvió a arreglarlo todo. Desde entonces, siempre he observado que los servicios registrados necesitan comprobar la sesión antes de trabajar en ellos, en lugar de echarle la culpa a IAM.

Ventajas:

• Los tokens suelen ser a corto plazo a través de STS.
• Se puede girar automáticamente.
• Mayor seguridad que las claves de API a largo plazo.

Desventajas:

• Depende del estado de inicio de sesión de AWS.
• Todo se detiene inmediatamente una vez que finaliza la sesión.

2.2. Asunción de funciones de IAM (acceso con privilegios mínimos)

Cuando utiliza las credenciales de AWS directamente, Claude actúa con su identidad personal. Es práctico, pero no siempre es el modo correcto. Asumir un rol permite al MCP usar una identidad independiente. Esta identidad solo sirve a una máquina o servicio específico. Esto es muy útil cuando se quiere simular la producción.

Por ejemplo, probar el funcionamiento de un servicio con acceso de solo lectura. O cuando el servidor MCP solo acepta una función de IAM fija. No permite que los usuarios individuales lo llamen directamente.

Me encontré con un caso como este. Una API interna solo permitía que los roles de backend accedieran a ella. Se bloquearon usuarios individuales. Para realizar las pruebas de forma local, tenías que asumir esa función específica.

El flujo de trabajo es bastante claro:

1. Solicitas asumir un rol de IAM.
2. AWS STS comprueba si tiene permiso para usar STS:AssumeRole. Si es válido, STS devuelve una credencial temporal.
3. El Proxy MCP usará esa credencial temporal para llamar al servicio objetivo. El servicio solo ve el rol, no su usuario individual.

Lo que me gusta de este método son los permisos muy claros. Los roles tienen sus propias políticas. Si quieres imponer alguna restricción, puedes ajustarla en esa política. La desventaja es que la configuración inicial lleva un poco de tiempo. Si la política de confianza es errónea al menos en una línea, la suposición no funcionará. Además, depurar IAM nunca es una tarea divertida.

Ejemplo de configuración

{
  "mcpServers": {
    "finance-bot": {
      "command": "node",
      "args": ["/path/to/aws-role-mcp-proxy.js"],
      "env": {
        "ASSUME_ROLE_ARN": "arn:aws:iam::123456789012:role/mcp-finance-bot-role",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://secure-finance.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

Configurar los permisos de IAM para asumir funciones

Para asumir un rol, el usuario actual debe tener ese permiso. Sin la política de confianza correcta, todo se detendrá de inmediato.

Por lo general, definiré algunas variables para simplificar:

# Definir variables

export ACCOUNT_ID="123456789012"
export ROLE_NAME="mcp-finance-bot-role"
export MY_USER_ARN="arn:aws:iam::${ACCOUNT_ID}:user/developer@company.com"

# Actualice la política de confianza del rol para permitir que su usuario lo asuma

aws iam update-assume-role-policy \
    --role-name "${ROLE_NAME}" \
    --policy-document '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "'"${MY_USER_ARN}"'"},
        "Action": "sts:AssumeRole"
      }]
    }

En esencia, esta sección solo hace una cosa. Le indica a AWS que su usuario puede asumir esa función.

Una vez perdí casi una tarde entera solo porque me faltaba el ARN correcto en la política de confianza. La política asociada al puesto era correcta. Sin embargo, la política de confianza no permitía al usuario asumir nada. Como resultado, STS seguía mostrando un error de acceso denegado. Otro punto a tener en cuenta:

IAM tiene un pequeño retraso. Tras actualizar la política, es posible que tengas que esperar uno o dos minutos para que entre en vigor. Si las pruebas de inmediato siguen fallando, no se asuste.

Ventajas:

• Mantiene el principio de permisos mínimos.
• Todo lo que un rol puede hacer está dentro de su política.

Desventajas:

• La configuración es un poco complicada.
• Solo un pequeño error y no funcionará.

3. Soporte OAuth 2.0 incorporado

Para servicios complejos de terceros como GitHub, Linear o Slack, una clave de API no es suficiente. Requieren iniciar sesión mediante un flujo de usuarios estándar. Claude Code proporciona soporte OAuth integrado para este tipo de servidores MCP.

Comandos de Shell

No necesitas escribir tu propio flujo de inicio de sesión. Antes de empezar, puedes comprobar qué servidores requieren autenticación:

# List the MCP servers that need authentication
claude mcp list

Si ves algún servidor que no esté conectado, simplemente ejecuta:

# Start the login flow for a GitLab MCP server (opens browser)
claude mcp auth gitlab-server

Comandos interactivos

Hay una función práctica. Si estás usando Claude y encuentras un error de permisos, no necesitas salir. Puedes autorizarlo directamente dentro de la sesión de chat.

Ejemplo:

>>> Tú: Lista mis tareas pendientes.

>>> Claude: Necesito acceder a Linear.

>>> /mcp auth servidor lineal

Simplemente escribe ese comando. Claude reactivará el flujo de inicio de sesión. Por lo general, abrirá el navegador para que confirmes los permisos.

Una vez me encontré con una situación en la que el token lineal caducó mientras estaba revisando un problema. Claude informó que los permisos eran insuficientes a mitad de camino.

En lugar de reiniciar la CLI, simplemente ejecuté»Autenticación /mcp» y se hizo. Volví a trabajar inmediatamente después.

Ventajas:

• Flujo de OAuth estándar.
• Los tokens se actualizan automáticamente.
• Una experiencia bastante fluida cuando se trabaja con un usuario.

Desventajas:

• De vez en cuando, todavía tienes que abrir el navegador e iniciar sesión de nuevo. Especialmente al cambiar de computadora o cuando finaliza la sesión de inicio de sesión.

Resumen

La elección del método de autenticación depende de dos cosas:

• Dónde guardas tus credenciales.
• Y qué problema estás resolviendo.

No existe la opción «lo mejor para todos los lugares». Solo la que se ajusta al contexto. Una nota pequeña pero importante: primero asegúrese de que su entorno de Node.js sea estable. Finalmente descubrió que la máquina local estaba usando una versión de Node incorrecta. Simplemente cambiándolo a»uso de nvm«debería funcionar normalmente. El uso de nvm ayuda a evitar muchos errores inexplicables debidos a desajustes en el entorno. No subestimes esto.

Guía rápida: Agregar servidores MCP en Claude Code

Transporte HTTP con encabezado de autenticación

# Transporte HTTP con encabezado de autenticación

claude mcp add my-server \
    --transport http \
    --header "Authorization: Bearer ${MY_TOKEN}" \
    https://my-mcp-server.com/mcp

# Transporte de estudio (proceso local)

claude mcp add my-local-server \
    -- node /path/to/server.js

# Listar los servidores MCP configurados

claude mcp list

# Eliminar un servidor MCP

claude mcp remove my-server

Solo recordar estos comandos es suficiente para empezar. El resto consiste en elegir el método de autenticación adecuado para cada situación.

Preguntas frecuentes

¿Cómo generar el token OAuth MCP de Claude Code?

Para generar un token OAuth MCP de Claude Code, normalmente te integras con un proveedor de OAuth que emite tokens de acceso a corto plazo. Este método altamente seguro ayuda a evitar la exposición directa de las credenciales a largo plazo de tus conexiones MCP de Claude Code. Los pasos específicos dependen de la configuración del proveedor de OAuth que hayas elegido y de su integración con Claude Code.

¿Puede Claude Code acceder a los servidores MCP?

Sí, Claude Code puede acceder a los servidores MCP, lo que permite la interacción con sistemas externos, como bases de datos y API. Esta funcionalidad convierte a Claude Code de un respondedor de texto en un participante activo del sistema. La autenticación mcp eficaz con código claude es vital para garantizar la seguridad de las operaciones, evitar el acceso no autorizado y garantizar la integridad de los datos en toda la infraestructura de EE. UU.

¿Cómo autenticar Figma MCP en Claude Code?

Para autenticar Figma MCP en Claude Code, tendrás que elegir un método de autenticación claude mcp seguro. Por lo general, esto implica el uso de claves de API, OAuth o tokens de portador, según la integración de Figma y tus políticas de seguridad. Concéntrese en conceder privilegios mínimos y evitar las claves a largo plazo para garantizar una interacción segura con el sistema.