Sessions avec Actions

Gérez les sessions utilisateur Auth0 avec Actions pour consulter les métadonnées de session, définir des durées de vie personnalisées et révoquer ou prolonger des sessions.

L’utilisation des sessions avec Actions vous permet de configurer des capacités de détection des risques et d’intervention après l’authentification afin de protéger vos applications et vos utilisateurs contre le détournement de session. Vous pouvez aussi personnaliser dynamiquement les limites de durée de vie des sessions.

À cette fin, les Actions post-login offrent deux objets clés :

• event.session: Fournit des renseignements pertinents, notamment un id unique, les dates created_at, expires_at, idle_expires_at et updated_at, ainsi que l’information sur clients, authentication_at et device, comme ASN, IP et User_agent.
• api.session: Vous permet de gérer les sessions existantes en révoquant des sessions ou en modifiant les dates expiry.

Les objets event.session et api.session prennent tous deux en charge les flux interactifs sur le Web, y compris le flux du code d’autorisation, le flux implicite, le flux du code d’appareil, ainsi que SAML et WS-Fed.

Vous pouvez utiliser l’objet event.session pour examiner les horodatages des interactions les plus récentes et évaluer les risques associés aux transactions en cours. Vous pouvez aussi combiner l’objet event.session avec d’autres objets d’événement, comme event.authentication ou event.request.

Vous pouvez ensuite utiliser l’objet api.session soit pour réinitialiser les dates d’expiration de la session existante, soit pour révoquer la session.

Pour en savoir plus sur ces objets, consultez :

• Event object: Découvrez l’objet Event de session et ses propriétés.
• API object: Découvrez l’objet API de session et ses méthodes.

​

Révoquer des sessions avec Actions

La méthode post-login api.session.revoke(reason, options) vous permet de réagir aux risques associés à une transaction. Cette méthode comprend une option qui vous permet de conserver les jetons d’actualisation liés à la transaction révoquée.

En plus de révoquer la session, la méthode déclenche aussi un initiateur de déconnexion OIDC back-channel session-revoked pour déconnecter les utilisateurs de toutes les applications liées à la session en cours et consigner un événement session_revoked dans les journaux du tenant.

Vous pouvez utiliser cette méthode pour :

• Invalider la transaction de la session en cours dans Auth0

• Rejeter la transaction en cours

• Révoquer tous les jetons d’actualisation associés à la session existante ayant une valeur session_id correspondante.

  • Il s’agit d’une option personnalisable; vous pouvez choisir de conserver les jetons d’actualisation au lieu de les révoquer. Cette opération s’exécute de façon asynchrone et devient cohérente à terme.

Si vous souhaitez utiliser la méthode api.session.revoke(reason,options), assurez-vous que la propriété event.session.id existe.

Contrairement à api.access.deny(), api.session.revoke() rejettera la transaction en cours et révoquera aussi la session; une authentification du premier facteur sera donc de nouveau requise.

​

Surveiller les événements de journal liés à la révocation

L’opération de révocation ajoute l’événement de journal suivant dans vos journaux du tenant :

Un code d’événement session_revoked indiquant qu’une session a été révoquée, avec l’attribut session_id qui y est associé.

​

Modifier les dates d’expiration des sessions avec Actions

Vous pouvez modifier les dates d’expiration des sessions à l’aide des méthodes post-login suivantes :

• api.session.setExpiresAt(absolute) vous permet de définir, pour une session donnée, une nouvelle date d’expiration absolue de la session (Require log in after).
• api.session.setIdleExpiresAt(idle) vous permet de définir, pour une session donnée, une nouvelle date d’expiration du délai d’inactivité.

Vous pouvez utiliser ces méthodes pour personnaliser dynamiquement la durée de vie de la session et les politiques d’inactivité en fonction de ce qui suit :

• l’organisation d’un utilisateur
• la connexion Auth0 d’un utilisateur
• l’appartenance d’un utilisateur à un groupe ou son profil
• l’évaluation du risque
• tout autre critère dynamique disponible pendant l’exécution de l’Action

Si vous voulez utiliser les méthodes api.session.setExpiresAt(absolute) et api.session.setIdleExpiresAt(idle), assurez-vous qu’une propriété de l’objet event.session existe, par exemple event.session.id.

