Tema 6
La autenticación responde una pregunta básica pero crítica: quién está llamando a la API. Elegir mal el mecanismo de autenticación, o implementarlo sin considerar su contexto, puede convertir toda la capa de acceso en un punto débil. En APIs no existe una única opción correcta: cada enfoque resuelve necesidades distintas y trae riesgos propios.
Una API puede estar perfectamente diseñada desde el punto de vista funcional y aun así ser insegura si no sabe identificar correctamente al actor que la consume. La autenticación es el mecanismo que permite afirmar si una solicitud proviene de un usuario, una aplicación, un servicio interno o un tercero autorizado.
Sin autenticación, la API no puede distinguir entre tráfico legítimo y tráfico arbitrario. Pero autenticar no es suficiente por sí solo: también hay que hacerlo con el mecanismo adecuado, proteger las credenciales y asegurar que la identidad autenticada pueda mantenerse, revocarse y observarse correctamente.
En este tema veremos los enfoques más comunes: API Keys, Basic Auth, tokens y sesiones. Analizaremos qué resuelve cada uno, cuándo puede ser razonable usarlo y qué errores suelen convertirlo en una fuente de riesgo.
Antes de comparar mecanismos, conviene fijar una diferencia fundamental:
En APIs, ambas suelen viajar juntas, pero no son lo mismo. Un token válido puede autenticar correctamente a un usuario y aun así no darle permiso para acceder a un recurso concreto. Esta distinción es clave porque muchos diseños confunden identidad con privilegio.
Un esquema de autenticación no solo tiene que permitir acceso. También debe resolver varios objetivos operativos y de seguridad:
Por eso no conviene elegir un mecanismo solo por facilidad de implementación. La pregunta correcta es si ese mecanismo soporta el nivel de control que el caso requiere.
Las API Keys son identificadores secretos que un cliente incluye en cada solicitud para probar que tiene autorización inicial para consumir la API. Suelen usarse en integraciones servidor a servidor, servicios de terceros, scripts automáticos o APIs de bajo riesgo que necesitan control básico de acceso y trazabilidad.
Una API Key normalmente identifica a una aplicación o consumidor técnico, no a un usuario final. Por eso suele responder más a la pregunta “qué cliente llama” que a “qué persona está detrás”.
Sus ventajas principales son simplicidad, facilidad de emisión y bajo costo operativo. Pero esa misma simplicidad puede volverse un problema cuando se la usa para casos de identidad humana o permisos finos.
| Aspecto | Ventaja | Límite o riesgo |
|---|---|---|
| Simplicidad | Fáciles de emitir y consumir | Se usan en exceso en escenarios donde no alcanzan |
| Trazabilidad | Permiten distinguir clientes o integraciones | No identifican bien al usuario final |
| Operación | Buenas para automatización controlada | Difíciles de gobernar si proliferan sin inventario |
| Seguridad | Pueden restringirse por IP, scope o cuota | Si se filtran, suelen ser reutilizables de inmediato |
Las API Keys suelen fallar menos por el mecanismo en sí y más por cómo se gestionan. Los problemas frecuentes incluyen:
Cuando esto ocurre, la API Key se convierte en una credencial reutilizable difícil de controlar y fácil de filtrar.
Basic Auth consiste en enviar usuario y contraseña codificados en Base64, normalmente dentro de la cabecera `Authorization`. Es un esquema simple y ampliamente soportado, pero muy débil si se lo usa como solución general para APIs modernas.
Base64 no cifra nada. Solo transforma el formato. Por eso Basic Auth depende completamente de HTTPS para no exponer las credenciales en tránsito. Incluso con HTTPS, sigue teniendo limitaciones importantes porque obliga a transmitir credenciales primarias repetidamente.
Basic Auth puede ser razonable en contextos muy acotados: herramientas internas simples, entornos controlados, integraciones temporales o capas adicionales delante de servicios no críticos. Aun así, no suele ser la mejor elección a largo plazo.
No es recomendable cuando:
Un token es una credencial emitida después de un proceso de autenticación o aprovisionamiento. En lugar de enviar usuario y contraseña en cada solicitud, el cliente presenta un token que representa su identidad o sesión durante un tiempo determinado.
Este enfoque desacopla la autenticación primaria del consumo diario de la API. Eso permite introducir expiración, scopes, revocación, contextos de uso y separación entre autenticación inicial y acceso posterior.
Los tokens pueden ser opacos o autocontenidos, de corta o larga duración, orientados a usuario o a cliente técnico. Más adelante veremos JWT, OAuth 2.0 y OpenID Connect en profundidad; aquí nos interesa entender la lógica general.
Su principal fortaleza es que convierten la identidad en un artefacto controlable, en lugar de depender directamente de contraseñas o secretos de larga vida.
Los tokens también pueden ser peligrosos si se tratan como simples cadenas sin gobernanza. Algunos errores comunes:
Un token robado puede equivaler, en la práctica, a una sesión secuestrada. La diferencia con una contraseña es que al menos debería existir un marco mejor para acotarlo y revocarlo.
Las sesiones representan un estado mantenido por el servidor para recordar que un actor ya fue autenticado. Tradicionalmente se implementan mediante una cookie o identificador de sesión que referencia información guardada del lado servidor.
En APIs, el uso de sesiones sigue siendo válido en muchos escenarios, especialmente cuando la API sirve a una aplicación web clásica o cuando existe infraestructura madura de manejo de sesión. Sin embargo, introduce consideraciones distintas a los tokens stateless.
| Aspecto | Ventaja | Desafío |
|---|---|---|
| Control central | El servidor puede invalidar la sesión fácilmente | Requiere almacenamiento y coordinación de estado |
| Seguridad | Menos exposición de datos de identidad en el cliente | Riesgo de secuestro de sesión si la cookie se roba |
| Operación | Bien conocidas en aplicaciones web | Escalado más complejo en sistemas distribuidos |
| Revocación | Simple desde el backend | Menos cómodas para ciertos clientes móviles o integraciones externas |
Las sesiones tienen una superficie de riesgo propia. Los problemas frecuentes incluyen:
No existe un mecanismo universalmente superior. La elección depende de qué tipo de actor consume la API, qué criticidad tiene la operación y qué controles de ciclo de vida se necesitan.
| Mecanismo | Sirve bien para | Debilidad típica |
|---|---|---|
| API Key | Integraciones simples entre sistemas | Poca granularidad de identidad y fácil reutilización |
| Basic Auth | Casos internos muy acotados | Reenvío constante de credenciales primarias |
| Token | Aplicaciones modernas, delegación y control contextual | Mala gestión de expiración, scopes o almacenamiento |
| Sesión | Aplicaciones web con backend tradicional | Secuestro de sesión o complejidad operativa en distribuido |
La forma de transportar la credencial es tan importante como la credencial misma. En general, conviene usar cabeceras o cookies según el modelo elegido y evitar ubicaciones más expuestas.
Buenas prácticas generales:
Una autenticación madura no termina cuando se emite la credencial. También debe poder caducar, reemplazarse y anularse rápidamente cuando sea necesario.
Preguntas clave de diseño:
Si estas respuestas no existen, el mecanismo puede funcionar en condiciones normales pero fallar gravemente durante un incidente.
El sistema debería poder observar quién llamó, con qué credencial, desde qué contexto y con qué resultado, sin exponer el secreto en sí mismo. Esta trazabilidad es vital para auditoría, investigación y detección de abuso.
Una buena observabilidad de autenticación permite:
La autenticación en APIs REST no se reduce a “poner una credencial”. Requiere elegir un mecanismo adecuado para el tipo de consumidor, la criticidad del negocio y la capacidad de operar el ciclo de vida de esa identidad. API Keys, Basic Auth, tokens y sesiones pueden ser válidos en distintos contextos, pero ninguno es seguro por defecto si se implementa sin controles de protección, observabilidad y revocación.
En el próximo tema profundizaremos en autenticación moderna con JWT, OAuth 2.0 y OpenID Connect, que hoy forman la base de muchos esquemas de acceso en APIs y aplicaciones distribuidas.