sid) inclus dans les 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 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 é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.

- Login - Pendant l’authentification de l’utilisateur, le tenant Auth0 ajoute le
sidau jeton ID. - Login - L’application stocke l’identifiant de session reçu dans son propre magasin de sessions et l’associe à la session propre à l’application.
- 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 lesid, ainsi que d’autres paramètres. - 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 :
- Lors de la configuration de l’application, Application A enregistre un URI de Back-Channel Logout auprès d’Auth0.
-
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
- Lors du login de l’utilisateur final, un utilisateur s’authentifie auprès d’Auth0 pour accéder à Application A.
-
Auth0 envoie un ID token avec
sidà Application A. Pour en savoir plus, consultez Structure des ID token. - L’utilisateur s’authentifie auprès d’Auth0 pour accéder à Application B.
-
Auth0 envoie un ID token avec le même
sidà Application B. Votre application doit stocker les informations de session. - Lors de la déconnexion, Application A ou d’autres entités lancent la déconnexion sur le front-channel.
- Auth0 met fin à la couche de session Auth0 au moyen du cookie de session.
- Auth0 appelle l’URI de Back-Channel Logout d’Application A et envoie le Logout Token.
- Application A valide le Logout Token et met fin à la session.
- Auth0 appelle l’URI de Back-Channel Logout d’Application B et envoie le Logout Token.
- Application B valide le Logout Token et met fin à la session.
Exemple de jeton
Votre application doit être en mesure d’analyser et de valider les 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
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
middlewares/validateLogoutToken.js
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.