JWT vs Autenticación basada en sesiones

Generalmente, el primer paso al usar una aplicación es la autenticación, donde el usuario final proporciona sus credenciales de identidad para iniciar sesión exitosamente. Después de este paso, el sistema de identidad (es decir, el proveedor de identidad, servidor de autenticación, etc.) sabe quién es el usuario y a qué recursos tiene acceso.

Dado que el HTTP es inherentemente sin estado, cada solicitud en una sesión es independiente y no recuerda información de las anteriores. Re-autenticar a los usuarios para cada acción resulta tedioso y perjudica la experiencia del usuario.

Aquí entran la autenticación basada en sesiones y la autenticación JWT (Token Web JSON), dos métodos populares para mantener el estado de autenticación. Cada uno tiene ventajas únicas y compensaciones, y la elección entre ellos depende de las necesidades específicas de tu aplicación. Si estás decidiendo entre los dos, esta guía está aquí para ayudarte.

¿Qué es la autenticación basada en sesiones?#

La autenticación basada en sesiones depende del servidor para mantener un registro del estado de autenticación del usuario. Al crear y gestionar sesiones, el servidor permite a los usuarios permanecer conectados e interactuar con una aplicación sin tener que volver a ingresar las credenciales con cada solicitud.

¿Cómo funciona la autenticación basada en sesiones?#

Creación de la sesión

1. Un usuario se autentica y proporciona algunas credenciales (por ejemplo, correo electrónico y contraseña).
2. Si las credenciales son válidas, el servidor crea un registro persistente que representa esa sesión. La sesión contiene información como una cadena aleatoria, identificador de usuario, hora de inicio de sesión, hora de expiración de la sesión, etc.
3. El SessionID se almacena en la base de datos y se devuelve al cliente del usuario como una cookie.

Validación de la sesión

1. El proceso puede ser activado manualmente por el usuario (por ejemplo, haciendo clic en una pestaña, actualizando una página) o automáticamente por el cliente (por ejemplo, durante cargas iniciales de páginas o a través de llamadas API con un SessionID).
2. Cada llamada subsecuente envía una solicitud HTTP desde el cliente que contiene la cookie de sesión al servidor.
3. El servidor valida el SessionID consultando los datos de la sesión almacenados en el servidor.
4. Si es válido, el servidor procesa la solicitud y autoriza al usuario.

¿Cómo revocar una sesión?#

Las sesiones pueden invalidarse en tiempo real, lo que es útil en situaciones donde se necesita revocar rápidamente el acceso.

• Cierre de sesión manual por parte del usuario: El servidor elimina el registro de la sesión, efectivamente cerrando la sesión del usuario.
• Forzar cierre de sesión por admin: Los administradores o sistemas pueden terminar sesiones específicas eliminándolas de la base de datos. Por ejemplo, durante una brecha de seguridad.
• Expiración de sesiones: Las sesiones pueden expirar automáticamente después de una duración establecida de inactividad, o un límite de tiempo fijo.

Ventajas de la autenticación basada en sesiones#

• Sencilla y confiable: El registro de sesión proporciona una fuente clara y centralizada, permitiendo un alto grado de confianza y haciendo más confiables las decisiones de autorización.
• Revocación en tiempo real: Al eliminar o invalidar el registro de sesión, el acceso del usuario puede ser revocado rápidamente.

Desventajas de la autenticación basada en sesiones#

• Latencia en sistemas distribuidos: Mantener datos de sesión a través de múltiples servidores siempre requiere sincronizar un almacén de sesiones. Esto introduce latencia adicional porque el servidor tiene que revisar el almacén de sesiones cada vez que se hace una solicitud.
• Alto consumo de recursos: Cada sesión consume recursos del servidor, afectando el rendimiento cuando la base de usuarios escala.
• Riesgo de seguridad: El secuestro de sesiones (mediante cookies de sesión robadas) puede permitir el acceso no autorizado a cuentas de usuario.
• Uso limitado para APIs: La autenticación basada en sesiones no es adecuada para aplicaciones móviles. Almacena datos de sesión en el servidor, lo que puede aumentar la carga y complejidad con muchos usuarios. Además, usa cookies, que son más difíciles de manejar en dispositivos móviles.

