Mapeo del vocabulario de autenticación: claves API, sesiones, JWT, OAuth2, OIDC, SSO

Un desarrollador agrega “Iniciar sesión con Google” a un proyecto, recibe un token de acceso y considera que la tarea está completada. Luego, un colega hace una pregunta sencilla: ¿cómo sabe la aplicación realmente de qué usuario se trata? Con frecuencia, la respuesta honesta es que no lo sabe, porque lo que se ha implementado es una autorización delegada, no un proceso de inicio de sesión. Términos como JWT, sesión, OAuth2, OIDC y SSO suelen explicarse uno por uno, y ese es precisamente el motivo por el cual se confunden entre sí. Este artículo sitúa cada uno de ellos en un mismo mapa para que pueda determinar qué problema resuelve realmente cada componente de su stack y elegir la herramienta adecuada para el siguiente.

Dos preguntas detrás de cada mecanismo de autenticación

Casi todo en este ámbito responde a una de dos preguntas.

• Autenticación pregunta ¿quién eres? Es el proceso de verificar una identidad, ya sea que esa identidad pertenezca a una persona, un servicio backend o un dispositivo.
• Autorización pregunta ¿qué puedes hacer? Se produce después de que se haya establecido la identidad y determina qué recursos y acciones están disponibles.

HTTP ya codifica esta distinción en sus códigos de estado. Una respuesta 401 Unauthorized significa que el solicitante no ha demostrado quién es (a pesar del nombre engañoso, se trata de autenticación). Una respuesta 403 Forbidden significa que el servidor sabe exactamente quién está solicitando y aún así rechaza la petición. Si tu API devuelve 403 por falta de token o 401 por un usuario que no tiene rol, los clientes no pueden decidir si solicitar inicio de sesión o mostrar un mensaje de “sin acceso”.

Una analogía física ayuda. En la entrada de una oficina, un guardia verifica tu tarjeta de identificación de empleado; eso es autenticación. Una vez adentro, tu placa abre algunas puertas y no otras; eso es autorización. Un paso establece la identidad, el otro aplica los permisos, y un sistema puede aprobar el primero mientras falla en el segundo. Para conocer mejor dónde debe ubicarse cada verificación dentro del código de la aplicación, consulta autenticación vs autorización y dónde pertenece cada una.

Ten en cuenta estas dos preguntas durante el resto de la explicación. Cada mecanismo que se describe a continuación es más fácil de entender una vez sabes a cuál de las preguntas responde.

Claves API: identificar a un cliente, no a una persona

Las claves API son la forma más sencilla de autenticación del cliente. El proveedor le emite una cadena única que usted envía con cada solicitud, y el servidor la compara con las claves que tiene registradas. Muchas API la aceptan como credencial de portador en el encabezado estándar:

Authorization: Bearer your-api-key-here

Otros proveedores utilizan un encabezado personalizado como X-API-Key; la idea es la misma. Lo que no hace la clave es describir a nadie en particular. Se trata de un valor opaco, por lo que el servidor debe buscarla para saber qué cuenta está realizando la solicitud. No tiene una fecha de vencimiento integrada a menos que usted la establezca, y quienquiera que posea una clave filtrada tendrá el mismo acceso que su legítimo propietario. Por eso, la rotación, delimitación de permisos y almacenamiento seguro de las claves son su responsabilidad.

También existe la autenticación básica HTTP, que envía un nombre de usuario y una contraseña codificados en base64 en un encabezado. Base64 es un método de codificación, no de cifrado, por lo que la autenticación básica solo es segura mediante TLS, y resulta difícil justificar su uso fuera de herramientas internas muy simples. Las claves API son la opción más común y ligera, y resultan adecuadas cuando se controlan ambos extremos de la conexión o cuando un servicio realiza cobros y limita el uso por cuenta.

Lugares típicos donde se encuentran las claves API:

• APIs de modelos de IA
• Puertas de enlace de pago
• APIs de clima y otros datos
• Llamadas de backend a backend entre tus propios servicios

Fíjate en lo que falta de esa lista: los usuarios finales que inician sesión en tu aplicación. Una clave API identifica la aplicación o cuenta que realiza la llamada, no a la persona que está frente a la pantalla.

Sesiones: estado del servidor detrás de una cookie

Hace mucho tiempo, antes de que los JWT se popularizaran, las sesiones eran la forma habitual para mantener a los usuarios conectados, y siguen siendo una opción sólida para las aplicaciones generadas en el servidor.

El proceso es sencillo: el usuario envía sus credenciales, el servidor las verifica y crea un registro de sesión en algún almacenamiento (memoria, Redis o una base de datos), y la respuesta establece una cookie que contiene únicamente el ID de la sesión. En cada solicitud posterior, el navegador envía nuevamente la cookie, y el servidor busca ese ID para encontrar la sesión y al usuario asociado a ella.

Este diseño es con estado, pero eso también es su ventaja. El servidor almacena la información real, por lo que cerrar la sesión de un usuario o revocar una sesión comprometida es tan sencillo como eliminar un registro. La propia cookie no contiene nada sensible más allá de un identificador aleatorio.

