Saltar al contenido principal
Finalizar una sesión autenticada cuando ya no se necesita, también conocido como cierre de sesión, es una buena práctica de higiene de seguridad. Ofrecer la posibilidad de cerrar sesión ayuda a mitigar diversos posibles problemas de seguridad, incluida la posibilidad de que terceros no autorizados puedan “apoderarse” de una sesión. En nuestros escenarios de arquitectura, ofrecemos orientación general sobre B2B Logout, que recomendamos revisar junto con la orientación que se proporciona aquí. Para este escenario, el cierre de sesión es casi idéntico al de cualquier otro sistema, por lo que tendrá el mismo nivel de complejidad que se describe en nuestra documentación estándar.

Conexión de base de datos

Tomando como ejemplo Hoekstra & Associates, el siguiente diagrama ilustra el flujo que suele darse al trabajar con un usuario autenticado mediante una Conexión de base de datos de Auth0. Veamos este flujo para entender qué sucede; tenga en cuenta que la mayor parte del flujo de trabajo descrito normalmente se gestionará mediante el SDK o la biblioteca de Auth0 correspondiente a su pila tecnológica:
Escenarios de arquitectura - MOA - Usuarios aislados, aplicaciones compartidas, flujo de cierre de sesión
  1. Jennifer hace clic en logout.
  2. La instancia de Travel0 Corporate Booking de Hoekstra & Associates redirige el navegador al Tenant de Auth0 de Travel0 en https://auth.travel0.net con los siguientes parámetros:
    1. returnTo: https://hoekstra.corp.travel0.net/logoutComplete
    2. client_id: ID de cliente asociado con la aplicación creada en el Tenant de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de Hoekstra & Associates.
      Práctica recomendadaDefina las aplicaciones de forma independiente en Auth0 para facilitar la configuración de la URL returnTo, donde se usa el client_id correspondiente para validar correctamente la URL proporcionada. Para obtener más información, consulte Provisioning.
  3. El Tenant de Auth0 de Travel0 finaliza la sesión de Auth0 establecida en nombre del usuario, elimina cualquier información de SSO y redirige el navegador a la URL returnTo especificada.
  4. La instancia de Travel0 Corporate Booking de Hoekstra & Associates muestra una página para indicarle a Jennifer que cerró sesión correctamente, probablemente con un botón para volver a iniciar sesión si lo desea.
    1. En esta etapa, la instancia de Travel0 Corporate Booking normalmente también querrá cerrar la sesión de la aplicación asociada con el usuario.
Si no desea eliminar la sesión de SSO del usuario en Auth0, la aplicación puede simplemente finalizar la sesión de la aplicación sin redirigir al endpoint /logout en el Tenant de Auth0. Aunque el usuario habrá cerrado sesión en la aplicación, seguirá teniendo una sesión de SSO con Auth0. En este caso, probablemente querrá informarle al usuario que todavía tiene una sesión activa en el Tenant de Auth0 y que, si vuelve a hacer clic en login, es posible que no se le solicite introducir credenciales del primer factor.

Conexión empresarial

En este escenario, implementar el cierre de sesión puede ser un poco más complejo que cuando se usa una Conexión de base de datos. Sigue teniendo la opción de cerrar sesión solo en la aplicación o de hacer que al cerrar sesión en la aplicación también se cierre la sesión en el Tenant de Auth0. Sin embargo, también puede tener la opción de permitir el cierre de sesión en el (IdP) de la organización, algo que la mayoría de las aplicaciones evitan, especialmente si los usuarios tienen acceso a otras aplicaciones corporativas en las que quizá necesiten seguir con la sesión iniciada. Sin evitarlo, sin embargo, es posible que los usuarios que más tarde hagan clic en el botón login sean autenticados automáticamente sin proporcionar de forma interactiva credenciales del primer factor. Esta funcionalidad puede generar una experiencia de usuario inesperada, por lo que debería considerar comunicárselo al usuario. Tomando nuestro ejemplo de MetaHexa Bank, veamos cómo podría desarrollarse esta implementación del cierre de sesión con un usuario autenticado mediante una Conexión empresarial a MetaHexa Bank; de nuevo, la mayor parte del flujo de trabajo descrito normalmente se gestionará mediante el SDK o la biblioteca de Auth0 correspondiente a su pila tecnológica:
Escenarios de arquitectura - MOA - Usuarios aislados, aplicaciones compartidas, flujo de cierre de sesión empresarial
  1. Amintha hace clic en logout.
  2. La instancia de Travel0 Corporate Booking de MetaHexa Bank redirige el navegador al Tenant de Auth0 de Travel0 en https://auth.travel0.net con los siguientes parámetros:
    1. returnTo: https://metahexa.corp.travel0.net/logoutComplete
    2. client_id: ID de cliente asociado a la aplicación creada en el Tenant de Auth0 de Travel0 para la instancia de Travel0 Corporate Booking de MetaHexa Bank.
    3. federated:  Parámetro opcional que se usa para cerrar la sesión del usuario en el IdP de MetaHexa Bank. Cuando se especifica, el navegador se redirige al endpoint /logout asociado al IdP de MetaHexa Bank, que finaliza la sesión del usuario antes de redirigir el navegador de vuelta al Tenant de Auth0 de Travel0.
      Práctica recomendadaDefina las aplicaciones de forma independiente en Auth0 para facilitar la configuración de la URL returnTo, donde el client_id correspondiente se usa para validar correctamente la URL proporcionada. Para obtener más información, consulte Provisioning.
Los pasos 3 y 4 coincidirán con los descritos en el escenario de Conexión de base de datos, pero usarán a Amintha en lugar de Jennifer y MetaHexa Bank (metahexa.corp.travel0.net) en lugar de Hoekstra & Associates.

Conexión social

En el contexto de las conexiones sociales, el cierre de sesión sigue un patrón similar al de una Conexión empresarial, pero el IdP de origen está asociado al proveedor social, y no a una organización específica. Es casi seguro que nunca querrá aprovechar la capacidad de cierre de sesión federado con un proveedor social, porque la experiencia de usuario resultante sería demasiado intrusiva.