> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> 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.

# Sessions avec Actions

L’utilisation des sessions avec [Actions](/docs/fr-ca/customize/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](/docs/fr-ca/manage-users/sessions/configure-session-lifetime-settings).

À 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](/docs/fr-ca/get-started/authentication-and-authorization-flow/authorization-code-flow), le flux implicite, le flux du code d’appareil, ainsi que <Tooltip tip="Security Assertion Markup Language (SAML) : protocole normalisé permettant à deux parties d’échanger des renseignements d’authentification sans mot de passe." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=SAML">SAML</Tooltip> et <Tooltip tip="Security Assertion Markup Language (SAML) : protocole normalisé permettant à deux parties d’échanger des renseignements d’authentification sans mot de passe." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=WS-Fed">WS-Fed</Tooltip>.

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](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-event-object): Découvrez l’objet Event de session et ses propriétés.
* [API object](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object): Découvrez l’objet API de session et ses méthodes.

<div id="revoke-sessions-with-actions">
  ## Révoquer des sessions avec Actions
</div>

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 <Tooltip tip="Refresh Token : jeton utilisé pour obtenir un nouveau jeton d’accès sans obliger les utilisateurs à se connecter de nouveau." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=refresh+tokens">jetons d’actualisation</Tooltip> 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](/docs/fr-ca/authenticate/login/logout/back-channel-logout/oidc-back-channel-logout-initiators) `session-revoked` pour déconnecter les utilisateurs de toutes les applications liées à la session en cours et consigner un événement [session\_revoked](/docs/fr-ca/deploy-monitor/logs/log-event-type-codes) 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](/docs/fr-ca/secure/tokens/refresh-tokens) 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.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

<div id="monitor-revoke-log-events">
  ### Surveiller les événements de journal liés à la révocation
</div>

L’opération de révocation ajoute l’événement de journal suivant dans vos [journaux du tenant](/docs/fr-ca/deploy-monitor/logs) :

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é.

<div id="change-sessions-expiry-dates-with-actions">
  ## Modifier les dates d’expiration des sessions avec Actions
</div>

Vous pouvez modifier les [dates d’expiration](/docs/fr-ca/manage-users/sessions/session-lifetime-limits) 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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

<div id="set-session-cookie-persistence-with-actions">
  ## Définir la persistance du témoin de session avec Actions
</div>

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é.                               |

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  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.
</Callout>

Pour savoir comment configurer la persistance du témoin de session, consultez [Configurer Keep Me Signed In à l’aide de Sessions](/docs/fr-ca/manage-users/sessions/configure-keep-me-signed-in-sessions).

<div id="limitations">
  ## Limitations
</div>

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](/docs/fr-ca/manage-users/sessions/configure-session-lifetime-settings) 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.

<div id="use-cases-revoke-a-session">
  ## Cas d’utilisation : Révoquer une session
</div>

Vous pouvez utiliser [Actions](/docs/fr-ca/customize/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`.

<div id="revoke-a-session-due-to-asn-network-binding">
  ### Révoquer une session en raison d’une liaison au réseau ASN
</div>

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)](https://www.arin.net/resources/guide/asn/) précis pendant toute leur durée et exiger une nouvelle authentification si le réseau ASN change.

```js lines theme={null}
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

<div id="revoke-a-session-due-to-an-ip-binding">
  ### Révoquer une session en raison d’une association à une adresse IP
</div>

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.

```js lines theme={null}
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

<div id="use-cases-customize-a-session-expiry-dates">
  ## Cas d’utilisation : Personnaliser les dates d’expiration d’une session
</div>

Vous pouvez utiliser [Actions](/docs/fr-ca/customize/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`.

<div id="customize-absolute-session-expiration-time-based-on-connections">
  ### Personnaliser le délai d’expiration absolu d’une session en fonction des connexions
</div>

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](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) 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.

```js lines theme={null}
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`.

<div id="customize-session-inactivity-timeout-based-on-the-organization">
  ### Personnaliser le délai d’inactivité de la session en fonction de l’organisation
</div>

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.

```js lines theme={null}
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` .
