Un back-channel logout OIDC met fin aux sessions d'un utilisateur sur une seule application. Il ne révoque pas le tenant du client

Un back-channel logout OIDC met fin aux sessions d'un utilisateur sur une seule application. Il ne révoque pas le tenant du client

La question qu'un MSP entend de la part de son client après un appel d'incident est la suivante : « notre IdP a envoyé un back-channel logout, donc tout le tenant du client est coupé, n'est-ce pas ? » La réponse courte est non. Selon OpenID Connect Back-Channel Logout 1.0, le fournisseur d'identité envoie par POST un Logout Token signé à une relying party, et ce jeton désigne un seul utilisateur final (issuer et subject) et/ou une seule session. En l'absence d'identifiant de session, la relying party met fin à toutes les sessions de cet utilisateur auprès de cette relying party, et rien de plus. Il n'y a ni claim de tenant ni sens de « tout révoquer ».

Cette FAQ répond à six questions que posent les MSP lorsqu'un signal de logout est confondu avec un offboarding. Que prouve un 200 OK renvoyé par l'endpoint de logout, et que ne prouve-t-il pas ? Pourquoi les intégrations machine-to-machine sont-elles entièrement en dehors du chemin de logout ? Pourquoi la fin de la session sur l'IdP ne met-elle pas automatiquement fin aux sessions applicatives, comme l'indique le NIST SP 800-63C-4 (26 août 2025) ? Où se situe un signal de révocation à l'échelle d'un tenant ou d'une politique, avec CAEP sur le Shared Signals Framework, et pourquoi ne remplace-t-il toujours pas un contrôle d'autorisation à chaque requête ? Et pourquoi le logout n'est-il pas un déprovisionnement ?

La règle de cet article est simple : l'offboarding d'un tenant est une action d'administration et d'autorisation, jamais l'effet secondaire d'un logout. Les sources sont les textes de l'OpenID, de l'IETF, du NIST et de l'OWASP, vérifiés le 5 octobre 2026. Il n'y a ni construction de jeton, ni affirmation qu'un produit Altovar émette ou reçoive ces événements de logout ou de signaux partagés.

Le tenant du client est-il entièrement révoqué lorsque l'IdP envoie un back-channel logout ? Dans les mots du client : « ils se sont déconnectés, donc tout le monde chez ce client est parti ». La réponse est non. Une requête Back-Channel Logout est un POST du fournisseur d'identité vers la relying party contenant un Logout Token signé, tel que le définit la section 2.4 d'OIDC Back-Channel Logout 1.0. Le jeton identifie un utilisateur final par son issuer et son subject, et/ou une session par son identifiant. C'est le rayon d'action que la norme donne au signal.

En l'absence d'identifiant de session, la relying party met fin à toutes les sessions de cet utilisateur auprès de cette relying party. La norme ne va pas plus loin. Il s'agit toujours d'un seul utilisateur et d'une seule application. Fermer toutes les sessions de navigateur d'Alice sur le portail de tickets ne ferme ni les sessions de Bob sur ce même portail, ni celles d'Alice sur un autre portail qui n'a jamais reçu de Logout Token.

Le Logout Token ne porte aucun claim de tenant et ne signifie pas « tout révoquer ». Une relying party qui traite un logout comme une révocation de tenant invente un comportement que la spécification ne définit pas. La révocation d'un tenant, en tant qu'ensemble d'actes d'administration distincts et non comme un parcours produit, consiste à désactiver l'enregistrement du tenant, révoquer ses grants et ses enregistrements de clients, renouveler les identifiants qu'il détient et faire en sorte que le point de décision de politique refuse ses requêtes. Chaque acte a un responsable et une piste d'audit. Aucun n'est un logout.

Une brève remarque sur les signatures, sans entrer dans le détail : la spécification exige que le Logout Token soit signé et de courte durée, précisément pour qu'une relying party n'agisse pas sur un logout falsifié ou rejoué. Cet article ne décrit pas comment un jeton est construit ou vérifié. Ce qui compte pour le MSP, c'est le rayon d'action : un utilisateur, une application, pas le tenant du client.

