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

# Back-Channel Logout OIDC

> Découvrez comment la Back-Channel Logout envoie un jeton de déconnexion de serveur à serveur à chaque partie utilisatrice lorsque la session SSO d’un utilisateur prend fin, afin que les applications puissent mettre fin à leurs propres sessions.

Auth0 prend en charge la [spécification OpenID Connect Back-Channel Logout 1.0](https://openid.net/specs/openid-connect-backchannel-1_0.html#Backchannel) dans tous les tenants associés à un abonnement Enterprise plan.

Cette spécification s’appuie sur l’ID de session (`sid`) inclus dans les <Tooltip tip="Jeton d’identification : justificatif destiné au client lui-même, plutôt qu’à l’accès à une ressource." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=ID+tokens">jetons ID</Tooltip> et sur les Logout Tokens pour coordonner la fermeture de session par communication de canal arrière. Des ID de session différents correspondent à des sessions distinctes d’un agent utilisateur ou d’un appareil dans votre tenant. Les Logout Tokens identifient l’utilisateur final et la session à déconnecter.

<div id="back-channel-communications">
  ## Communications par canal arrière
</div>

Pour utiliser Back-Channel Logout, une application doit exposer un URI de Back-Channel Logout, accessible à partir du serveur du tenant, où l’application s’attend à recevoir les requêtes contenant le Logout Token. Lorsqu’une application reçoit cette requête, elle doit effacer l’état de session local correspondant aux claims du token.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Pour que Back-Channel Logout fonctionne, les applications doivent être en mesure de recevoir des communications par canal arrière.
</Callout>

<div id="tokens-in-oidc-back-channel-logout-communications">
  ### Jetons dans les communications OIDC Back-Channel Logout
</div>

Les applications ne peuvent pas se fier aux <Tooltip tip="Cookie de session : entité qui, lorsqu’elle est présente, permet de considérer l’utilisateur comme authentifié." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=session+cookies">cookies de session</Tooltip> pour déterminer quelle session terminer lorsque les communications se font par le canal arrière. Le service s’appuie plutôt sur un identifiant de session partagé (`sid`) dans les jetons ID et Logout.

Lorsque les utilisateurs finaux s’authentifient avec succès auprès d’Auth0 au moment du login, le <Tooltip tip="Serveur d’autorisation : serveur centralisé qui contribue à définir les limites de l’accès d’un utilisateur. Par exemple, votre serveur d’autorisation peut contrôler les données, les tâches et les fonctionnalités accessibles à un utilisateur." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=authorization+server">serveur d’autorisation</Tooltip> émet des jetons d’accès et des jetons ID. Des jetons Logout sont générés lorsqu’une session est détruite, par exemple à la suite d’une action de logout ou d’une révocation de session. Les jetons ID et Logout contiennent tous deux les claims dont votre application a besoin pour prendre en charge le workflow Back-Channel Logout. Pour en savoir plus sur les claims, consultez [Claims de JSON Web Token](/docs/fr-ca/secure/tokens/json-web-tokens/json-web-token-claims).

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5jQ5HogFNeD9tqUGEJuJHE/663f1f52b285f7019fd1157f5a26caf0/2023-09-29_09-32-00.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=2b7fbbaf0b09b46cf3f64b42509b7bc7" alt="Workflow du Back-Channel Logout" width="849" height="324" data-path="docs/images/cdy7uua7fh8z/5jQ5HogFNeD9tqUGEJuJHE/663f1f52b285f7019fd1157f5a26caf0/2023-09-29_09-32-00.png" />
</Frame>

1. Login - Pendant l’authentification de l’utilisateur, le tenant Auth0 ajoute le `sid` au jeton ID.
2. Login - L’application stocke l’identifiant de session reçu dans son propre magasin de sessions et l’associe à la session propre à l’application.
3. Logout - L’IdP appelle l’URL de callback de logout préenregistrée et envoie le jeton Logout à cet endpoint. Le jeton contient le `user_id` (`sub`) et le `sid`, ainsi que d’autres paramètres.
4. Logout - Le backend de l’application doit valider le jeton Logout conformément à la spécification OIDC et extraire le `sid`. Le backend peut ensuite utiliser ce jeton pour trouver la session associée à cet identifiant et y mettre fin au besoin.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  La réponse attendue est `HTTP 200` pour un logout réussi. Si vous recevez un code `HTTP 400`, indiquant une request incorrecte ou mal interprétée, vous pouvez utiliser nos conseils de dépannage. Pour en savoir plus, consultez [Configurer Back-Channel Logout](/docs/fr-ca/authenticate/login/logout/back-channel-logout/configure-back-channel-logout).
</Callout>

<div id="how-it-works">
  ### Fonctionnement
</div>

Cet exemple de cas d’utilisation montre comment Back-Channel Logout fonctionne avec plus d’une application :

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/54mbNobsvLec0A2tz0DXUG/99ce79c9e93ffe526472d6250373778c/2023-06-20_09-39-12.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=0af402480a71445e216e9cc5427d3aca" alt="Cas d’utilisation de la déconnexion canal arrière pour plusieurs applications" width="2476" height="2562" data-path="docs/images/cdy7uua7fh8z/54mbNobsvLec0A2tz0DXUG/99ce79c9e93ffe526472d6250373778c/2023-06-20_09-39-12.png" />
</Frame>

1. Lors de la configuration de l’application, Application A enregistre un URI de Back-Channel Logout auprès d’Auth0.
2. Lors de la configuration de l’application, Application B enregistre un URI de Back-Channel Logout auprès d’Auth0.

   <Callout icon="file-lines" color="#0EA5E9" iconType="regular">
     Les URL de déconnexion OIDC Back-Channel doivent :

     * Être accessibles depuis l’IdP
     * Utiliser des endpoints avec chiffrement TLS
     * [Valider les jetons de déconnexion](https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation)
   </Callout>
3. Lors du login de l’utilisateur final, un utilisateur s’authentifie auprès d’Auth0 pour accéder à Application A.
4. Auth0 envoie un ID token avec `sid` à Application A. Pour en savoir plus, consultez [Structure des ID token](/docs/fr-ca/secure/tokens/id-tokens/id-token-structure).
5. L’utilisateur s’authentifie auprès d’Auth0 pour accéder à Application B.
6. Auth0 envoie un ID token avec le même `sid` à Application B. Votre application doit stocker les informations de session.
7. Lors de la déconnexion, Application A ou d’autres entités lancent la déconnexion sur le front-channel.
8. Auth0 met fin à la couche de session Auth0 au moyen du cookie de session.
9. Auth0 appelle l’URI de Back-Channel Logout d’Application A et envoie le Logout Token.
10. Application A valide le Logout Token et met fin à la session.
11. Auth0 appelle l’URI de Back-Channel Logout d’Application B et envoie le Logout Token.
12. Application B valide le Logout Token et met fin à la session.

Les requêtes de déconnexion canal arrière sont placées dans une file d’attente asynchrone et traitées aussi rapidement que possible. En situation de forte charge, il peut y avoir un léger délai avant l’exécution de la demande de déconnexion; concevez donc vos applications de façon à gérer cette cohérence à terme.

<div id="sample-token">
  #### Exemple de jeton
</div>

Votre application doit être en mesure d'analyser et de valider les <Tooltip tip="JSON Web Token (JWT) : format standard des ID Tokens (et souvent des Access Tokens) utilisé pour représenter de manière sécurisée des claims entre deux parties." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=JWTs">JWTs</Tooltip> afin de les utiliser comme Logout Tokens avec Auth0. Pour en savoir plus, consultez [Valider les JSON Web Tokens](/docs/fr-ca/secure/tokens/json-web-tokens/validate-json-web-tokens).

Une fois que votre application a validé et décodé votre jeton, son contenu ressemble à l'exemple ci-dessous :

```json JSON lines theme={null}
{
  "iss": "https://artex-dev.eu.auth0.com/",
  "sub": "auth0|602e93db83fa6f00749a23e6",
  "aud": "TuhNLv7ulXD3RfyLlSMbOvszzwJJFPpO",
  "iat": 1698160928,
  "exp": 1698161048,
  "jti": "44a91215-dfb4-4dfe-a1eb-fcafa911deba",
  "events": {
    "http://schemas.openid.net/event/backchannel-logout": {}
  },
  "trace_id": "81b336a94a4a5707",
  "sid": "375UIp_ID5mCTClIeBEHpXfGwq51tF_L"
}
```

<div id="auth0-sdks">
  ### Auth0 SDKs
</div>

Un exemple complet ainsi que le code prêt pour la production se trouvent déjà dans la section **Back-Channel Logout Example** de notre [SDK express-openid-connect](https://github.com/auth0/express-openid-connect/blob/master/EXAMPLES.md#11-back-channel-logout).

<div id="implementation-examples">
  ## Exemples de mise en œuvre
</div>

<div id="session-storage">
  ### Stockage des sessions
</div>

L’exemple de stockage des sessions est créé en Node (Express) et s’appuie sur l’[exemple d’application web Express OpenID Connect](https://github.com/auth0-samples/auth0-express-webapp-sample/tree/master/01-Login).

Dans l’onglet Sessions de votre application, exposez la route que vous avez configurée pour recevoir le Logout Token. Validez le token et mettez fin à la session de l’utilisateur.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Cet exemple utilise un magasin de sessions en mémoire à des fins de démonstration.
</Callout>

```javascript routes/index.js lines expandable theme={null}
const express = require('express');
const router = express.Router();
const { requiresAuth } = require('express-openid-connect');

// middleware pour valider le jeton de déconnexion
const requiresValidLogoutToken = require('../middlewares/validateLogoutToken');

// fonction utilitaire pour supprimer les sessions utilisateur
const deleteUserSessions = require('../utils/sessions');

// nouvelle route pour recevoir les jetons de déconnexion par canal arrière
// doit être configurée dans l'onglet Application -> Sessions
// dans le Dashboard de gestion Auth0
router.post(
  '/backchannel-logout',
  requiresValidLogoutToken,
  function (req, res, next) {
    // à ce stade, le jeton de déconnexion est valide, vérifié par le middleware requiresValidLogoutToken
    // vous pouvez y accéder depuis l'objet de requête : req.logoutToken

    // supprimer la session utilisateur pour déconnecter l'utilisateur
    deleteUserSessions(
      req.app.locals.sessionStore,
      req.logoutToken.sub,
      req.logoutToken.sid
    );

    res.sendStatus(200);
  }
);

router.get('/', function (req, res, next) {
  res.render('index', {
    title: 'Auth0 Webapp sample Nodejs',
    isAuthenticated: req.oidc.isAuthenticated(),
    headline: process.env.APP_NAME,
    backgroundColor: process.env.BACKGROUND_COLOR,
    baseURL: process.env.BASE_URL,
  });
});

router.get('/profile', requiresAuth(), function (req, res, next) {
  res.render('profile', {
    userProfile: JSON.stringify(req.oidc.user, null, 2),
    title: 'Profile page',
    headline: process.env.APP_NAME,
    backgroundColor: process.env.BACKGROUND_COLOR,
    baseURL: process.env.BASE_URL,
  });
});

module.exports = router;
```

```javascript middlewares/validateLogoutToken.js lines expandable theme={null}
// Ce middleware valide le jeton de déconnexion tel que défini ici :
// https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation

const jose = require('jose');

async function requiresValidLogoutToken(req, res, next) {

  // récupérer l'ensemble de clés distant pour la vérification du jeton
  const JWKS = jose.createRemoteJWKSet(
    new URL(process.env.ISSUER_BASE_URL + '/.well-known/jwks.json')
  );

  const logoutToken = req.body.logout_token;

  if (!logoutToken) {
    res.status(400).send('Need logout token');
  }

  try {
    const { payload, protectedHeader } = await jose.jwtVerify(
      logoutToken,
      JWKS,
      {
        issuer: process.env.ISSUER_BASE_URL + '/',
        audience: process.env.CLIENT_ID,
        typ: 'JWT',
        maxTokenAge: '2 minutes',
      }
    );

    // Vérifier que le jeton de déconnexion contient une revendication sub, une revendication sid, ou les deux
    if (!payload.sub && !payload.sid) {
      res
        .status(400)
        .send(
          'Error: Logout token must contain either sub claim or sid claim, or both'
        );
    }

    // Vérifier que le jeton de déconnexion contient une revendication events
    // dont la valeur est un objet JSON contenant le nom de membre http://schemas.openid.net/event/backchannel-logout
    if (!payload.events['http://schemas.openid.net/event/backchannel-logout']) {
      res
        .status(400)
        .send(
          'Error: Logout token must contain events claim with correct schema'
        );
    }

    // Vérifier que le jeton de déconnexion ne contient pas de revendication nonce.
    if (payload.nonce) {
      res
        .status(400)
        .send('Error: Logout token must not contain a nonce claim');
    }

    // associer le jeton de déconnexion valide à l'objet de requête
    req.logoutToken = payload;

    // le jeton est valide, appeler le middleware suivant
    next();
  } catch (error) {
    res.status(400).send(`Error:  ${error.message}`);
  }
}

module.exports = requiresValidLogoutToken;
```

<div id="logout-token-store">
  ### Magasin de Logout Token
</div>

Une approche courante de stockage des jetons consiste à définir un magasin de déconnexion comme solution de rechange au modèle de magasin de sessions. Votre ou vos applications conservent une collection de Logout Tokens dans la couche de persistance.

Chaque fois que l’application veut vérifier son état d’authentification, elle interroge le magasin de Logout Token pour déterminer si sa session est toujours active. Le magasin de déconnexion purge régulièrement les données obsolètes afin de ne conserver que l’information nécessaire.

<Frame>
  <img src="https://mintcdn.com/translations/Dcx0M11uuptU53TX/docs/images/cdy7uua7fh8z/2zTtcie1d0fjiSuxZ4huyV/dbcf45fb68a045bd1b1918315f8025f7/image__21_.png?fit=max&auto=format&n=Dcx0M11uuptU53TX&q=85&s=a5dcbbfe2b72204119f6f3447334799c" alt="Magasin de Logout Token" width="2978" height="1144" data-path="docs/images/cdy7uua7fh8z/2zTtcie1d0fjiSuxZ4huyV/dbcf45fb68a045bd1b1918315f8025f7/image__21_.png" />
</Frame>

<div id="security-considerations">
  ## Considérations de sécurité
</div>

Les jetons de Back-Channel Logout sont transmis sur Internet; par conséquent, les points de terminaison de rappel qui les reçoivent doivent respecter les meilleures pratiques afin d'assurer un fonctionnement fiable et sécuritaire. La liste de recommandations ci-dessous n'est pas exhaustive, et vous devez toujours tenir compte des situations de déploiement et d'exploitation propres à votre contexte afin de vous y adapter. Dans la liste ci-dessous, toutes les applications qui traitent les jetons de Back-Channel Logout sont désignées par « applications ».

* Les applications doivent pouvoir stocker l'ID de session (claim `sid`) reçu lors de la connexion de l'utilisateur afin de le récupérer plus tard à la réception d'un jeton de Back-Channel Logout.
* Les applications doivent vérifier tous les jetons reçus conformément aux [meilleures pratiques de validation des JWT](/docs/fr-ca/secure/tokens/json-web-tokens/validate-json-web-tokens).
* Les applications doivent accepter uniquement les jetons émis par des tenants de confiance. Un acteur malveillant peut tenter d'envoyer des jetons émis par d'autres tenants Auth0; de telles tentatives doivent être rejetées.
* Les applications doivent accepter des jetons uniquement lorsqu'ils contiennent une valeur `sid` (ID de session) que l'application reconnaît. Les jetons contenant un ID de session invalide (qu'il soit expiré ou non reconnu) doivent être rejetés.
* Les applications doivent exposer les points de terminaison de rappel uniquement au moyen de TLS. Les canaux de communication non chiffrés ne sont pas autorisés.
* Il est recommandé que les applications acceptent des requêtes uniquement à partir de la liste publiée des [adresses IP sortantes](/docs/fr-ca/secure/security-guidance/data-security/allowlist).
* Il est recommandé que les applications suivent les meilleures pratiques générales en matière de surveillance, de journalisation et de limitation du débit; toutefois, les détails à ce sujet dépassent la portée du présent document.
* Il est recommandé que les applications suppriment régulièrement les sessions obsolètes ou expirées.
* Toute modification de l'adresse du point de terminaison doit être synchronisée avec la configuration du tenant afin de garantir que les jetons de Logout sont toujours remis à la bonne URL de rappel de Back-Channel Logout.