Notes produit
La chaîne de déconnexion
Une personne se connecte une fois, mais plusieurs sessions se créent en chemin. Se déconnecter exige de déterminer lesquelles doivent prendre fin sur l’ensemble du parcours.
Une connexion, trois clés
Supposons que votre service propose « Se connecter avec Google ». Pour l’utilisateur, c’est un seul clic.
En coulisses, chaque système du parcours crée et conserve sa propre session. Une chez Google, une chez Authrim, une dans votre application : trois au total.
Une session encore active peut permettre de continuer à utiliser le service ou de se reconnecter sans saisir de mot de passe.
Se déconnecter ne consiste pas seulement à afficher un message.
Il faut définir le périmètre, puis terminer les sessions concernées.
La révocation des jetons est une autre opération
Les « clés » désignent ici des sessions. Les jetons d’accès et de renouvellement fonctionnent autrement : terminer une session ne rend pas nécessairement les jetons déjà émis invalides. Leur révocation est une opération distincte.
Dans OIDC, la déconnexion des sessions, la révocation des jetons et la désactivation du compte chez l’IdP amont sont trois opérations différentes. Cet article traite des sessions. Pour les jetons, voir introspection et révocation.
Authrim est au milieu
Dans ce parcours, le fournisseur amont fournit la connexion et votre application la demande. Authrim change de rôle selon le côté auquel il s’adresse.
La déconnexion s’arrête souvent en chemin
La connexion suit son parcours. La déconnexion, elle, doit être transmise explicitement.
Terminer la session amont ne supprime pas automatiquement celles d’Authrim et de l’application. Il faut transmettre l’arrêt en aval, puis que chaque destinataire termine la session correspondante. Le schéma suppose les méthodes et réglages nécessaires en place.
Ce que cela donne sur le terrain
| Situation | Conséquence d’une chaîne interrompue |
|---|---|
| Départ d’un salarié | Les RH révoquent l’accès. L’application reste ouverte sur l’ordinateur et les données internes restent visibles jusqu’au lendemain. |
| Terminaux partagés | Commerce, hôpital, centre d’appels : la personne précédente s’est déconnectée, mais un autre onglet affiche encore son tableau de bord. |
| Appareil perdu | La personne a choisi de se déconnecter partout. Seule la session en cours a réellement pris fin. |
| Réponse à un incident | Le compte compromis est bloqué. La session de l’attaquant reste pourtant active jusqu’à son expiration. |
| Audit | Il faut démontrer que la déconnexion se propage à tous les systèmes. Aucune preuve n’est disponible. |
Le bouton de déconnexion existe, l’écran change. Pourtant, la portée réelle est plus étroite que prévu. C’est ce qui rend le problème difficile à repérer.
Les limites du passage par le navigateur
Deux méthodes permettent de prévenir les applications. L’une dépend du navigateur et rencontre davantage de restrictions.
La certification d’Authrim couvre la réception par back-channel. La réception et l’envoi en aval doivent chacun être vérifiés.
Vérifier le destinataire et l’émetteur
Authrim agit comme Relying Party (RP) envers le fournisseur amont et comme OpenID Provider (OP) envers les applications. Transmettre la déconnexion exige de respecter les spécifications dans les deux rôles.
- Côté RP : vérifier la notification reçue et terminer la session Authrim correspondante.
- Côté OP : envoyer les notifications permettant aux applications de terminer leurs sessions correspondantes.
Les certifications des profils de déconnexion OP et RP apportent des éléments de vérification pour ces deux rôles. Authrim les a obtenues via la procédure d’auto-certification de l’OpenID Foundation et ses tests officiels de conformité.
La certification atteste que la version soumise a réussi les tests des profils présentés. Elle ne garantit pas la fin immédiate de toutes les sessions dans les applications et le réseau du client.
Les méthodes, points de notification et correspondances de sessions doivent être configurés chez le fournisseur amont et dans chaque application. Désactiver un compte amont ne déclenche pas forcément une notification. Les échecs de livraison et les relances doivent aussi être vérifiés dans la configuration déployée.
Les versions et profils certifiés figurent dans la liste Certified OpenID Relying Parties & Logout Profiles. La présentation de la certification en précise la portée.
Après la déconnexion, où reste-t-il une session active ?
C’est la question lors du passage d’un terminal partagé à un collègue ou du départ d’un salarié. Authrim reçoit et transmet les notifications entre fournisseur amont et applications. La certification renseigne sur l’implémentation ; les essais de l’ensemble connecté vérifient la portée effective de la déconnexion.