La méthode api.session.setIdleExpiresAt(idle) définit le délai d’inactivité de la session pour l’interaction en cours. Si la méthode n’est pas appliquée de nouveau, les interactions réussies suivantes remplaceront le délai d’inactivité en fonction des paramètres de délai d’inactivité de la session.

​

Définir la persistance du témoin de session avec Actions

La méthode post-login api.session.setCookieMode(options) vous permet de modifier la persistance du témoin de session. Vous pouvez indiquer si un témoin de session est persistant ou non persistant.

Les sessions non persistantes (éphémères) renforcent la sécurité, car elles n’existent qu’en mémoire. Ces sessions sont effacées lorsqu’un navigateur ou une application est fermé, ce qui les rend idéales pour des processus sensibles, comme l’accès à partir d’un appareil non fiable ou les scénarios d’authentification renforcée.

Vous pouvez utiliser cette méthode pour :

• Imposer des sessions éphémères aux utilisateurs ayant des rôles à risque élevé ou appartenant à des groupes à risque élevé

• Exiger une nouvelle authentification lorsque le navigateur est fermé pour certains appareils ou certaines plages d’adresses IP

• Réduire la durée de la session dans des environnements non fiables ou partagés (p. ex., des ordinateurs publics)

Cette méthode accepte les paramètres suivants :

Propriété	Type	Description
persistent	string	La session est stockée dans un témoin persistant et demeure active après le redémarrage du navigateur, à moins d’être effacée manuellement.
non-persistent	string	La session est stockée uniquement en mémoire et est effacée lorsque le navigateur ou l’application est fermé.

La méthode api.session.setCookieMode() remplace le paramètre par défaut du tenant pour la session en cours.

Auth0 conserve ce paramètre de persistance pendant toute la session; il n’est pas nécessaire de le définir de nouveau dans de futurs flux d’authentification silencieuse.

La méthode api.session.setCookieMode() doit être utilisée dans une Action post-login. Si elle est utilisée dans un contexte où api.session n’est pas disponible, la requête échoue silencieusement.

Pour savoir comment configurer la persistance du témoin de session, consultez Configurer Keep Me Signed In à l’aide de Sessions.

​

Limitations

Les sessions émises avant la publication des méthodes d’API post-login api.session.setExpiresAt(absolute) et api.session.setIdleExpiresAt(idle) ne contiendront pas la propriété event.session suivante : last_interacted_at.

Les sessions émises avant la publication de la méthode d’API post-login api.session.revoke(reason, options) ne contiendront pas les propriétés event.session.device suivantes :

• initial_ip
• initial_asn
• initial_user_agent

Pour des raisons de sécurité, les délais d’expiration absolus et d’inactivité ne peuvent pas être définis au-delà des paramètres de session configurés dans les limites de durée de vie des sessions du tenant. Si vous tentez de définir une date qui dépasse ces limites, les méthodes d’API la mettront à jour jusqu’aux limites autorisées et consigneront un événement d’avertissement (w) dans les journaux du tenant.

​

Cas d’utilisation : Révoquer une session

Vous pouvez utiliser Actions pour configurer la détection des risques et révoquer les sessions à risque ainsi que les jetons d’actualisation qui y sont associés à l’aide de la méthode post-login api.session.revoke(reason, options) et de l’objet event.session.

​

Révoquer une session en raison d’une liaison au réseau ASN

Vous pouvez utiliser les propriétés de l’objet post-login, event.session.device.initial_asn et event.request.asn, pour lier les transactions de session à un réseau numéro de système autonome (ASN) précis pendant toute leur durée et exiger une nouvelle authentification si le réseau ASN change.

exports.onExecutePostLogin = async (event, api) => {
  const sessionInitialAsn = event.session?.device?.initial_asn;
  const sessionCurrentAsn = event.request.asn;

  // s'il existe une session et que l'ASN change
  if (
    sessionInitialAsn &&
    sessionCurrentAsn &&
    sessionInitialAsn != sessionCurrentAsn
  ) {
    api.session.revoke( "Invalid network change. Login again from a trusted network" )
  }
};

