JWT vs Autenticación basada en sesiones

En general, 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 con éxito. Después de este paso, el sistema de identidad (es decir, el proveedor de identidad, el servidor de autenticación, etc.) sabe quién es el usuario y a qué recursos tiene acceso.

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

Entremos en la autenticación basada en sesiones y autenticación JWT (JSON Web Tokens), dos métodos populares para mantener el estado de autenticación. Cada uno tiene ventajas y desventajas únicas, 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 ayudar.

¿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 introducir credenciales con cada solicitud.

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

Creación de sesiones

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 del usuario, hora de inicio de la 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 sesiones

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 las cargas iniciales de página o a través de llamadas API con un SessionID).
2. Cada llamada subsiguiente 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 cual es útil en situaciones donde es necesario un acceso rápido.

• Usuarios cierran sesión manualmente: El servidor elimina el registro de la sesión, efectivamente desconectando al usuario.
• Administradores fuerzan el cierre de sesión de usuarios: Los administradores o sistemas pueden terminar sesiones específicas eliminándolas de la base de datos. Por ejemplo, durante una violación de seguridad.
• Expiración de sesiones: Las sesiones pueden expirar automáticamente después de un periodo determinado de inactividad, o un límite de tiempo fijo.

Ventajas de la autenticación basada en sesiones#

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

Desventajas de la autenticación basada en sesiones#

