Autenticación básica versus tokens de portador ¿Qué método de autenticación de API utilizar?

Cada solicitud de API debe demostrar quién la está realizando. El método que elijas influye en tu postura de seguridad, en la experiencia del desarrollador y en el costo operativo durante años. La autenticación básica, las claves de API, los tokens de portador y el OAuth resuelven problemas diferentes — y usar el malo crea deuda que es difícil de resolver más adelante. A continuación, una explicación clara de cada uno, con código copiable y una tabla de decisión para que puedas elegir el método adecuado para tu caso de uso.

Autenticación HTTP básica

La autenticación básica envía credenciales con cada solicitud. El cliente combina el nombre de usuario y la contraseña como username:password, codifica la cadena en Base64 y la coloca en el Authorization encabezado:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

Esa cadena en Base64 es no criptografiados. Cualquiera que intercepte la solicitud puede decodificarla en segundos. La autenticación básica solo es segura sobre HTTPS, y aunque así sea, las credenciales viajan en cada solicitud y terminan en los registros del servidor a menos que las elimines activamente.

Para generar el valor correcto del encabezado sin codificar manualmente las credenciales, utiliza el Generador de autenticación básica IO Tools.

# curl with Basic Auth
curl -u username:password https://api.example.com/data

# Or with the explicit header
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

// fetch with Basic Auth
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
  headers: { Authorization: `Basic ${credentials}` }
});

Cuándo es aceptable: Herramientas internas, entornos de desarrollo y integraciones entre servidores simples donde controlas ambos extremos. Nunca para APIs públicas o autenticación para usuarios finales.

Claves de API

Una clave de API es un token estático — una cadena larga y aleatoria vinculada a una aplicación específica o a un llamador. El cliente la envía en un encabezado, típicamente X-API-Key o mediante el Authorization encabezado con un esquema personalizado:

# curl with API key
curl -H "X-API-Key: sk_live_abc123xyz" https://api.example.com/data

# Or with Authorization header
curl -H "Authorization: ApiKey sk_live_abc123xyz" https://api.example.com/data

// fetch with API key
fetch('https://api.example.com/data', {
  headers: { 'X-API-Key': 'sk_live_abc123xyz' }
});

Las claves de API son fáciles de implementar y se pueden revocar inmediatamente si se comprometen. El inconveniente: son inestáticas y no tienen caducidad incorporada. Una clave filtrada permanece válida hasta que la revocas manualmente. No hay firma para verificarla y no hay alcance incorporado — solo una cadena que buscas en una base de datos.

Cuándo usarlas: Integraciones de terceros, productos de API para desarrolladores y acceso público a APIs donde deseas limitar el tráfico por cliente y poder revocar inmediatamente sin el sobrecoste de OAuth.

Tokens de portador (JWT)

Los tokens de portador — más comúnmente JWTs (tokens web de JSON) — son emitidos por un servidor de autenticación y enviados en el Authorization encabezado con el Bearer esquema:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Un JWT contiene un payload firmado que incluye reclamaciones: quién es el usuario, qué permisos tiene y cuándo caduca el token. El servidor valida el token verificando la firma contra un secreto compartido o una clave pública — sin necesidad de buscar en una base de datos. Esa validación inestática es la principal ventaja en sistemas distribuidos y arquitecturas de microservicios.

Las desventajas son reales: los JWTs son grandes (varios cientos de bytes por solicitud), y no pueden invalidarse antes de su caducidad sin infraestructura adicional como una lista de tokens bloqueados. Errores en la implementación — claves de firma débiles, comprobaciones de caducidad ausentes, ataques por confusión de algoritmos — han causado brechas graves en sistemas en producción.

# curl with Bearer token
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  https://api.example.com/data

