> ## 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. # Configurer l’expiration des sessions pour les connexions Enterprise (IPSIE) > Découvrez comment appliquer l’expiration des sessions de l’Identity Provider en amont à l’aide de la revendication `session_expiry` d’IPSIE pour les connexions Enterprise Okta et OIDC. L’expiration des sessions est prise en charge pour les connexions Enterprise Okta et OIDC, mais n’est pas offerte pour les connexions Microsoft Entra ID (Azure AD). Microsoft n’inclut pas la revendication `session_expiry` dans les jetons Entra ID. Auth0 prend en charge la revendication `session_expiry` conformément à la [norme Interoperability Profile for Secure Identity in the Enterprise (IPSIE)](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html) pour les connexions Enterprise Okta et OIDC. Lorsqu’elle est activée, Auth0 récupère la revendication `session_expiry` (représentée en secondes sous forme d’horodatage Unix) auprès de l’Identity Provider (IdP) en amont et l’inclut dans le jeton d’ID émis à votre application. Auth0 traite la revendication `session_expiry` et synchronise la session Auth0 locale avec le cycle de vie de la session de l’IdP en amont. Ainsi, lorsqu’une session utilisateur expire auprès de l’IdP Enterprise, la session Auth0 de l’utilisateur prend également fin. Le client est responsable du traitement de la revendication `session_expiry` reçue ainsi que de la fermeture et de la gestion des sessions utilisateur dans ses applications. Avant d’activer l’application de l’expiration des sessions : * Vous devez disposer d’une connexion Enterprise [Okta](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/okta/express-configuration) ou [OIDC](/docs/fr-ca/authenticate/identity-providers/enterprise-identity-providers/oidc). * L’Identity Provider en amont doit émettre une revendication `session_expiry` dans son jeton d’ID.
## Fonctionnement
Lorsqu’un utilisateur s’authentifie au moyen d’une connexion Enterprise pour laquelle `session_expiry` est activé, Auth0 : 1. Récupère la revendication `session_expiry` du jeton d’ID de l’IdP en amont. 2. Calcule l’expiration de la session en évaluant certains paramètres et définit l’expiration finale de la session Auth0 à la valeur minimale (la plus proche) parmi les facteurs suivants : * La revendication `session_expiry` de l’IdP : l’horodatage absolu figurant dans un jeton d’ID de l’Identity Provider en amont. * Le paramètre d’expiration absolue par défaut de votre tenant Auth0 : la limite de durée de vie de session que vous configurez dans Auth0 Dashboard ou Management API. Pour en savoir plus, consultez [Configurer les paramètres de durée de vie des sessions](/docs/fr-ca/manage-users/sessions/configure-session-lifetime-settings). * Auth0 Actions \[`setExpiresAt`] : tout horodatage d’expiration personnalisé défini par programmation pendant la transaction de connexion à l’aide de la méthode [`api.session.setExpiresAt()`](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object#api-session-setexpiresat-absolute) de l’Action Post Login. 3. Utilise une Action Post Login que vous configurez lors de l’activation pour transmettre à votre application l’expiration finale de la session, telle qu’évaluée, en l’injectant sous forme de [revendication personnalisée](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object#api-idtoken-setcustomclaim-key-value) dans le jeton d’ID émis par Auth0. La revendication `session_expiry` est un [horodatage UNIX](https://en.wikipedia.org/wiki/Unix_time) en secondes qui représente la limite d’expiration absolue de la session de l’utilisateur : ```json theme={null} { "iss": "https://YOUR_DOMAIN.auth0.com/", "aud": "YOUR_CLIENT_ID", "sub": "oidc|username@domain.com", "iat": 1748534400, "exp": 1748538000, "session_expiry": 1748566800 } ``` | Revendication | Ce qu’elle représente | Portée | | ---------------- | ---------------------------------------------------- | ------------------- | | `exp` | Durée de vie du jeton d’ID (généralement en minutes) | Validation du jeton | | `session_expiry` | Expiration absolue (secondes) | Gestion de session | La revendication `session_expiry` ne remplace pas `exp`. La valeur `exp` du jeton d’ID demeure de courte durée et inchangée. `session_expiry` est une limite au niveau de la session incluse parmi les revendications du jeton. **`session_expiry` est fixé lors de la connexion.** Il est défini une seule fois lorsque l’utilisateur s’authentifie et n’est pas mis à jour lors de l’actualisation des jetons. Un utilisateur déjà connecté avant l’activation de cette fonctionnalité n’aura pas `session_expiry` dans sa session existante; la revendication n’apparaît qu’après sa prochaine connexion. Cette fonctionnalité concerne uniquement l’expiration planifiée des sessions. Pour la révocation de session en temps réel, par exemple lorsqu’un utilisateur est retiré en cours de session, nous vous recommandons d’utiliser [Back-Channel Logout](/docs/fr-ca/authenticate/login/logout/back-channel-logout).
## Activer l’application de l’expiration des sessions
Configurez l’application de l’expiration des sessions pour votre connexion Enterprise à l’aide du Auth0 Dashboard ou de la Management API. 1. Dans le Auth0 Dashboard, accédez à [Auth0 Dashboard > Authentication > Enterprise](https://manage.auth0.com/#/connections/enterprise). 2. Repérez la connexion Enterprise Okta ou OpenID Connect, puis sélectionnez **Browse**. 3. Choisissez la connexion à configurer. 4. Sous Settings, activez **Use ID Token for Session Expiry**. 5. Sélectionnez **Save**. Pour utiliser la Management API, vous avez besoin d’un [jeton d’accès de la Management API](/docs/fr-ca/secure/tokens/access-tokens/management-api-access-tokens) doté du scope `update:connections`. Effectuez une requête `PATCH` vers l’endpoint [Update a connection](https://auth0.com/docs/api/management/v2/connections/patch-connections-by-id) : ```http theme={null} PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID Content-Type: application/json Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN { "options": { "id_token_session_expiry_supported": true } } ``` Remplacez les valeurs de l’espace réservé : * **`YOUR_DOMAIN`** : Le domaine de votre tenant Auth0. Exemple : `travel0.us.auth0.com`. * **`YOUR_CONNECTION_ID`** : L’ID de votre connexion Enterprise Okta ou OIDC. * **`YOUR_MANAGEMENT_API_TOKEN`** : Un jeton de la Management API doté du scope `update:connections`. Si vous effectuez une requête `PATCH` sur le paramètre `options`, l’objet `options` entier est remplacé. Veillez à inclure toutes les propriétés existantes lorsque vous effectuez une requête `PATCH` sur `options`.
## Transmettre l’expiration de session à votre application
Auth0 utilise l’expiration de session calculée pour gérer sa propre couche de session, mais vos applications en aval peuvent aussi avoir besoin de connaître cette heure d’expiration absolue afin d’appliquer des limites de session locales. Configurez une Action Post Login pour ajouter l’expiration de session finale calculée à un jeton d’ID émis par Auth0 et transmettre ce jeton à votre application. 1. Dans Auth0 Dashboard, accédez à [**Auth0 Dashboard > Actions > Library**](https://manage.auth0.com/#/actions/library), puis sélectionnez **Build Custom Action**. 2. Saisissez un nom pour l’Action, sélectionnez **Login / Post Login** comme déclencheur, puis sélectionnez **Create**. 3. Ajoutez le code suivant à votre Action : ```javascript theme={null} exports.onExecutePostLogin = async (event, api) => { // Vérifiez si une expiration de session a été établie if (event.session?.expires_at) { // Convertissez la chaîne de date ISO en objet Date const exp_date = new Date(event.session.expires_at); // Définissez la claim personnalisée session_expiry sous forme d’horodatage Unix (secondes) api.idToken.setCustomClaim('session_expiry', Math.floor((exp_date.getTime()) / 1000)); } }; ``` 4. Dans le panneau Test, sélectionnez **Run** et examinez les résultats. 5. Sélectionnez **Deploy**. 6. Accédez à [**Actions > Triggers**](https://manage.auth0.com/#/actions/triggers), puis sélectionnez **Post-Login**. 7. Repérez votre Action et faites-la glisser dans le flux Login. Sélectionnez **Apply**. La configuration de l’Action au moyen de la Management API nécessite trois étapes : créer l’Action, la déployer, puis l’associer au déclencheur Login. Vous avez besoin d’un [jeton d’accès à la Management API](/docs/fr-ca/secure/tokens/access-tokens/management-api-access-tokens) avec les scopes `create:actions`, `read:actions` et `update:actions`. ### Créer l’Action 1. Effectuez une requête `POST` vers le endpoint [Create an action](https://auth0.com/docs/api/management/v2/actions/post-action) : ```http theme={null} POST https://YOUR_DOMAIN/api/v2/actions/actions Content-Type: application/json Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN { "name": "Set session_expiry claim", "supported_triggers": [ { "id": "post-login" } ], "code": "exports.onExecutePostLogin = async (event, api) => {\n if (event.session?.expires_at) {\n const exp_date = new Date(event.session.expires_at);\n api.idToken.setCustomClaim('session_expiry', Math.floor((exp_date.getTime()) / 1000));\n }\n};" } ``` Prenez note de la valeur `id` dans la réponse, car vous en aurez besoin aux étapes suivantes. ### Déployer l’Action 1. Effectuez une requête `POST` vers le endpoint [Deploy an action](https://auth0.com/docs/api/management/v2/actions/post-deploy-action) : ```http theme={null} POST https://YOUR_DOMAIN/api/v2/actions/actions/YOUR_ACTION_ID/deploy Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN ``` ### Associer l’Action au déclencheur Login 1. Effectuez une requête `PATCH` vers le endpoint [Update trigger bindings](https://auth0.com/docs/api/management/v2/actions/patch-bindings) : ```http theme={null} PATCH https://YOUR_DOMAIN/api/v2/actions/triggers/post-login/bindings Content-Type: application/json Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN { "bindings": [ { "ref": { "type": "action_id", "value": "YOUR_ACTION_ID" }, "display_name": "Set session_expiry claim" } ] } ``` La requête `PATCH /api/v2/actions/triggers/post-login/bindings` remplace toutes les associations existantes. Pour conserver les Actions déjà présentes dans votre flux Login, récupérez d’abord vos associations actuelles avec `GET /api/v2/actions/triggers/post-login/bindings`, puis incluez-les avec la nouvelle association dans votre requête `PATCH`. Remplacez les valeurs de l’espace réservé : * **`YOUR_DOMAIN`** : Le domaine de votre tenant Auth0. Exemple : `travel0.us.auth0.com`. * **`YOUR_MANAGEMENT_API_TOKEN`** : Un jeton de la Management API avec les scopes `create:actions`, `read:actions` et `update:actions`. * **`YOUR_ACTION_ID`** : L’`id` renvoyé dans la réponse Create Action.
## Utiliser l’expiration de session avec les SDK Auth0
Si vous utilisez les [SDK Auth0](/docs/fr-ca/libraries) et avez configuré l’Action Post Login décrite ci-dessus, l’expiration de session est appliquée automatiquement. Le SDK lit `session_expiry` dans le jeton d’ID au moment de la connexion, l’enregistre avec la session et considère celle-ci comme expirée dès que l’heure actuelle atteint ou dépasse `session_expiry` : | Type de SDK | Application de l’expiration | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | **Application Web classique** (Next.js, Express, Python) | Le middleware efface la session et redirige avec `prompt=login` ; `getAccessToken()` génère `SessionExpiredError` | | **Application monopage** (React, Angular, Vue) | `getTokenSilently()` / `getAccessTokenSilently()` échoue et déclenche une nouvelle connexion avec `prompt=login` | | **Mobile** (iOS/Swift, Android/Kotlin) | `CredentialsManager.credentials()` renvoie `noCredentials`, et le processus de connexion existant de l’application gère la réauthentification | L’Action Post Login est nécessaire pour injecter le claim `session_expiry` dans le jeton d’ID. Une fois défini, lorsque la session expire, le SDK se comporte comme pour toute autre expiration de session : l’utilisateur est redirigé vers la connexion. Aucune gestion d’erreur supplémentaire n’est requise.
## Ajoutez des valeurs d’expiration de session à votre application
Vous pouvez éventuellement ajouter des valeurs d’expiration de session à votre application. Par exemple, votre application peut lire `session_expiry` pour avertir les utilisateurs que leur session arrive à expiration, ou vous pouvez associer la durée de vie de la session de votre application à celle de l’IdP en amont. ```javascript theme={null} const claims = await auth0.getIdTokenClaims(); const sessionExpiresAt = claims?.session_expiry; // secondes Unix const remainingSeconds = sessionExpiresAt - Math.floor(Date.now() / 1000); ``` ```javascript theme={null} const session = await auth0.getSession(); const sessionExpiresAt = session?.sessionExpiresAt; // champ de niveau supérieur, secondes Unix const remainingSeconds = (sessionExpiresAt ?? Infinity) - Math.floor(Date.now() / 1000); ``` ```swift theme={null} credentialsManager.credentials { result in switch result { case .success(let credentials): let sessionExpiresAt = credentials.idToken?.session_expiry // secondes Unix case .failure: startLogin() } } ``` N’enregistrez pas la valeur `session_expiry` dans un espace de stockage à long terme, comme un cookie ou `localStorage`, sans la valider de nouveau à chaque lecture. Cette valeur n’a de sens que par rapport à l’heure actuelle.
## Vérifier dans les journaux du tenant
Après avoir activé l’application de l’expiration des sessions, vérifiez qu’elle fonctionne en consultant les [journaux du tenant](/docs/fr-ca/deploy-monitor/logs). Accédez à [**Auth0 Dashboard > Monitoring > Logs**](https://manage.auth0.com/#/logs) et recherchez un événement de connexion réussie (`s`) pour un utilisateur qui s’authentifie au moyen de la connexion Enterprise configurée. Lorsque la valeur `session_expiry` de l’IdP en amont est inférieure ou égale à la durée de vie absolue des sessions configurée pour votre tenant, l’entrée de journal inclut le champ `idp_session_expiry` (un horodatage Unix en secondes) : ```json theme={null} { "type": "s", "description": "Success Login", "details": { "idp_session_expiry": 1782472241 } } ``` Si l’IdP n’a pas envoyé de claim `session_expiry` et que vous activez cette fonctionnalité, la connexion échoue et affiche le message d’erreur suivant : `The upstream Identity Provider did not return a session_expiry claim`.
## Désactiver l’application de l’expiration de la session
1. Dans Auth0 Dashboard, accédez à [**Authentication > Enterprise**](https://manage.auth0.com/#/connections/enterprise). 2. Sélectionnez la connexion à configurer. 3. Sélectionnez l’onglet **Settings**. 4. Désactivez **Use ID Token for Session Expiry**. 5. Sélectionnez **Save**. Dans vos options de connexion, définissez `id_token_session_expiry_supported` à `false` : ```http theme={null} PATCH https://YOUR_DOMAIN/api/v2/connections/YOUR_CONNECTION_ID Content-Type: application/json Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN { "options": { "id_token_session_expiry_supported": false } } ```
## En savoir plus
* [Cycle de vie des sessions](/docs/fr-ca/manage-users/sessions/session-lifecycle) * [Configurer la durée de vie des sessions](/docs/fr-ca/manage-users/sessions/configure-session-lifetime) * [Sessions avec les Actions](/docs/fr-ca/manage-users/sessions/manage-sessions-actions) * [Back-Channel Logout](/docs/fr-ca/authenticate/login/logout/back-channel-logout) * [Profil OpenID Connect IPSIE SL1](https://openid.net/specs/ipsie-openid-connect-sl1-profile-1_0.html)