Saltar al contenido principal

Cierre de sesión

El proceso de cierre de sesión en Logto (como proveedor de identidad basado en OIDC) es un concepto multifacético debido a la participación tanto de la sesión de inicio de sesión centralizada gestionada por Logto como del estado de autenticación distribuido gestionado por las aplicaciones cliente.

Sesión de inicio de sesión​

Para comprender mejor el proceso de cierre de sesión, es importante entender primero cómo se gestionan las sesiones de inicio de sesión de usuario y su estado de autenticación en Logto.

  1. El usuario accede a la aplicación web (RP).
  2. La aplicación cliente redirige al usuario a Logto (IdP) para la autenticación (Authentication).
  3. El proveedor OIDC verifica el estado de la sesión de inicio de sesión del usuario. Si no existe sesión o la sesión ha expirado, se solicita al usuario iniciar sesión.
  4. El usuario interactúa con la página de inicio de sesión para autenticarse.
  5. Tras un inicio de sesión exitoso, Logto crea una nueva sesión para el usuario y lo redirige de vuelta a la aplicación cliente con un código de autorización.
  6. El proveedor OIDC crea una nueva sesión de inicio de sesión y concesión de autenticación para el usuario.
  7. El proveedor OIDC redirige al usuario de vuelta al cliente con un código de autenticación (Flujo de Código de Autorización).
  8. El cliente recibe el código de autenticación y lo intercambia por tokens para acceder a la información del usuario.
  9. Concede tokens a la aplicación cliente.

Componentes​

Sesión de inicio de sesión centralizada gestionada por Logto​

En el flujo anterior, la sesión de inicio de sesión centralizada es gestionada por Logto. La sesión se crea cuando el usuario inicia sesión con éxito y se destruye cuando el usuario cierra sesión. La sesión también se destruye cuando la sesión del usuario expira.

La sesión de inicio de sesión de Logto se gestiona mediante cookies de sesión. La cookie de sesión se establece cuando el usuario inicia sesión. Todas las solicitudes de autenticación se validan contra la cookie de sesión. Si la cookie de sesión está presente y es válida, el usuario será autenticado automáticamente y redirigido directamente a la aplicación cliente con el código de autorización. De lo contrario, se solicitará al usuario iniciar sesión.

  1. Cookie de sesión compartida de Logto
    Para un usuario que inicia sesión en varias aplicaciones cliente desde el mismo agente de usuario (por ejemplo, navegador), el usuario tendrá una cookie de sesión compartida bajo el dominio de Logto. Esto significa que el usuario solo necesita iniciar sesión una vez y será autenticado automáticamente para otras aplicaciones cliente.

  2. Cookie de sesión aislada de Logto
    Para un usuario que inicia sesión en diferentes aplicaciones cliente desde diferentes dispositivos o navegadores, el usuario tendrá cookies de sesión aisladas bajo el dominio de Logto. Esto significa que el usuario necesita iniciar sesión por separado en cada aplicación cliente.

Estado de autenticación distribuido gestionado por las aplicaciones cliente​

Cada aplicación cliente mantiene su propio estado de autenticación. Ya sea una aplicación Nativa, SPA o Web, todas tienen su propia forma de gestionar el estado de autenticación del usuario.

Tras un inicio de sesión exitoso, la aplicación cliente puede recibir un Token de ID (ID token) y un Token de acceso (Access token). La aplicación cliente puede usar el Token de ID para determinar la identidad del usuario y el Token de acceso para acceder a los recursos del usuario. El estado de autenticación del usuario está representado por el tiempo de expiración del Token de acceso.

  • Aplicaciones Nativas y SPA:
    La aplicación cliente necesita almacenar y gestionar estos tokens de forma segura para mantener el estado de autenticación del usuario. Por ejemplo, almacenar los tokens en el almacenamiento local o de sesión, y limpiar los tokens cuando el usuario cierra sesión.
  • Aplicaciones Web:
    Las aplicaciones web como las construidas con frameworks como Next.js suelen gestionar su propia sesión para los usuarios autenticados junto con los tokens emitidos por Logto. Una vez que el usuario inicia sesión y la aplicación web recibe los tokens de Logto, puede almacenarlos en el lado del cliente como las aplicaciones SPA, o almacenarlos en el lado del servidor y gestionar la sesión usando cookies u otros mecanismos.

Mecanismos de cierre de sesión​

Limpiar tokens y sesión local en el lado del cliente​

En el lado del cliente, un cierre de sesión simple implica limpiar la sesión local y eliminar los tokens (Token de ID, Token de acceso, Token de actualización) del almacenamiento local o de sesión. Esto resulta en un cierre de sesión solo del lado del cliente, donde la sesión centralizada permanece intacta. Los usuarios que cierran sesión de esta manera aún pueden acceder a otras aplicaciones bajo la misma sesión del servidor de autorización hasta que la sesión centralizada expire o sea destruida activamente.

Limpiar la sesión de inicio de sesión en Logto​