• Latencia en sistemas distribuidos: Mantener los datos de la sesión en varios servidores siempre requiere sincronizar un almacén de sesiones. Esto introduce latencia adicional porque el servidor tiene que verificar el almacén de sesiones cada vez que se realiza una solicitud.
• Alto consumo de recursos: Cada sesión ocupa recursos del servidor, afectando el rendimiento cuando la base de usuarios crece.
• Riesgo de seguridad: El secuestro de sesiones (vía 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 ideal para aplicaciones móviles. Almacena datos de sesión en el servidor, lo cual puede aumentar la carga y complejidad con muchos usuarios. Además, utiliza 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 incorporar toda la información relevante del usuario directamente en un token, usando un objeto JSON. A diferencia de los métodos basados en sesiones, los JWT son sin estado, lo que significa que el servidor no gestiona registros de autenticación.

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

Un JWT consta de tres partes: un header, payload y signature.

• El header contiene el algoritmo de firma (por ejemplo, HS256) y el tipo de token (JWT).
• El payload contiene las declaraciones claims principales, como la identidad del usuario, el rol del usuario y el tiempo de expiración.
• La signature utiliza una clave para firmar el encabezado y el payload, permitiendo verificar si la firma ha sido manipulada.

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 el encabezado, el payload y la 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 sesiones 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 JWT dependen de los tokens enviados al cliente para su almacenamiento y uso posterior.

Validación de tokens

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

La autenticación basada en sesiones requiere que el servidor consulte un almacén de sesiones, lo cual 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 asegurar la seguridad. Esto elimina la necesidad de gestionar sesiones, haciendo que sea más rápido y escalable, especialmente en sistemas distribuidos.

¿Cómo revocar un JWT?#

En el lado del cliente, cerrar sesión generalmente significa 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 localmente, dejando intacta la sesión centralizada en el servidor de autorización. Como resultado, los usuarios aún pueden acceder a otras aplicaciones bajo la misma sesión hasta que el token expire o se termine manualmente.

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

• Tiempos de expiración cortos: Establecer un reclamo exp corto (por ejemplo, 15 minutos) para el JWT. Una vez vencido, el usuario debe volver a autenticar. Esto minimiza el riesgo si se compromete un token, ya que el atacante solo puede usarlo por un tiempo limitado. Para mantener una experiencia de usuario continua, se puede usar un token de actualización para minimizar la molestia de volver a autenticar.
• Lista negra de tokens: Para casos críticos (por ejemplo, cerrar sesión del usuario, cambios de contraseña), mantener una lista negra de tokens revocados. El servidor verifica los tokens entrantes contra este bloque y rechaza cualquier coincidencia. Aunque efectiva, esta estrategia requiere rastrear tokens revocados, lo que va en contra de la naturaleza sin estado de los JWT y puede volverse ineficiente si la lista crece demasiado.
• Punto de revocación: Introducir un punto de revocación en el servidor de autorización donde los tokens (por ejemplo, tokens de actualización) pueden ser invalidados. Una vez que se revoca un token de actualización, cualquier token de acceso emitido a partir de este ya no se renovará. Este método funciona bien en flujos OAuth2.

Ventajas de la autenticación JWT#

• Rápida y más informativa: La naturaleza auto contenida de los JWT hace que la verificación en el lado del cliente sea más rápida y eficiente, sin necesidad de interacción con el servidor. También pueden incluir declaraciones personalizadas (por ejemplo, roles de usuario u otros datos relevantes) dentro del token, permitiendo que los servidores determinen roles sin consultar una base de datos.
• Seguridad mejorada: Los JWT utilizan técnicas de firma y cifrado, haciéndolos más difíciles de atacar.
• Soporte multiplataforma: Los JWT son perfectos para Single Sign-On (SSO) y la autenticación multiplataforma. Permiten a los usuarios autenticarse a través de múltiples dominios o servicios con el mismo token.
• Amigable con dispositivos móviles: Los JWT funcionan muy bien para aplicaciones móviles que necesitan autenticación sin estado. Los tokens pueden almacenarse en el lado del cliente y enviarse con cada solicitud, mejorando la eficiencia y facilidad de uso.

Desventajas de la autenticación JWT#

• JWT no se actualizan en tiempo real

  Una vez firmado un JWT, no puede revocarse ni actualizarse, y se considerará válido siempre que la firma sea válida y no haya expirado.

  Si los permisos de acceso de un usuario cambian (generalmente se degradan), el usuario aún tendrá acceso eliminado a los recursos hasta que el JWT expire. Del mismo modo, si un JWT contiene información de autorización basada en roles, el nuevo alcance de autorización no surtirá efecto hasta que el antiguo JWT expire. En otras palabras, los JWT 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 JWT emitidos antes de que expiren para implementar la revocación del usuario en todos los dispositivos. Mientras que teóricamente es posible revocar la clave de firma para invalidar el JWT, esto también invalidaría todos los JWT que usan esa clave, y el proceso de manejo de claves en caché hace que este enfoque no sea práctico para operaciones de revocación de usuario simples.

Algunos proveedores de identidad pueden 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 Sesiones?#

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

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 de la validación de base de datos del lado del servidor introduce una sobrecarga de latencia, lo cual puede afectar negativamente la experiencia del usuario para aplicaciones altamente responsivas.

Los JWT, por otro lado, son ventajosos para 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 del usuario, de modo que los clientes puedan limpiar el JWT almacenado en caché y hacer que el usuario vuelva a autenticarse.

Ya 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 y más aplicaciones modernas.

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

Tu método de autenticación debería coincidir con la arquitectura de tu aplicación y necesidades específicas. 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 importante. Aquí es donde brilla:

• 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 de datos de sesión controlados por el servidor, asegurando una gestión de acceso robusta y segura.

• Sistemas de un solo servidor o de pequeña escala

  Herramientas internas o aplicaciones de pequeña escala sin necesidades de gran escalabilidad prosperan con una gestión de sesiones simple para facilitar el uso y la fiabilidad.

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:

• Single Sign-On (SSO)

  Los JWT son perfectos para Single Sign-On, permitiendo a los usuarios autenticarse una vez y acceder sin problemas a múltiples servicios o aplicaciones usando el mismo token. Comparte una explicación detallada sobre aplicaciones seguras basadas en la nube usando OAuth 2.0 y OIDC, con formato JWT tanto para tokens de acceso como para tokens de ID.

• Aplicaciones móviles

  Las aplicaciones móviles a menudo prefieren los JWT para la autenticación, ya que los tokens pueden almacenarse de manera segura en el dispositivo y enviarse 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 JWT permiten que cada servicio valide de manera independiente el token sin depender de un almacén de sesiones central, asegurando escalabilidad y eficiencia.

• Autenticación entre dominios

  Los JWT 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 JWT permiten la autenticación a través de dominios sin dependencias adicionales.

• APIs y servicios web

  APIs RESTful y servicios web comúnmente usan JWT para la autenticación porque son livianos, portátiles y eliminan la necesidad de gestión de sesiones del lado del servidor. Aprende más sobre la autenticación máquina a máquina 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éndolo una elección superior 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 de cierre de sesión de usuario adecuada. Logto simplifica este proceso con su SDK listo para usar.

• Al limpiar tokens y sesiones locales en el lado del cliente y redirigir a los usuarios al punto final de fin de sesión de Logto, puedes terminar fácilmente las sesiones tanto en la aplicación cliente como en 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 se desconecta.

Esto asegura una gestión de sesiones consistente y segura en todo tu ecosistema. Aprende más sobre los mecanismos de cierre de sesión y cómo implementar el cierre de sesión.

Manejo de cambios de permisos de usuarios#

Gestionar cambios en tiempo real a los permisos de usuarios con JWT también puede ser complicado. Ya que los JWT son sin estado por diseño, cualquier permiso o rol actualizado puede no surtir efecto hasta que el token expire. Logto ofrece estrategias para manejar esto de manera efectiva:

• Para disminuir permisos para este usuario: Usa tiempos de expiración de tokens de acceso cortos o verifica dinámicamente los permisos a través de una llamada API.
• Para agregar nuevos permisos para este usuario: Actualiza el AuthServer para incluir el nuevo alcance de permisos y solicita nuevamente 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 receptivo. Aprende más sobre cómo gestionar cambios en tiempo real a los permisos de usuarios.

Logto, que es una infraestructura de gestión de acceso a identidad escalable, proporciona una solución completa de identidad tanto con servicio en la nube como con versión de código abierto disponible.