¿Qué es la autenticación JWT?#

JSON Web Tokens (JWTs) adoptan un enfoque diferente al incrustar toda la información relevante del usuario directamente en un token, usando un objeto JSON. A diferencia de los métodos basados en sesión, los JWTs son sin estado, lo que significa que el servidor no maneja registros de autenticación.

¿Cómo funciona la autenticación JWT?#

Un JWT consta de tres partes: un encabezado, un carga útil y una firma.

• El encabezado contiene el algoritmo de firma (por ejemplo, HS256) y el tipo de token (JWT).
• La carga útil contiene las principales declaraciones, como la identidad del usuario, el rol del usuario y el tiempo de expiración.
• La firma usa una clave para firmar el encabezado y la carga útil, permitiendo verificar si la firma ha sido alterada.

Emisión de JWT

1. El cliente envía credenciales de usuario al servidor de autenticación (Un proveedor de identidad universal es particularmente beneficioso para gestionar el acceso a través de múltiples dominios.)
2. Tras la autenticación exitosa, el servidor genera un JWT que incluye encabezado, carga útil y firma.
3. AuthServer envía el token emitido al Cliente. El cliente almacena el JWT (por ejemplo, en cookies, localStorage o sessionStorage).

Los flujos basados en sesión siguen un proceso similar. Sin embargo, después de la autenticación, la información del usuario se almacena en el servidor dentro de una sesión, mientras que los JWTs dependen de tokens enviados al cliente para almacenamiento y uso posterior.

Validación de token

1. Para solicitudes de API subsecuentes, el cliente envía el JWT en el encabezado Authorization (Bearer <token>).
2. El servidor verifica la firma del JWT usando una clave secreta o pública y revisa sus declaraciones (por ejemplo, expiración, emisor).
3. Si el token es válido, el servidor concede acceso al cliente a los recursos solicitados.

La autenticación basada en sesiones requiere que el servidor consulte un almacén de sesiones, lo que puede ser lento, especialmente si depende de bases de datos externas o centralizadas. En contraste, la autenticación JWT es sin estado, con toda la información necesaria almacenada en el token del cliente, y utilizando la firma para garantizar la seguridad. Esto elimina la necesidad de gestión de sesiones, haciéndolo más rápido y escalable, especialmente en sistemas distribuidos.

¿Cómo revocar un JWT?#

En el lado del cliente, cerrar sesión suele significar limpiar la sesión local y eliminar tokens (ID, acceso, token de actualización) del almacenamiento. Sin embargo, para la autenticación JWT, esto solo cierra la sesión del usuario a nivel local, dejando intacta la sesión centralizada en el servidor de autorización. Como resultado, los usuarios pueden seguir accediendo a otras aplicaciones bajo la misma sesión hasta que el token expire o se termine manualmente.

Revocar un JWT (Token Web JSON) es más desafiante que la autenticación basada en sesiones porque los JWTs son sin estado y no pueden ser invalidados una vez emitidos, a menos que se implementen estrategias específicas. Los métodos comunes incluyen:

• Tiempos de expiración cortos: Configura un reclamo exp corto (por ejemplo, 15 minutos) para el JWT. Una vez expirado, el usuario debe volver a autenticarse. Esto minimiza el riesgo si un token es comprometido, ya que el atacante solo podrá usarlo por un tiempo limitado. Para mantener una experiencia de usuario fluida, se puede utilizar un token de actualización para minimizar la molestia de volver a autenticarse.
• Lista negra de tokens: Para casos críticos (por ejemplo, cierre de sesión del usuario, cambios de contraseña), mantén una lista negra de tokens revocados. El servidor revisa los tokens entrantes contra esta lista de bloqueo y rechaza cualquier coincidencia. Aunque efectiva, este enfoque requiere rastrear los tokens revocados, lo que va en contra de la naturaleza sin estado de los JWTs y puede volverse ineficiente si la lista crece demasiado.
• Punto de acceso de revocación: Introduce un punto de acceso de revocación en el servidor de autorización donde se puedan invalidar los tokens (por ejemplo, tokens de actualización). Una vez revocado un token de actualización, cualquier token de acceso emitido con él ya no se renovará. Este método funciona bien en flujos de OAuth2.

