Saltar al contenido principal
Una sesión es un conjunto de interacciones entre un usuario y una aplicación durante un período determinado. Una sola sesión puede incluir múltiples actividades (como vistas de página, eventos, interacciones sociales y transacciones de comercio electrónico) y almacenar esta información temporalmente mientras el usuario permanece conectado. Con una implementación estándar del encabezado Set-Cookie, una sesión termina cuando un usuario abandona un sitio web o cierra el navegador. Para evitar que los usuarios tengan que iniciar sesión cada vez, las aplicaciones pueden extender las sesiones configurando una duración máxima para la . Las sesiones terminan cuando un usuario cierra sesión o cuando se alcanza el límite de duración de la sesión. Para obtener más información, consulta la Política de Privacidad y Cookies de Auth0.

​
Casos de uso de las sesiones

Auth0 mantiene una sesión de inicio de sesión para cualquier usuario que se autentique a través de una aplicación. Cuando un usuario vuelve a iniciar sesión de forma estándar, Auth0 restablece la sesión de inicio de sesión. Actualizar la contraseña, el correo electrónico, el número de teléfono o el username también hace que la sesión de Auth0 del usuario caduque. Cuando crea una aplicación que requiere autenticación, puede usar sesiones para determinar si un usuario está autenticado cada vez que se realiza una solicitud. Según cómo esté diseñada su aplicación, se recomiendan distintos para ofrecer una experiencia más segura a los usuarios. Por ejemplo, considere un sitio web compatible con OIDC ( Connect) llamado storezero.io.
Ejemplo de sitio web de comercio electrónico Storezero.io
Storezero.io no exige que sus usuarios inicien sesión para completar compras. Sin embargo, los usuarios deben iniciar sesión para ver la sección Mi cuenta del sitio. Para los casos de uso que se enumeran a continuación, considere un escenario en el que un usuario quiere revisar sus pedidos anteriores antes de finalizar la compra. Para ello, navega a la página Todos los pedidos de la sección Mi cuenta y se le pide que inicie sesión.

​
Flujos de inicio de sesión

La mayoría de los tipos de aplicaciones (como las aplicaciones web, las aplicaciones de una sola página y las aplicaciones nativas) deben usar el flujo de código de autorización con PKCE para gestionar la autenticación de inicio de sesión. Este flujo consiste en intercambiar un código de autorización por tokens.
El flujo de código de autorización con PKCE sustituye el uso anterior del flujo implícito en aplicaciones de una sola página sin backend. Los desarrollos nuevos deben usar este flujo para garantizar una seguridad óptima. También se recomienda encarecidamente migrar las aplicaciones existentes que usan el flujo implícito al flujo de código de autorización con PKCE.

​
El usuario inicia sesión con username y contraseña

En este ejemplo, un usuario inicia sesión manualmente con su username y contraseña:
  1. El SDK de Auth0 crea una sesión local y redirige al usuario al servidor de autorización de Auth0 (endpoint /authorize).
  2. El servidor de autorización crea una sesión y, a continuación, redirige al usuario a la pantalla de inicio de sesión y autorización.
  3. El usuario se autentica con su username y contraseña.
  4. El servidor de autorización de Auth0 actualiza la sesión del usuario creada anteriormente para indicar que ha iniciado sesión.
  5. Según el flujo utilizado, el servidor de autorización devuelve al usuario a su aplicación junto con un token de ID o un código de autorización.
  6. Su aplicación intercambia el token o el código de autorización por un token de acceso y completa el flujo.
Con este flujo, se crean dos sesiones:
  • La sesión local (storezero.io), que indica a la aplicación si un usuario está autenticado.
  • La sesión del (storezero.auth0.com), que indica al servidor si un usuario está autenticado. La sesión del servidor también puede registrar opcionalmente detalles sobre la autenticación.
    • Por ejemplo, el servidor de autorización puede registrar si un usuario utilizó autenticación multifactor (MFA). Esta información puede utilizarse después para determinar si se debe pedir a un usuario que inicie sesión o use MFA la próxima vez que llegue al servidor de autorización.

​
El usuario inicia sesión con un proveedor de identidad

En este ejemplo, el usuario elige iniciar sesión con Facebook en lugar de usar su nombre de usuario y contraseña:
  1. El SDK de Auth0 crea una sesión local y redirige al usuario al servidor de autorización de Auth0 (endpoint /authorize).
  2. El servidor de autorización crea una sesión y luego redirige al usuario a la pantalla de inicio de sesión y autorización.
  3. Al elegir iniciar sesión con Facebook, el servidor de autorización redirige al usuario a Facebook.
  4. Facebook crea una sesión y autentica al usuario. Luego, Facebook actualiza su sesión para indicar que el usuario inició sesión.
  5. Facebook devuelve al usuario al servidor de autorización de Auth0. Luego, el servidor de autorización actualiza su sesión para indicar que el usuario inició sesión.
  6. Según el flujo utilizado, el servidor de autorización devuelve al usuario a su aplicación, junto con un token de ID o un código de autorización.
  7. Su aplicación intercambia el token o el código de autorización por un token de acceso y completa el flujo.
En este escenario, se crean tres sesiones: la sesión local (storezero.io), la sesión del servidor de autorización (storezero.auth0.com) y una sesión del (IdP) (facebook.com). La sesión del IdP en el servidor de Facebook autentica al usuario y proporciona una experiencia de fluida. Como es muy probable que los usuarios ya hayan iniciado sesión en Facebook, a menudo se autentican sin tener que introducir manualmente sus credenciales de Facebook.

​
Gestión de sesiones para las SPA

En los ejemplos anteriores, se crea una sesión local cuando el usuario inicia cualquiera de los flujos de inicio de sesión. Esta sesión local puede mantener la sesión iniciada de los usuarios y determinar cuándo deben volver a autenticarse. Sin embargo, las sesiones locales no están disponibles para aplicaciones sin backend, como las aplicaciones de una sola página (SPA). En su lugar, estas aplicaciones usan un enfoque distinto conocido como autenticación silenciosa para mantener la sesión iniciada de los usuarios. La autenticación silenciosa usa la sesión en el servidor de autorización para determinar cuándo un usuario debe volver a autenticarse. Un iframe oculto redirige las solicitudes de autenticación al servidor de autorización junto con el parámetro prompt=none. Este parámetro evita que el servidor solicite intervención del usuario.
  • Si la sesión en el servidor de autorización no ha expirado, la transacción continúa sin problemas. El servidor envía un mediante WMRM (Web Message Response Mode), que utiliza postMessage.
  • Si la sesión en el servidor de autorización ha expirado o el usuario cierra sesión, la redirección en el iframe devuelve un error. Entonces, la aplicación debe dirigir al usuario al servidor de autorización para que vuelva a autenticarse.

​
Más información