Token opaco vs JWT

En Logto, como una plataforma CIAM integral basada en OIDC, los tokens de autorización juegan un papel crucial en la seguridad de las interacciones de usuario y la gestión del acceso a los recursos. Entre los diversos tipos de tokens utilizados para la autorización, los tokens opacos y los JWTs (JSON Web Tokens) son los más importantes.

Hemos recibido varias preguntas de nuestra comunidad, tales como: ¿Cuál es la diferencia entre un token opaco y un JWT? ¿Por qué no puedo decodificar el token de acceso que recibí, y por qué la longitud del token parece corta? Este artículo de blog tiene como objetivo aclarar estos conceptos y ayudar a entender las distinciones entre los tokens opacos y los JWTs, sus casos de uso, y por qué podrías encontrar diferentes comportamientos al trabajar con ellos.

¿Qué es un token opaco?#

Un token opaco es un tipo de token de acceso que, como su nombre indica, es opaco o no transparente para el cliente o cualquier parte externa. Esto significa que el propio token no lleva información legible sobre el usuario o la autorización concedida.

Cuando recibes un token opaco, a menudo aparece como una cadena aparentemente aleatoria de caracteres, e intentar decodificarlo no producirá datos significativos.

Aquí hay un ejemplo de un token opaco:

Dado que el contenido real del token solo es conocido por el servidor de autorización que lo emitió, para validar un token opaco, el cliente debe enviarlo de vuelta al servidor, que luego verifica su autenticidad y determina los permisos asociados. Este enfoque asegura que la información sensible permanezca oculta, proporcionando una capa adicional de seguridad, pero también requiere comunicación adicional con el servidor para validar el token.

Pros:

• seguro: Los tokens opacos no exponen ninguna información sensible al cliente. El contenido del token solo es conocido por el servidor de autorización.
• revocable: Dado que el token se almacena en el servidor, y la única forma de validarlo es a través del punto de acceso de introspección en el servidor de autorización, el servidor puede revocar fácilmente el token si es necesario y prevenir el acceso no autorizado.
• tamaño pequeño: Los tokens opacos suelen ser más cortos que los JWTs, lo cual puede ser beneficioso para el rendimiento y las consideraciones de almacenamiento.

Contras:

• con estado: Los tokens opacos requieren que el servidor de autorización mantenga un estado para validar el token, lo que puede introducir complejidad adicional y sobrecarga.
• rendimiento: La necesidad de comunicación adicional con el servidor para validar el token puede afectar el rendimiento, especialmente en escenarios de alto tráfico.

¿Qué es un JWT?#

En contraste con los tokens opacos, un JWT (JSON Web Token) es un token sin estado y auto-contenido que lleva información en un formato estructurado y legible.

Un JWT se compone de tres partes: un header, un payload, y una signature, cada uno codificado en Base64URL.

Aquí hay un ejemplo de un JWT:

• El header contiene información sobre el tipo de token y el algoritmo utilizado para firmar. Por ejemplo, { "alg": "HS256", "typ": "JWT"}.
• La sección payload contiene claims—piezas de información sobre el usuario o la autorización—como el ID del usuario, tiempo de expiración y alcances. Debido a que estos datos están codificados pero no cifrados, cualquiera que tenga el token puede decodificarlo para ver los claims, aunque no pueden alterarlo sin invalidar la firma. Basado en la especificación y configuración del servidor de autorización, varios claims pueden incluirse en el payload. Esto le da al token su naturaleza auto-contenida. Por ejemplo, { "sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• La signature se genera combinando el header, payload y una clave secreta usando el algoritmo especificado. Esta firma se usa para verificar la integridad del token y asegurar que no se ha alterado.

Los JWTs son comúnmente utilizados porque pueden ser verificados localmente por el cliente o cualquier servicio, sin necesidad de interactuar con el servidor de autorización. Esto hace que los JWTs sean particularmente eficientes para sistemas distribuidos, donde múltiples servicios pueden necesitar verificar la autenticidad del token independientemente.

Sin embargo, esta conveniencia también viene con la responsabilidad de asegurar que los claims del token no estén expuestos en exceso, ya que son visibles para cualquiera que tenga acceso al token. Además, los JWTs suelen ser de corta duración, y el tiempo de expiración se incluye en los claims del token para asegurar que el token no sea válido indefinidamente.

Pros:

• sin estado: Los JWTs son auto-contenidos y no requieren estado en el lado del servidor para ser validados.
• compatibilidad entre servicios: Los JWTs pueden compartirse y verificarse fácilmente entre diferentes servicios, haciéndolos ideales para sistemas distribuidos.
• extensible: El payload de un JWT puede contener claims personalizados, permitiendo una autorización flexible y un intercambio de información.
• estándar: Los tokens JWT siguen un estándar bien definido (RFC 7519), haciéndolos ampliamente soportados e interoperables.

Contras:

• exposición: Los claims en un JWT son visibles para cualquiera que tenga acceso al token, por lo que la información sensible no debe incluirse en el payload.
• tamaño grande: Los JWTs pueden ser más grandes que los tokens opacos debido a la información adicional que llevan, lo que puede impactar el rendimiento y las consideraciones de almacenamiento. Los claims en los tokens JWT deben mantenerse al mínimo para reducir el tamaño del token.
• complejidad de revocación: Dado que los JWTs son sin estado, suelen ser válidos por un período corto de tiempo, y no hay un mecanismo integrado para revocar tokens antes de que expiren, lo que significa que un token comprometido puede permanecer válido hasta que expire.

Validación de token de acceso opaco#

Un token de acceso opaco se valida enviándolo de vuelta al servidor de autorización para su verificación. El servidor de autorización mantiene el estado de los tokens emitidos y puede determinar la validez del token basándose en su almacenamiento interno.

1. El cliente solicita un token de acceso al servidor de autorización.
2. El servidor de autorización emite un token opaco.
3. El cliente envía la solicitud de acceso al recurso con el token opaco en el encabezado.
4. El proveedor de recursos envía una solicitud de introspección del token al servidor de autorización para validar el token.
5. El servidor de autorización responde con la información del token.

Validación de token de acceso JWT (offline)#

Un token de acceso JWT puede validarse offline por el cliente o cualquier servicio que tenga acceso a la clave pública del token.

0. El proveedor de recursos pre-obtiene la clave pública del servidor de autorización desde el punto de descubrimiento OIDC. La clave pública se usa para verificar la firma del token y asegurar su integridad.
1. El cliente solicita un token de acceso al servidor de autorización.
2. El servidor de autorización emite un token JWT.
3. El cliente envía la solicitud de acceso al recurso con el token JWT en el encabezado.
4. El proveedor de recursos decodifica y valida el token JWT usando la clave pública obtenida del servidor de autorización.
5. El proveedor de recursos concede acceso basándose en la validez del token.

Casos de uso en OIDC#

En el contexto de OIDC (OpenID Connect), los tokens opacos y los JWTs sirven diferentes propósitos y se utilizan en diferentes escenarios.

Tokens opacos#

1. Recuperación de perfil de usuario:

Por defecto, cuando un cliente solicita un token de acceso sin especificar un recurso y incluye el alcance openid, el servidor de autorización emite un token de acceso opaco. Este token se utiliza principalmente para recuperar información del perfil de usuario desde el punto final OIDC /oidc/userinfo. Al recibir una solicitud con el token de acceso opaco, el servidor de autorización verifica su almacenamiento interno para recuperar la información de autorización asociada y verifica la validez del token antes de responder con los detalles del perfil del usuario.

2. Intercambio de token de actualización:

Los tokens de actualización están diseñados para ser intercambiados únicamente entre el cliente y el servidor de autorización, sin necesidad de ser compartidos con proveedores de recursos. Como tal, los tokens de actualización suelen ser emitidos como tokens opacos. Cuando el token de acceso actual expira, el cliente puede usar el token de actualización opaco para obtener un nuevo token de acceso, asegurando acceso continuo sin re-autenticar al usuario.

JWTs#

1. Token ID:

En OIDC, el token ID es un JWT que contiene información del usuario y se utiliza para autenticar al usuario. Típicamente emitido junto con el token de acceso, el token ID permite al cliente verificar la identidad del usuario. Por ejemplo:

El cliente puede validar el token ID para asegurar la identidad del usuario y extraer información del usuario para personalización o propósitos de autorización. El token ID es para un solo uso y no debe ser usado para la autorización de recursos API.

2. Acceso a recursos API:

Cuando un cliente solicita un token de acceso con un indicador de recurso específico, el servidor de autorización emite un token de acceso JWT destinado a acceder a ese recurso. El JWT contiene claims que el proveedor de recursos puede usar para autorizar el acceso del cliente. Por ejemplo:

El proveedor de recursos puede validar la solicitud verificando los claims:

• iss: Confirma que el token fue emitido por un servidor de autorización de confianza.
• sub: Identifica al usuario asociado con el token.
• aud: Asegura que el token está destinado para el recurso específico.
• scope: Verifica los permisos concedidos al usuario.

Conclusión#

En resumen, los tokens opacos y los JWTs sirven diferentes propósitos en sistemas basados en OIDC, con los tokens opacos proporcionando un enfoque seguro y con estado para la autorización y los JWTs ofreciendo una alternativa auto-contenida y sin estado. Entender las distinciones entre estos tipos de tokens y sus casos de uso es esencial para diseñar mecanismos de autenticación y autorización seguros y eficientes en tus aplicaciones.

Descubre más características de tokens de acceso en Logto:

• Usar RBAC para proteger tu API
• Token de acceso de organización
• Claims personalizados en JWT