Ventajas de la autenticación JWT#

• Rápida y más informativa: La naturaleza autónoma de los JWTs hace que la verificación del lado del cliente sea más rápida y eficiente, sin necesidad de interacción del servidor. También pueden incluir reclamos personalizados (por ejemplo, roles de usuario u otros datos relevantes) dentro del token, permitiendo a los servidores determinar roles sin consultar una base de datos.
• Mejorada seguridad: Los JWTs utilizan técnicas de firma y cifrado, haciendo los ataques más difíciles.
• Soporte de dominio cruzado: Los JWTs son perfectos para Inicio de Sesión Único (SSO) y autenticación de dominio cruzado. Permiten a los usuarios autenticarse en múltiples dominios o servicios con el mismo token.
• Amigable para móviles: Los JWTs funcionan genial para aplicaciones móviles que necesitan autenticación sin estado. Los tokens se pueden almacenar en el lado del cliente y enviarse con cada solicitud, mejorando la eficiencia y facilidad de uso.

Desventajas de la autenticación JWT#

• El JWT no se actualiza en tiempo real

  Una vez firmado un JWT, no puede ser revocado o actualizado, y será considerado válido mientras la firma sea válida y no haya expirado.

  Si cambian los permisos de acceso de un usuario (usualmente disminuye), el usuario seguirá teniendo acceso a los recursos hasta que el JWT expire. De manera similar, si un JWT contiene información de autorización basada en roles, el nuevo alcance de autorización no entrará en vigor hasta que expire el antiguo JWT. En otras palabras, los JWTs no son adecuados para la revocación en tiempo real y los usuarios pueden establecer un tiempo de expiración adecuado para mitigar este problema.

• Dilema de múltiples dispositivos y revocación

  No es posible validar todos los JWTs emitidos antes de que expiren para implementar la revocación de usuario en todos los dispositivos. Aunque teóricamente es posible revocar la clave de firma para hacer el JWT inválido, esto también invalidaría todos los JWTs que utilizan esa clave, y el proceso de manejo de claves de caché haría que este enfoque sea poco práctico para operaciones simples de revocación de usuario.

Algunos proveedores de identidad podrían tener soluciones preconstruidas para estos problemas de JWT. Para más información, consulta "Mejores Prácticas para Mejorar la Experiencia de Autenticación JWT.”

¿Cuál es la diferencia entre JWT y Sesión?#

Las sesiones y los JWT son dos enfoques populares para mantener el contexto de autenticación y autorización en un mundo sin estado HTTP. Mientras ambos enfoques tienen sus pros y contras, ofrecen diferentes beneficios y desventajas.

Las sesiones proporcionan garantías más fuertes para la autorización de solicitudes individuales y son más simples de implementar de forma segura. Sin embargo, su dependencia en validación basada en bases de datos del lado del servidor introduce latencia adicional, lo que puede afectar negativamente la experiencia del usuario para aplicaciones altamente sensibles.

Por otro lado, los JWTs son ventajosos para una autorización más rápida e interoperabilidad con aplicaciones externas, pero requieren más esfuerzo del desarrollador para abordar las complejidades de seguridad. Por ejemplo, podemos usar webhooks para notificar a los clientes cuando se revoca el acceso de usuario, para que los clientes puedan borrar el JWT en caché y forzar al usuario a re-autenticarse.

Dado que la autenticación basada en tokens es más adecuada para escalar con sus desventajas aún manejables, está siendo adoptada por más aplicaciones modernas.

Sesión vs. JWT: Elegir el método correcto#

Tu método de autenticación debe coincidir con la arquitectura y necesidades específicas de tu aplicación. Aquí tienes una guía rápida para ayudarte a decidir:

Cuándo usar autenticación basada en sesiones#

La autenticación basada en sesiones funciona mejor cuando necesitas control de sesión en tiempo real, necesitas gestión centralizada, o la escalabilidad no es una preocupación principal. Aquí es donde destaca:

• Aplicaciones web con sesiones persistentes

  Para plataformas como sitios web de compras en línea, las sesiones son esenciales para rastrear usuarios, carritos de compras y preferencias durante su visita.

