Sessions avec actions

L’utilisation des sessions avec des Actions vous permet de configurer des capacités de détection et de réponse aux risques post-authentification afin de protéger vos applications et vos utilisateurs contre le détournement de session. Vous pouvez également personnaliser dynamiquement les limites de durée de vie de la session.

Pour faciliter cela, les Actions post-connexion comportent deux objets clés :

• event.session : Fournit des renseignements pertinents, y compris les données id, created_at, expires_at, idle_expires_at et updated_at, clients, authentication_at et des données liées à device, comme ASN, IP et User_agent.

• api.session: Vous permet de gérer les sessions existantes en révoquant les sessions ou en modifiant les dates d’expiration expiry.

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

Vous pouvez utiliser l’objet event.session pour examiner l’horodatage des dernières interactions et évaluer les risques associés aux transactions en cours. Vous pouvez également combiner l’objet event.session avec d’autres objets d’événement, tels que event.authentication ou event.request.

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

Pour en savoir plus sur ces objets, consultez :

• Objet Event : En savoir plus sur l’objet de session Event et ses propriétés

• Objet API : En savoir plus sur l’objet de session API et ses méthodes.

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

En plus de révoquer la session, la méthode lancera également un initiateur de déconnexion de canal d’appui OIDCsession-revoked pour déconnecter les utilisateurs de toutes les applications liées à la session en cours et enregistrer un événement session_revoked dans les journaux du locataire.

Vous pouvez utiliser cette méthode pour :

• invalider la transaction de la session en cours dans Auth0;

• refuser la transaction en cours;

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

  • Il s’agit d’une option personnalisable, vous pouvez choisir de conserver les jetons d’actualisation plutôt que de les révoquer. Cette opération s’exécute de manière asynchrone et devient finalement cohérente.

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

Un code d’événement session_revoked indiquant une session révoquée avec son attribut session_id associé.

Vous pouvez modifier les dates d’expiration de la session avec les méthodes de post-connexion suivantes :

• api.session.setExpiresAt(absolute) vous permet de définir une nouvelle date d’expiration de session absolue (Nécessiter la connexion après) pour une session spécifiée.

• api.session.setIdleExpiresAt(idle) vous permet de définir une nouvelle date d’expiration du délai d’inactivité pour une session spécifiée.

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

• L’organisation d’un utilisateur

• La connexion Auth0 d’un utilisateur

• L’adhésion ou le profil de groupe d’un utilisateur spécifique

• L’évaluation des risques

• Tout autre critère dynamique disponible lors de l’exécution de l’Action

Les sessions émises avant la publication des méthodes API post-connexion 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 API post-connexion 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’inactivité et absolu ne peuvent pas être définis au-dessus des paramètres de la session définis dans les limites de la durée de vie de la session pour le locataire. Si vous tentez de définir une date au-dessus des limites de la durée de vie, les méthodes de l’API la mettront à jour en fonction des limites de durée de vie et enregistreront un événement d’avertissement (w) dans les journaux du locataire.

Vous pouvez utiliser les Actions pour configurer les détections de risques et révoquer les sessions risquées et leurs jetons d’actualisation associés avec la méthode post-connexion api.session.revoke(reason, options) et l’objet event.session.

Vous pouvez utiliser les propriétés de l’objet post-connexion, event.session.device.initial_asn et event.request.asn pour lier les transactions de session à un réseau autonomous system number (ASN) spécifique pour leur durée et nécessiter une réauthentification si le réseau ASN change.

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

  // if there is a session and the ASN changes
  if (
    sessionInitialAsn &&
    sessionCurrentAsn &&
    sessionInitialAsn != sessionCurrentAsn
  ) {
    api.session.revoke( "Invalid network change. Login again from a trusted network" )
  }
};

Dans cet exemple, une vérification se produit au début de l’Action pour vérifier si les propriétés event.session.device.initial_asn et event.request.asn restent dans le même réseau ASN pendant la transaction. Si cette vérification échoue, l’Action appelle  api.session.revoke() pour :

• invalider la session;

• refuser la transaction en cours;

• révoquer tous ses jetons d’actualisation associés;

• inviter à la réauthentification.

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

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

  // if there is a session and the IP changes
  if (
    sessionInitialIp &&
    sessionCurrentIp &&
    sessionInitialIp != sessionCurrentIp
  ) {
    api.session.revoke("Invalid IP change")
  }
};

Dans cet exemple, une vérification se produit au début de l’Action pour vérifier si les propriétés event.session.device.initial_ip et event.request.ip conservent la même adresse IP pendant la transaction. Si la vérification échoue, l’Action appelle alors api.session.revoke() pour :

• invalider la session;

• refuser la transaction en cours;

• révoquer tous ses jetons d’actualisation associés;

• inviter à la réauthentification.

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

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

• event.session.created_at

• event.session.expires_at

Et vous pouvez utiliser la Management API d‘Auth0 pour créer une métadonnée de connexion, event.connection.metadata.session_timeout define un délai d’expiration de connexion spécifique.

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

  // desired session lifetime for this connection in milliseconds, configured as connection metadata
  const connection_lifetime = event.connection?.metadata?.session_timeout;

  // if there is a session lifetime defined for the connection, set it
  if (event.session?.id && connection_lifetime) {
    api.session.setExpiresAt(created + Number(connection_lifetime));
  }
};

Dans cet exemple, une vérification se produit au début de l’Action pour vérifier s’il y a une valeur session_timeout définie dans la connexion actuelle. Dans ce cas, l’Action définit l’expiration de la session comme étant égale à la date de création created de la session, plus le paramètre connection_lifetime.

Vous pouvez définir une variable current_time et utiliser une nouvelle métadonnée d’Organization appelée idle_session_timeout pour définir le délai d’inactivité souhaité pour une organization.

exports.onExecutePostLogin = async (event, api) => {
  // The Organization metadata is configured with a shorter idle timeout for sessions (in milliseconds)
  const idle_organization_lifetime =
    event.organization?.metadata?.idle_session_timeout;

  // If the organization has an specific idle timeout defined, set the timeout
  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é spécifique est défini pour l’Organization, l’Action définit le délai d’inactivité de la session comme étant égal à la valeur current_time plus la valeur idle_organization_lifetime.