Déconnexion par canal d’appui OIDC

Auth0 prend en charge la Spécification 1.0 du canal d’appui OpenID Connect dans tous les locataires ayant souscrit à un plan Entreprise.

Cette spécification exploite l’identifiant de session (sid) inclus dans les jetons d’ID et les jetons de déconnexion pour coordonner la fin de la session via la communication par canal d’appui. Des identifiants de session différents représentent des séances individuelles d’un agent utilisateur ou d’un appareil dans votre locataire. Les jetons de déconnexion déterminent l’utilisateur final et la session à déconnecter.

Pour utiliser la déconnexion par canal d’appui, une application doit exposer un URI de déconnexion par canal d’appui, accessible depuis le serveur du locataire, où l’application s’attend à recevoir les requêtes avec le jeton de déconnexion. Lorsqu’une application reçoit cette requête, elle est obligée d’effacer l’état de la session locale correspondant aux demandes contenues dans le jeton.

Les applications ne peuvent pas s’appuyer sur les témoins de session pour déterminer la session à clôturer lorsque les communications sont effectuées via le canal d’appui. Le service dépend plutôt d’un identifiant de session partagé (sid) sur les jetons d’ID et de déconnexion.

Lorsque les utilisateurs finaux s’authentifient avec succès auprès d’Auth0 lors de la connexion, le serveur d’autorisation émet des jetons d’accès et d’ID. Des jetons de déconnexion sont générés lorsqu’une session est détruite, par exemple par une action de déconnexion ou par la révocation d’une session. Les jetons d’ID et de déconnexion contiennent les demandes dont votre application a besoin pour faciliter le flux de production de déconnexion du canal d’appui. Pour en savoir plus sur les demandes, consultez Demandes de jetons Web JSON.

1. Connexion – Lors de l’authentification de l’utilisateur, le locataire Auth0 ajoute le sid au jeton d’ID.

2. Connexion – L’application conserve l’identifiant de session reçu dans son propre magasin de sessions et l’associe à la session propre à l’application.

3. Déconnexion – L’IdP appelle l’URL de rappel de déconnexion préenregistrée et envoie le jeton de déconnexion à ce point de terminaison. Le jeton contient le user_id (sub) et le sid ainsi que d’autres paramètres.

4. Déconnexion – Le système dorsal de l’application doit valider le jeton de déconnexion conformément à la spécification OIDC et extraire le sid. Le programme dorsal peut ensuite utiliser ce jeton pour trouver la session associée à l’identifiant et y mettre fin si nécessaire.

L’exemple de cas d’utilisation montre comment la déconnexion par canal d’appui fonctionne avec plusieurs applications :

1. Lors de la configuration de l’application, l’application A enregistre un URI de déconnexion du canal d’appui auprès d’Auth0.

2. Lors de la configuration de l’application, l’application B enregistre un URI de déconnexion du canal d’appui auprès d’Auth0.

   Les URL de déconnexion du canal d’appui OIDC doivent :

   • Être accessibles à partir de l’IdP

   • Utiliser des points de terminaison avec chiffrement TLS

   • Valider les jetons de déconnexion

3. Lors de la connexion de l’utilisateur final, un utilisateur s’authentifie auprès d’Auth0 pour accéder à l’application A.

4. Auth0 envoie un jeton d’ID avec sid à l’application A. Pour en savoir plus, consultez Structure du jeton d’ID.

5. L’utilisateur s’authentifie auprès d’Auth0 pour accéder à l’application B.

6. Auth0 envoie un jeton d’ID avec le même sid à l’application B. Votre application doit stocker les informations de session.

7. Pendant la déconnexion, l’application A ou d’autres entités initient la déconnexion sur le canal frontal.

8. Auth0 met fin à la couche de session Auth0 au moyen d’un témoin de session.

9. Auth0 appelle l’URI de déconnexion du canal d’appui de l’application A et envoie le jeton de déconnexion.

10. L’application A valide le jeton de déconnexion et met fin à la session.

11. Auth0 appelle l’URI de déconnexion du canal d’appui de l’application B et envoie le jeton de déconnexion.

12. L’application B valide le jeton de déconnexion et met fin à la session.

Votre application doit être en mesure d’analyser et de valider les JWT pour les utiliser comme jetons de déconnexion avec Auth0. Pour en savoir plus, consultez Valider les jetons Web JSON.

Une fois que votre application valide et décode votre jeton, le contenu est similaire à l’exemple ci-dessous :

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

Un exemple complet et le code de production sont déjà inclus dans la section Exemple de déconnexion du canal d’appui de notre trousse SDK express-openid-connect.

L’exemple de stockage de session est construit en Node (Express) et basé sur l’exemple d’application Web OpenID Connect Express.