Dans cet exemple, une vérification est effectuée au début de l’Action afin de confirmer que les propriétés event.session.device.initial_asn et event.request.asn appartiennent toujours au même réseau ASN au cours de la transaction. Si cette vérification échoue, l’Action appelle  api.session.revoke() pour :

• Invalider la session
• Rejeter la transaction en cours
• Révoquer tous les jetons d’actualisation associés
• Exiger une réauthentification

​

Révoquer une session en raison d’une association à une adresse IP

Vous pouvez utiliser les propriétés de l’objet post-login event.session.device.initial_ip et event.request.ip pour vous assurer qu’une transaction de session utilise la même adresse IP pendant toute sa durée. Dans ce scénario, tout changement d’IP est considéré comme un risque, et l’utilisateur devra s’authentifier de nouveau.

exports.onExecutePostLogin = async (event, api) => {
  const sessionInitialIp = event.session?.device?.initial_ip;
  const sessionCurrentIp = event.request.ip;

  // s'il y a une session et que l'adresse IP change
  if (
    sessionInitialIp &&
    sessionCurrentIp &&
    sessionInitialIp != sessionCurrentIp
  ) {
    api.session.revoke("Invalid IP change")
  }
};

Dans cet exemple, une vérification est effectuée au début de l’Action pour s’assurer que les propriétés event.session.device.initial_ip et event.request.ip conservent la même adresse IP tout au long de la transaction. Si la vérification échoue, l’Action appelle ensuite  api.session.revoke() pour :

• Invalider la session
• Rejeter la transaction en cours
• Révoquer tous les jetons d’actualisation associés
• Exiger une réauthentification

​

Cas d’utilisation : Personnaliser les dates d’expiration d’une session

Vous pouvez utiliser Actions pour personnaliser les dates d’expiration absolue et d’inactivité d’une session. Plus précisément, vous pouvez configurer les dates d’expiration d’une transaction de session précise à l’aide des méthodes post-login api.session.setExpiresAt(absolute) et api.session.setIdleExpiresAt(idle), ainsi que de l’objet event.session.

​

Personnaliser le délai d’expiration absolu d’une session en fonction des connexions

Vous pouvez utiliser les propriétés suivantes de l’objet post-login pour définir une durée de validité pour la connexion utilisée afin d’authentifier un utilisateur.

• event.session.created_at
• event.session.expires_at

Et en utilisant la Management API d’Auth0 pour créer des métadonnées de connexion, event.connection.metadata.session_timeout définit un délai d’expiration propre à la connexion.

exports.onExecutePostLogin = async (event, api) => {
  const created = Date.parse(event.session?.created_at ?? "");

  // durée de vie de session souhaitée pour cette connexion en millisecondes, configurée en tant que métadonnée de connexion
  const connection_lifetime = event.connection?.metadata?.session_timeout;

  // si une durée de vie de session est définie pour la connexion, l'appliquer
  if (event.session?.id && connection_lifetime) {
    api.session.setExpiresAt(created + Number(connection_lifetime));
  }
};

Dans cet exemple, une vérification est effectuée au début de l’Action pour s’assurer qu’un session_timeout est défini dans la connexion actuelle. Le cas échéant, l’Action définit l’expiration de la session au moment où la session a été created, plus le connection_lifetime.

​

Personnaliser le délai d’inactivité de la session en fonction de l’organisation

Vous pouvez définir une variable current_time et, à l’aide de nouvelles métadonnées d’organisation appelées idle_session_timeout, configurer le délai d’inactivité voulu pour une organisation.

exports.onExecutePostLogin = async (event, api) => {
  // Les métadonnées de l'organisation sont configurées avec un délai d'inactivité plus court pour les sessions (en millisecondes)
  const idle_organization_lifetime =
    event.organization?.metadata?.idle_session_timeout;

  // Si l'organisation a un délai d'inactivité spécifique défini, appliquer le délai
  if (event.session?.id && idle_organization_lifetime) {
    const current_time = new Date().getTime();

    api.session.setIdleExpiresAt(
      current_time + Number(idle_organization_lifetime),
    );
  }
};

Dans cet exemple, si un délai d’inactivité précis est défini pour l’Organisation, l’Action règle le délai d’inactivité de la session de façon à ce qu’il soit égal à current_time plus idle_organization_lifetime .