L'endpoint de logout a renvoyé 200 OK. Tous les jetons de l'utilisateur sont-ils invalides ? Pas nécessairement. Un 200 OK signifie que la relying party a effacé l'état des sessions qui lui ont été signalées. C'est un accusé de réception de cette relying party, pas la preuve que tous les jetons ont disparu partout.

Les refresh tokens suivent une règle plus étroite, selon la section 2.7 de Back-Channel Logout. Les refresh tokens liés à la session fermée et émis sans offline_access DEVRAIENT être révoqués ; les refresh tokens offline-access ne DEVRAIENT normalement PAS l'être. Il s'agit d'une propriété générique de la norme. Cet article ne la rattache à la configuration d'aucun fournisseur et ne cite aucune valeur d'inactivité ou de durée de vie.

Les access tokens racontent une autre histoire. Un access token autonome (JWT) reste valide jusqu'à son expiration, sauf si le resource server le vérifie en direct par introspection (RFC 7662) ou si le jeton est révoqué auprès de l'authorization server (RFC 7009). La section 3 de la RFC 7009 note elle-même que la révocation immédiate des access tokens autonomes exige une coordination supplémentaire, non normalisée, entre authorization server et resource server, ou des durées de vie courtes. Un 200 OK sur le logout n'est pas cette coordination.

Un garde-fou sur l'introspection, en une phrase : active: true signifie que le jeton a été émis et qu'il n'est ni révoqué ni expiré. Cela ne dit rien sur le fait que ce tenant ou cette action soient autorisés. C'est une question distincte, que cet article n'approfondit pas. L'OWASP Session Management Cheat Sheet ajoute une ligne : le logout doit invalider la session côté serveur ; supprimer un cookie dans le navigateur n'est pas la même chose.

Le logout coupe-t-il les intégrations machine-to-machine ? Non. Back-Channel Logout met fin aux sessions des utilisateurs finaux auprès des relying parties. Un client machine qui obtient ses jetons via le grant client credentials n'a ni session utilisateur ni identifiant de session : un Logout Token ne peut donc pas le cibler. Le signal n'a nulle part où arriver.

La conséquence pour le MSP, en termes simples : le connecteur RMM, la synchronisation de facturation et le client API de l'agent de sauvegarde continuent de fonctionner une fois que toutes les personnes du client ont été déconnectées. C'est le comportement correct du protocole, et c'est précisément pourquoi « nous avons déconnecté tout le monde » ne constitue pas un procès-verbal d'offboarding. Les personnes ont quitté les applications qui ont reçu un Logout Token. Les intégrations ne sont pas des personnes et n'en ont reçu aucun.

L'offboarding d'une intégration a sa propre checklist, formulée en résultats plutôt qu'en clics dans un produit : désactiver ou renouveler les identifiants du client, révoquer les jetons qu'il détient déjà et retirer son droit d'accès au tenant au point de décision. Chacune de ces actions est un acte d'administration et d'autorisation avec un responsable. Aucune n'est produite par un POST de logout.

La fin de la session sur l'IdP met-elle automatiquement fin aux sessions applicatives ? Non. Le NIST SP 800-63C-4 (révision 4 finale, page datée du 26 août 2025) indique que mettre fin à la session de l'abonné auprès de l'IdP « ne mettra pas nécessairement fin » aux sessions que cet abonné peut avoir auprès des RP en aval (traduction de notre part). Les deux parties peuvent s'échanger des événements de fin de session si le protocole de fédération le permet, ou via des signaux partagés. « Peuvent » ne veut pas dire « vont ».

Back-Channel Logout est l'un de ces mécanismes, et il fonctionne au mieux (best effort). La relying party doit enregistrer une URI de back-channel logout, le fournisseur d'identité doit pouvoir la joindre, et il ne réessaie qu'après des erreurs qu'il juge récupérables (section 2.5 de Back-Channel Logout). Une application qui ne s'est jamais enregistrée, ou qui était injoignable au moment du POST de l'IdP, conserve sa session. Une règle de pare-feu, une URI obsolète ou un enregistrement manquant suffit à laisser une session active.