Dans l’onglet des sessions de votre application, exposez la route que vous avez configurée pour recevoir le jeton de déconnexion. Validez le jeton et mettez fin à la session de l’utilisateur.

routes/index.js

const express = require('express');
const router = express.Router();
const { requiresAuth } = require('express-openid-connect');

// middleware to validate the logout token
const requiresValidLogoutToken = require('../middlewares/validateLogoutToken');

// helper function to delete user sessions
const deleteUserSessions = require('../utils/sessions');

// new route to receive backchannel logout tokens
// must be configured in the Application -> Sessions tab 
// in the Auth0 Management Dashboard
router.post(
  '/backchannel-logout',
  requiresValidLogoutToken,
  function (req, res, next) {
    // at this point the logout token is valid, checked by requiresValidLogoutToken middleware
    // you can access it from the request object: req.logoutToken

    // delete user session so the user gets logged out
    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

// This middleware validates the logout token as defined here:
// https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation

const jose = require('jose');

async function requiresValidLogoutToken(req, res, next) {

  // get remote key set for token verification
  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',
      }
    );

    // Verify that the Logout token contains a sub claim, a sid claim, or both
    if (!payload.sub && !payload.sid) {
      res
        .status(400)
        .send(
          'Error: Logout token must contain either sub claim or sid claim, or both'
        );
    }

    // Verify that the logout token contains an events claim
    // whose value is a JSON object containing the member name 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'
        );
    }

    // Verify that the Logout token does not contain a nonce claim.
    if (payload.nonce) {
      res
        .status(400)
        .send('Error: Logout token must not contain a nonce claim');
    }

    // attach valid logout token to request object
    req.logoutToken = payload;

    // token is valid, call next middleware
    next();
  } catch (error) {
    res.status(400).send(`Error:  ${error.message}`);
  }
}

module.exports = requiresValidLogoutToken;

Une approche courante pour le stockage des jetons consiste à définir un magasin de déconnexion comme solution de rechange au modèle de magasin de session. Vos applications conservent une collection de jetons de déconnexion au niveau de la persistance.

Chaque fois que l’application a besoin de vérifier son statut d’authentification, elle interroge le magasin de jetons de déconnexion pour savoir si sa session est toujours active. Le magasin de déconnexion efface régulièrement les informations obsolètes pour ne conserver que les informations nécessaires.

Les jetons de déconnexion du canal d’appui sont délivrés sur l’Internet. Par conséquent, les points de terminaison de rappel qui les reçoivent doivent suivre les pratiques exemplaires pour assurer un fonctionnement fiable et sécuritaire. Voici une liste de suggestions non exhaustives. Prendre en compte les situations particulières de déploiement et d’exploitation pour s’y adapter est crucial. Dans la liste ci-dessous, toutes les applications qui gèrent les jetons de déconnexion du canal d’appui sont appelées « applications ».

• Les applications doivent pouvoir stocker l’identifiant de session (demande sid) reçu lors de la connexion de l’utilisateur afin de le récupérer ultérieurement lors de la réception d’un jeton de déconnexion du canal d’appui.

• Les applications doivent vérifier tout jeton reçu conformément aux pratiques exemplaires de validation des JWT.

• Les applications doivent accepter les jetons émis uniquement par des locataires de confiance. Un acteur malveillant peut tenter d’envoyer des jetons émis par d’autres locataires d’Auth0, ces tentatives doivent être rejetées.

• Les applications doivent accepter les jetons uniquement lorsqu’ils contiennent une valeur sid (identifiant de session) que l’application reconnaît. Les jetons contenant un identifiant de session non valide (qu’il soit expiré ou non reconnu) doivent être rejetés.

• Les applications doivent exposer les points de terminaison de rappel uniquement via TLS. Les canaux de communication non cryptés ne sont pas autorisés.

• Il est recommandé que les applications acceptent uniquement les demandes provenant de la liste publiée des adresses IP sortantes.

• Il est recommandé aux applications de suivre les pratiques exemplaires générales en matière de surveillance, de journalisation et de limites anti-attaques. Toutefois, les détails de ces pratiques ne relèvent pas du champ d’application du présent document.

• Il est recommandé que les applications nettoient régulièrement les sessions périmées ou expirées.

• Toute modification de l’adresse du point de terminaison doit être synchronisée avec la configuration du locataire afin de garantir que les jetons de déconnexion sont toujours délivrés à l’URL de rappel de déconnexion du canal d’appui appropriée.

• Configuration de déconnexion du canal d’appui OIDC
• Vérifier les problèmes de connexion et de déconnexion
• Déconnecter des utilisateurs des fournisseurs d’identité SAML
• Déconnexion des utilisateurs d’Auth0 avec le point de terminaison OIDC
• Déconnecter l’utilisateur de l’application
• Déconnecter des utilisateurs des fournisseurs d’identité