// fetch with Bearer token
fetch('https://api.example.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

Cuándo usarlas: APIs dirigidas a usuarios, microservicios que deben pasar la identidad hacia abajo, y cualquier escenario donde credenciales de corta duración con reclamaciones incorporadas reduzcan la necesidad de estado en el servidor.

OAuth 2.0: Tokens de acceso y tokens de renovación

OAuth 2.0 no es un formato de token — es un protocolo de delegación. Cuando tu aplicación necesita actuar en nombre de un usuario y acceder a recursos en otro servicio, OAuth 2.0 gestiona el consentimiento y el intercambio de tokens.

El flujo en resumen: el usuario aprueba el acceso, el servidor de autorización emite un token de acceso de corta duración de acceso y un token de renovación de larga duración de renovación, tu aplicación utiliza el token de acceso para llamadas a API, y cuando el token de acceso caduca, el token de renovación intercambia por uno nuevo sin pedir nuevamente al usuario.

# Step 1: Exchange credentials for a token (client credentials flow)
curl -X POST https://auth.example.com/token \
  -d "grant_type=client_credentials" \
  -d "client_id=myapp" \
  -d "client_secret=mysecret"

# Step 2: Use the access token
curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.example.com/data

# Step 3: Refresh when expired
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=REFRESH_TOKEN" \
  -d "client_id=myapp"

Los tokens de acceso son típicamente JWTs. Los tokens de renovación son cadenas opacas almacenadas en el servidor — nunca exponerlos a código en el navegador.

Cuándo necesitas usarlos: Inicios de sesión sociales, acceso a datos de terceros, cualquier integración “Inicia sesión con X” o cualquier escenario donde un usuario humano debe consentir lo que tu aplicación está permitido hacer en su nombre.

Reglas de seguridad que se aplican a todos los métodos

Cualquiera que sea el método de autenticación que elijas, estas reglas se aplican sin excepción.

• HTTPS en todos los lugares. Las credenciales o tokens enviados por HTTP plano se comprometen en el momento en que cualquiera pueda inspeccionar un paquete. No hay excepciones.
• Nunca almacenes secretos en el código. Usa variables de entorno o un gestor de secretos. Ninguna credencial en archivos controlados por versión — incluyendo archivos excluidos por .gitignore, ya que esas exclusiones no son confiables en la práctica.
• Rotar según un calendario y en caso de sospecha. Las claves de API deben rotarse sin interrupción. Los secretos de firma de JWT deben soportar versionado para que puedas rotarlos sin invalidar simultáneamente todas las sesiones activas.
• La duración más corta que funcione. Tokens de acceso: minutos a unas pocas horas. Claves de API: rotar en cualquier cambio de personal. Credenciales de autenticación básica: tratar como privilegiadas y rotar proactivamente.
• Auditar quién tiene qué. Mantén un registro de credenciales emitidas. Cuando algo salga mal, necesitarás saber exactamente qué fue emitido, a quién y cuándo.

Guía de decisión: qué método para qué caso de uso

Método	Inestático	Revocable	Complejidad	APIs, microservicios, autenticación entre dominios
Autenticación Básica	Sí	Solo mediante cambio de credenciales	Muy baja	Herramientas internas, entornos de desarrollo
Clave de API	Sí	Sí, inmediatamente	Bajo	Integraciones de terceros, APIs para desarrolladores
Token de portador (JWT)	Sí	Solo con lista de bloqueo de tokens	Medio	APIs dirigidas a usuarios, microservicios
OAuth 2.0	Varía	Sí	Alto	Delegación de usuario, autenticación de terceros

API interna, integraciones entre servidores, sin usuarios: Claves de API. Fáciles de implementar, revocables inmediatamente, fáciles de auditar. Si ya estás ejecutando microservicios con JWTs, usa un token de cuenta de servicio de corta duración en su lugar.

API pública con consumidores de desarrolladores externos: Claves de API con límites de tráfico por clave y un portal de gestión autónomo. Añade escopos de OAuth si tus consumidores necesitan solicitar acceso a recursos específicos en nombre de sus propios usuarios.

Autenticación para usuarios en tu propio producto: Tokens de portador (JWTs) con breve duración y rotación de tokens de renovación. Emite tokens tras la verificación de credenciales, manténlos de corta duración y evita almacenarlos en localStorage si existe el riesgo de XSS en tu aplicación.

Acceder a un servicio de terceros en nombre de uno de tus usuarios: Flujo de autorización de OAuth 2.0. No simplifiques este paso. El modelo de delegación de usuario existe porque es la forma más segura de manejar el consentimiento de terceros a escala.

La elección correcta normalmente depende de dos preguntas: ¿quién es el llamador y ¿necesita un usuario humano consentir lo que está haciendo el llamador? Si el llamador es una máquina y no hay delegación de usuario, las claves de API abordan la mayoría de los casos de forma limpia. Añade JWTs cuando necesitas reclamaciones incorporadas o identidad inestática entre servicios. Usa OAuth solo cuando el consentimiento del usuario forma parte del flujo.

También te puede interesar