• Aplicaciones que requieren control de sesión en tiempo real

  Aplicaciones como servicios bancarios o financieros se benefician del control servido de los datos de sesión, asegurando una gestión de acceso robusta y seguridad.

• Sistemas de servidor único o pequeña escala

  Herramientas internas o aplicaciones de pequeña escala sin necesidades altas de escalabilidad prosperan en una gestión de sesiones sencilla para facilitar su uso y confiabilidad.

Cuándo usar autenticación JWT#

La autenticación JWT es más adecuada para aplicaciones que priorizan la escalabilidad, eficiencia y sistemas distribuidos. Es particularmente útil para interacciones sin estado entre clientes y servidores. Considera la autenticación basada en tokens para lo siguiente:

• Inicio de Sesión Único (SSO)

  Los JWTs son perfectos para Inicio de Sesión Único, permitiendo a los usuarios autenticarse una vez y acceder de manera fluida a múltiples servicios o aplicaciones usando el mismo token. Comparte una explicación detallada sobre aplicaciones basadas en la nube seguras usando OAuth 2.0 y OIDC, con formato JWT para ambos tokens de acceso y tokens de ID.

• Aplicaciones móviles

  Las aplicaciones móviles a menudo prefieren los JWTs para autenticación, ya que los tokens se pueden almacenar de manera segura en el dispositivo y enviar con cada solicitud API. Explora la integración rápida de autenticación JWT para Android / iOS.

• Arquitecturas de microservicios

  En entornos de microservicios, los JWTs permiten que cada servicio valide el token de manera independiente sin depender de un almacén de sesiones central, asegurando la escalabilidad y eficiencia.

• Autenticación de dominio cruzado

  Los JWTs sobresalen en escenarios que involucran múltiples dominios o subdominios (por ejemplo, api.example.com, dashboard.example.com, y docs.example.com). A diferencia de las cookies, los JWTs permiten autenticación a través de dominios sin dependencias adicionales.

• APIs y servicios web

  APIs RESTful y servicios web usan comúnmente los JWTs para autenticación porque son ligeros, portátiles y eliminan la necesidad de gestión de sesiones del lado del servidor. Aprende más sobre autenticación entre máquinas para escenarios donde tu aplicación necesita comunicarse directamente con recursos.

Mejores prácticas para mejorar la experiencia de autenticación JWT#

La autenticación JWT es una gran herramienta, pero puede venir con desafíos que afectan la experiencia del usuario. Logto ofrece una solución fácil y confiable para superar estos obstáculos, haciéndola una opción principal para autenticación segura y eficiente.

Manejo de problemas de cierre de sesión de usuario con JWT#

Un problema común con la autenticación JWT es asegurar una experiencia adecuada de cierre de sesión de usuario. Logto simplifica este proceso con su SDK listo para usar.

• Al borrar tokens y sesiones locales en el lado del cliente y redirigir a los usuarios al punto de fin de sesión de Logto, puedes terminar fácilmente las sesiones en la aplicación cliente y el servidor.
• Además, Logto soporta cierre de sesión por canal trasero, permitiendo que el AuthServer notifique a todas las aplicaciones cliente que comparten la misma sesión cuando un usuario cierra sesión.

Esto asegura una gestión de sesión consistente y segura a través de tu ecosistema. Aprende más sobre el manejo de cierre de sesión.

Manejo de cambios en permisos de usuario#

Manejar cambios en tiempo real a los permisos de usuario con JWT también puede ser complicado. Dado que los JWTs son sin estado por diseño, cualquier permiso o rol actualizado puede no entrar en vigor hasta que el token expire. Logto ofrece estrategias para manejar esto efectivamente:

• Para disminuir permisos para este usuario: Usa tiempos de expiración de token de acceso cortos o verifica dinámicamente permisos vía una llamada API.
• Para agregar nuevos permisos para este usuario: Actualiza el AuthServer para incluir el nuevo alcance de permiso y vuelve a obtener el consentimiento de los usuarios para aplicar estos cambios.

Estas soluciones ayudan a mantener los permisos actualizados y aseguran un sistema más seguro y sensible. Aprende más sobre el manejo de cambios de permisos.

Logto, que es una infraestructura de gestión de acceso e identidad escalable, proporciona una solución de identidad completa con ambos servicio en la nube y versión de código abierto disponibles.