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 dans tous les tenants associés à un abonnement Enterprise plan.

Cette spécification s’appuie sur l’ID de session (sid) inclus dans les jetons ID 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.

​

Communications par canal arrière

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.

Pour que Back-Channel Logout fonctionne, les applications doivent être en mesure de recevoir des communications par canal arrière.

​

Jetons dans les communications OIDC Back-Channel Logout

Les applications ne peuvent pas se fier aux cookies de session 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 serveur d’autorisation é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.

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.

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.

​

Fonctionnement

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

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.

   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

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.

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.

​

Exemple de jeton

Votre application doit être en mesure d’analyser et de valider les JWTs afin de les utiliser comme Logout Tokens avec Auth0. Pour en savoir plus, consultez Valider les JSON Web Tokens.

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

JSON

{
  "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"
}

​

Auth0 SDKs

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.

​

Exemples de mise en œuvre

​

Stockage des sessions

L’exemple de stockage des sessions est créé en Node (Express) et s’appuie sur l’exemple d’application web Express OpenID Connect.

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.

Cet exemple utilise un magasin de sessions en mémoire à des fins de démonstration.

routes/index.js

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;

middlewares/validateLogoutToken.js

// 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;

​

Magasin de Logout Token

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.

​

Considérations de sécurité

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