El costo aparece cuando se escala horizontalmente. Si varios servidores manejan el tráfico, todos deben acceder al mismo almacenamiento de sesiones; de lo contrario, un usuario conectado en una instancia se verá anónimo en la siguiente. Una instancia compartida de Redis resuelve bien este problema en la práctica, pero representa un componente adicional que hay que desplegar, monitorear y configurar correctamente. Un almacenamiento de sesiones mal configurado es el tipo de problema que surge en el peor momento posible durante un lanzamiento.

Las sesiones siguen siendo una opción excelente para:

• Aplicaciones web tradicionales generadas por servidor
• Panels de administración
• Aplicaciones donde la revocación instantánea es más importante que la falta de estado

JWT: autónomo, firmado y legible

Un token web JSON es un objeto JSON firmado que contiene información como el ID del usuario, sus roles y una fecha de vencimiento. Está formado por tres segmentos codificados en base64url unidos por puntos:

Header.Payload.Signature

El encabezado indica el algoritmo de firma, la carga útil contiene las afirmaciones, y la firma permite al servidor confirmar que ninguna de estas partes fue modificada por nadie sin la clave de firma. Dado que las afirmaciones se encuentran dentro del token, un servidor puede autenticar una solicitud verificando la firma y leyendo la carga útil, sin necesidad de consultar una base de datos. Es por esta característica que los JWT son adecuados para sistemas distribuidos sin estado.

Estar firmado no significa ser secreto

El malentendido más común es que un JWT oculta su contenido. No lo hace. Un JWT estándar está firmado, no encriptado, y cualquiera que lo posea puede decodificar la carga útil con una sola llamada base64. Nunca incluya contraseñas, datos personales que no se mostrarían al usuario ni secretos internos en las afirmaciones bajo la suposición de que son privados. Cuando ocurre un incidente relacionado con JWT, esta suposición errónea suele estar en su origen. (Existen tokens encriptados según la especificación JWE, pero son un formato distinto y rara vez es a lo que se refiere un tutorial con “JWT”.)

Tokens de acceso y de actualización

Dado que un JWT permanece válido hasta su vencimiento, el patrón habitual combina dos tokens:

• Token de acceso: de corta duración, generalmente de 15 minutos a una hora, y se envía con cada solicitud a la API.

TOKEN DE REFRESCO: de larga duración, desde días hasta semanas, y se utiliza únicamente para obtener un nuevo token de acceso sin pedir al usuario que inicie sesión nuevamente.

Almacene el token de refresco en una cookie HttpOnly en lugar de en localStorage, donde cualquier script inyectado podría leerlo. La corta vida útil del token de acceso limita los daños causados por una fuga, mientras que el token de refresco es donde puede residir la lógica de revocación.

Los JWT funcionan bien para APIs, clientes móviles, aplicaciones de página única y servicios distribuidos. No han hecho obsoletas las sesiones; intercambian una revocación sencilla por la falta de estado, y la elección adecuada depende de su arquitectura. La comparación entre sesiones y JWT como modelos de autenticación en Node.js analiza en detalle ese equilibrio.

OAuth 2.0: acceso delegado, no inicio de sesión

OAuth 2.0 es el concepto que con más frecuencia se coloca en el cajón equivocado. Se trata de un marco de autorización, no de un protocolo de autenticación. Su función es permitir que una aplicación acceda a recursos gestionados por otro servicio en nombre del usuario, sin que este tenga que entregar nunca su contraseña.

En el flujo de código de autorización habitual, tu aplicación redirige al usuario a la pantalla de consentimiento del proveedor, donde se pregunta algo como “¿Permitir que esta aplicación vea sus archivos de Google Drive?”. Si el usuario está de acuerdo, el proveedor redirige al usuario con un código de autorización de corta duración. Tu backend intercambia ese código por un token de acceso y luego utiliza este para llamar a la API del proveedor.

Ese token de acceso representa el permiso para acceder a ciertos recursos. No es una indicación sobre quién es el usuario, y la especificación OAuth2 no define su formato ni exige que su aplicación pueda leerlo. Considerar la llegada de un token de acceso como prueba de que el usuario está conectado es el error clásico del escenario inicial, y ha causado verdaderas vulnerabilidades, por ejemplo cuando un token emitido para una aplicación es aceptado como prueba de identidad por otra.

OAuth2 está diseñado para responder preguntas como:

• ¿Puede esta aplicación leer los archivos de Drive del usuario?
• ¿Puede esta aplicación acceder a los repositorios del usuario?

No está diseñado para responder: ¿quién es este usuario?

OpenID Connect: la capa de identidad sobre OAuth2

Si OAuth2 le indica qué puede acceder una aplicación, OpenID Connect agrega la información que falta sobre quién es esa persona. OIDC es una capa de identidad ligera construida sobre OAuth2, reutilizando sus mecanismos de redirección e intercambio de tokens. Cuando hace clic en “Iniciar sesión con Google”, el flujo que se ejecuta en segundo plano es OIDC, no simplemente OAuth2.

Después de que el usuario se autentica, un proveedor OIDC devuelve dos tokens con propósitos diferentes:

• token de ID, que es un JWT que describe al usuario: un identificador único y estable, y generalmente contiene datos como el nombre y la dirección de correo electrónico.
• token de acceso, que permite a su aplicación llamar a las API en nombre del usuario.

El token de ID es lo que autentica al usuario en su aplicación. El token de acceso es lo que autoriza las siguientes acciones de la aplicación. Su backend debe validar la firma, el emisor, el público y la fecha de vencimiento del token de ID antes de confiar en sus afirmaciones, y debe asociar las cuentas de usuario al identificador de sujeto estable en lugar de a una dirección de correo electrónico que puede cambiar. Visto de esta manera, OAuth2 por sí solo no puede proporcionar el inicio de sesión; OIDC lo completa.

SSO: una experiencia, entregada por protocolos

El inicio de sesión único a menudo se confunde con los protocolos que lo implementan. SSO es un patrón de experiencia de usuario: autenticarse una vez y luego moverse entre varios sistemas sin tener que iniciar sesión nuevamente. Google es el ejemplo más conocido; se inicia sesión una vez, y Gmail, Drive, Calendar y YouTube lo reconocen a uno.

Dos protocolos realizan la mayor parte del trabajo detrás de SSO:

• SAML: Basado en XML y maduro, predomina en entornos empresariales como portales corporativos, paneles de control de CRM y herramientas internas.
• OpenID Connect: Basado en JSON y JWT, más reciente, y la opción habitual para aplicaciones web y móviles.

SAML es notoriamente complicado de implementar y depurar, por lo que para un sistema nuevo OIDC suele ser el camino más sencillo. SAML sigue siendo una opción válida cuando es necesario integrarse con proveedores de identidad empresariales que no ofrecen OIDC, y muchos de ellos siguen en uso.

Cuando alguien le pide que “añada SSO”, lo primero que debe averiguar es qué protocolo utiliza su proveedor de identidad. Esa respuesta determina las bibliotecas, la configuración y los trabajos de pruebas que seguirán.

Elegir un mecanismo

Al sintetizar toda esta información, una guía aproximada para tomar la decisión sería la siguiente:

• Su servicio es llamado por otros programas, no por personas: claves API, con alcance definido y rotación periódica, o credenciales de cliente OAuth2 si necesita tokens que caduquen.
• Una aplicación generada en el servidor o un panel de administración con su propio sistema de inicio de sesión: sesiones mediante una cookie segura y HttpOnly.
• API sin estado, clientes móviles o varios servicios que verifican al mismo usuario: tokens de acceso JWT con tokens de actualización.
• Su aplicación necesita acceder a los datos de un usuario en otro servicio: OAuth 2.0.
• Desea que los usuarios inician sesión con una cuenta existente como Google: OpenID Connect.
• Los empleados necesitan un único inicio de sesión en varias herramientas internas o SaaS: SSO a través de OIDC, o SAML cuando el proveedor de identidad lo exija.

Estas opciones se combinan. Un producto típico podría utilizar OIDC para el inicio de sesión, luego emitir su propia sesión o JWT, al tiempo que mantiene tokens de acceso OAuth2 para integraciones con terceros.

Preguntas frecuentes

¿En qué difieren la autenticación y la autorización en la práctica? La autenticación verifica la identidad y falla con HTTP 401; la autorización comprueba los permisos y falla con 403. Son pasos separados con códigos de error distintos, y combinarlos genera verdaderas brechas de seguridad.

¿Debería usar JWT o sesiones? Las sesiones son ideales para aplicaciones generadas en el servidor que pueden compartir un almacén de sesiones. Los JWT resultan más adecuados para APIs sin estado, clientes móviles y sistemas distribuidos. Tome la decisión según su arquitectura y necesidades de revocación, no porque una opción suene más moderna.

¿OAuth2 sirve para autenticación o autorización? Autorización. Permite a las aplicaciones acceder a recursos en nombre de un usuario sin confirmar quién es ese usuario. Para la identidad, utilice OpenID Connect, que extiende OAuth2 precisamente con ese fin.

Puntos clave

• Clasifique cada mecanismo bajo una misma pregunta: ¿quién está haciendo la solicitud? o ¿qué pueden hacer?
• Las claves API identifican a las aplicaciones cliente; no contienen información sobre la identidad del usuario y requieren su propio sistema de vencimiento y rotación.
• Las sesiones almacenan el estado en el servidor, lo que facilita la revocación pero exige un almacenamiento compartido a gran escala.
• Los JWTs están firmados, no encriptados; mantenga los secretos fuera del payload y los tokens de actualización fuera de localStorage.
• OAuth2 otorga acceso delegado; OIDC añade el token de identidad que realmente inicia sesión al usuario.

SSO es una experiencia que se implementa con OIDC o SAML, dependiendo del proveedor de identidad.

La mayor confusión en esta área, incluido el error de “Iniciar sesión con Google” mencionado al principio, proviene de mezclar estas dos cuestiones. Mantenga separadas la identidad y los permisos; así, elegir entre estas herramientas se convierte en una cuestión de adaptar cada una a la pregunta para la cual fue diseñada.