Para cerrar sesión explícitamente y limpiar la sesión en Logto, la aplicación cliente debe redirigir al usuario al endpoint de fin de sesión de Logto.

Ejemplo: https://{your-logto-domain}/oidc/session/end

El endpoint de fin de sesión es un endpoint estándar de OIDC que permite a la aplicación cliente notificar al servidor de autorización que el usuario ha cerrado sesión. El endpoint limpiará la sesión de inicio de sesión centralizada en Logto.

Una vez que la sesión se limpia, cualquier solicitud de autorización posterior requerirá que el usuario inicie sesión nuevamente.

Si se proporciona un post-logout redirect URI, el usuario será redirigido a la URI especificada después de limpiar la sesión. De lo contrario, el usuario será redirigido a la página predeterminada de cierre de sesión alojada por Logto.

Cierre de sesión federado: Back-channel logout​

Para una gestión de cierre de sesión más consistente, Logto admite el back-channel logout. El back-channel logout es un mecanismo que permite a Logto notificar a todas las aplicaciones cliente bajo la misma sesión de inicio de sesión cuando el usuario cierra sesión.

Esto es especialmente útil en escenarios donde el usuario cierra sesión desde una aplicación cliente y espera cerrar sesión en todas las demás aplicaciones cliente bajo la misma sesión de inicio de sesión de Logto.

Para habilitar el back-channel logout para tus aplicaciones cliente, ve a la página de detalles de la aplicación en el panel de Logto y registra una URI de back-channel logout. Logto enviará un token de cierre de sesión a todas las URI registradas cuando el usuario inicie una solicitud de cierre de sesión desde cualquier aplicación cliente.

Si tu aplicación cliente requiere que la sesión de inicio de sesión se incluya en el token de cierre de sesión, activa la configuración Is session required en la configuración de back-channel logout. Se incluirá un reclamo sid en el token de cierre de sesión para identificar la sesión de inicio de sesión del usuario en Logto.

  1. El usuario inicia una solicitud de cierre de sesión desde una aplicación cliente.
  2. Logto recibe la solicitud de fin de sesión, genera un token de cierre de sesión y lo envía a todas las URI de back-channel logout registradas.
  3. Cada aplicación cliente recibe el token de cierre de sesión y realiza las acciones de cierre de sesión.

Acciones de cierre de sesión para cada aplicación cliente al recibir el token de cierre de sesión:

  • Validar el token de cierre de sesión.
  • Limpiar la sesión local y eliminar los tokens del almacenamiento local o de sesión.

Métodos de cierre de sesión en los SDKs de Logto​

Si estás integrando Logto con tu aplicación cliente usando los SDKs de Logto:

  • Para aplicaciones SPA y web, el método client.signOut() limpiará el almacenamiento local de tokens y redirigirá al usuario al endpoint de fin de sesión de Logto. Puedes especificar una post-logout redirect URI para redirigir al usuario después de limpiar la sesión.
  • Para aplicaciones nativas (incluyendo apps híbridas como React Native y Flutter), solo se limpia el almacenamiento local de tokens. Esto se debe a que en aplicaciones nativas, usamos el webview sin sesión para manejar el proceso de inicio de sesión. No se almacenan cookies de sesión en el navegador nativo, por lo que no es necesario limpiar la sesión de inicio de sesión en Logto. Cada solicitud de autenticación es una solicitud independiente que no lleva cookies de sesión.
nota:

Para aplicaciones nativas que no admiten webview sin sesión o no reconocen la configuración emphasized (aplicaciones Android usando el SDK de React Native o Flutter), puedes forzar que el usuario deba iniciar sesión nuevamente pasando el parámetro prompt=login en la solicitud de autorización.

Forzar la re-autenticación en cada acceso​

En escenarios de alta seguridad—como la verificación de la identidad del usuario antes de acciones sensibles—puedes requerir que el usuario se re-autentique en cada acceso. Para forzar este comportamiento, incluye prompt=login en tu solicitud de autenticación.

Establecer prompt=login obliga a Logto a mostrar siempre la página de inicio de sesión, independientemente de si el usuario tiene una sesión activa o ha iniciado sesión recientemente. Esto omite el comportamiento de inicio de sesión único (SSO) y asegura que se soliciten las credenciales del usuario cada vez.

Si tu aplicación solicita el alcance offline_access (para recibir un Token de actualización), la especificación de OpenID Connect requiere que también incluyas prompt=consent.
En la mayoría de los casos, para forzar tanto la re-autenticación como la emisión del Token de actualización, establece:

prompt=login consent

Esto garantiza que el usuario se re-autentique y consienta explícitamente el acceso offline.

Preguntas frecuentes​

No estoy recibiendo las notificaciones de back-channel logout.​

  • Asegúrate de que la URI de back-channel logout esté correctamente registrada en el panel de Logto.
  • Asegúrate de que tu aplicación cliente tenga una sesión de inicio de sesión activa válida y que sea la misma sesión que inició la solicitud de cierre de sesión.

Entendiendo el back-channel logout de OIDC.