La section 5 du NIST SP 800-63B-4 ajoute une précision de vocabulaire : les sessions se terminent par expiration ou par logout explicite, et le comportement en fédération est renvoyé au 63C. « L'IdP a expiré » et « toutes les applications ont déconnecté l'utilisateur » sont donc deux faits différents. Un ticket MSP qui les confond clôturera le mauvais travail.

Déconnecter un utilisateur ne supprime pas non plus son appartenance au tenant ni ses rôles. Le NIST SP 800-63C-4 traite la clôture d'un compte d'abonné auprès d'une relying party (suppression des identifiants, des authentificateurs et des attributs) comme un acte distinct de la fin de session. L'appartenance et les rôles sont des données de provisioning et d'autorisation ; les modifier relève du déprovisionnement. La phrase à retenir : fin de session ≠ clôture du compte ≠ offboarding du tenant.

Où se situe une révocation à l'échelle du tenant, si ce n'est pas dans un Logout Token ? L'OpenID Shared Signals Framework 1.0, avec le Continuous Access Evaluation Profile (CAEP 1.0, tous deux en version Final), définit les événements session-revoked et token-claims-change. Leur sujet peut être un sujet complexe incluant une composante de tenant. C'est ce qu'une norme offre de plus proche d'un message de révocation à l'échelle d'un tenant ou d'une politique.

Cela reste un signal : c'est le destinataire qui décide quoi en faire. Recevoir un événement n'équivaut pas à avoir révoqué l'accès. Un produit qui ignore l'événement, le retarde ou le transforme en simple avertissement n'a pas appliqué le refus. L'événement est un déclencheur, pas la décision.

L'autorisation dans le produit doit toujours refuser par défaut et vérifier le statut du tenant et les permissions à chaque requête, comme le formule l'OWASP Authorization Cheat Sheet. Un logout ou un événement CAEP déclenche ce contrôle, il ne le remplace pas. Un MSP qui assimile « CAEP reçu » à « accès révoqué » saute le point de décision.

Cet article ne dit pas quels produits émettent ou reçoivent CAEP. En particulier, il ne dit pas qu'Auris le fait. L'article décrit uniquement la norme et n'affirme pas qu'un produit Altovar prenne en charge CAEP, SSF ou le back-channel logout.

Ce n'est pas une FAQ sur PAR, PKCE ou les passkeys. Ces sujets portent sur la manière dont commence une connexion ou une requête d'autorisation. Cet article porte sur ce qu'un signal de logout termine. Lancer une requête et fermer une session sont deux tâches différentes, et les mélanger produit le mauvais ticket.

Ce n'est pas non plus une FAQ sur les group claims ou sur SCIM. Les données de provisioning et de rôles n'apparaissent ici que pour dire que le logout ne les modifie pas. Les lignes d'appartenance et les attributions de rôles survivent à un Logout Token tant qu'un acte d'administration distinct ne les supprime pas.

Il ne s'agit pas davantage de DPoP ou des cérémonies de liaison d'authentificateur. La contrainte d'émetteur (sender constraint) et la liaison d'authentificateur répondent à d'autres questions que le rayon d'action du logout.

Et il ne s'agit pas des jetons de courte durée ni des TTL de jetons. Ces sujets portent sur la durée de vie d'un jeton. Ici, ce qui compte est le rayon d'action du signal de logout (session ou utilisateur face au tenant), pas la durée de vie. Un access token de courte durée et un Logout Token peuvent coexister dans une même stack et laisser malgré tout intacts les clients machine et les autres applications.

Cet article n'affirme pas qu'Auris prend en charge le back-channel logout, CAEP ou SSF, annonce backchannel_logout_supported, respecte une backchannel_logout_uri propre à chaque client, ou émet des événements de signaux partagés.

La phrase à répéter : un signal de logout met fin à des sessions ; révoquer le tenant d'un client est une décision d'administration et d'autorisation délibérée, vérifiée à chaque requête.