OAuthSD, suivant en cela OAuth 2.0, considère que l’utilisateur final est connecté à une application tant que le jeton d’accès associé est valide.
Il n’y a pas "naturellement" de relation directe entre ce jeton et l’état de connexion local d’une application. Chaque application devra donc mettre en place un monitoring, côté client, dans le but de :
surveiller la validité du jeton d’accès,
réaliser la ré-authentification silencieuse et la connexion automatique,
compléter le mécanisme de déconnexion unique (Single Logout, SLO) en provoquant la déconnexion locale de l’application lorsque le jeton d’accès a expiré.
Plusieurs solutions se présentent pour assurer le suivi de la session OIDC :
1. La communauté se voit proposer une "norme" de gestion de la session OpenID Connect (voir : OpenID Connect Session Management ) qui s’appuie sur des iframes du côté du serveur et du côté de l’application.
Dans sa version 30 publiée en août 2020, le paragraphe 5, encore présent dans la version 28, intitulé "Back-Channel Logout", disparait.
En effet, une nouvelle proposition "OpenID Connect Back-Channel Logout" évite les dysfonctionnements prévus au paragraphe "User Agents Blocking Access to Third-Party Content" :
Notez qu’au moment de la rédaction de cet article, certains agents utilisateurs (navigateurs) commencent à bloquer l’accès au contenu tiers par défaut pour bloquer certains mécanismes utilisés pour suivre l’activité de l’utilisateur final sur les sites. Plus précisément, le contenu tiers bloqué est un contenu de site Web avec une origine différente de l’origine de la fenêtre de l’agent utilisateur ciblée. Les données du site incluent les cookies et toutes les API de stockage Web (sessionStorage, localStorage, etc.).
Cela peut empêcher la capacité des notifications de l’OP au niveau du RP d’accéder à l’état de l’agent utilisateur du RP pour mettre en œuvre des actions de déconnexion locale. En particulier, les cookies et les API de stockage Web peuvent ne pas être disponibles dans le cadre OP chargé dans le contexte RP. L’effet secondaire ici est que, selon le mécanisme utilisé (cookies ou stockage Web), les données nécessaires pour recalculer session_state peuvent ne pas être disponibles. Les implémentations basées sur les cookies peuvent alors renvoyer des modifications pour chaque appel, ce qui entraîne des boucles infinies de ré-authentifications. Par conséquent, les déploiements de cette spécification sont recommandés pour inclure un code défensif pour détecter cette situation et, si possible, informer l’utilisateur final que les déconnexions RP demandées n’ont pas pu être effectuées. Les détails du code défensif nécessaire dépassent le cadre de cette spécification ; il peut varier selon l’agent utilisateur et peut varier dans le temps, car la situation de prévention du suivi de l’agent utilisateur est fluide et continue d’évoluer. ".
Une proposition de spécification qui a connu 30 modifications mais qui n’évolue plus depuis août 2020, et qui de plus se termine sur un constat de dysfonctionnement, est morte !
De plus, il ne s’agit là que d’un procédé de communication entre une application et le serveur OIDC, communication qui peut être réalisée par d’autres moyens, et notamment par interrogation régulière du contrôleur Authorize avec prompt = ’none’. Nous pensons (peut-être à tort ?) qu’une "norme" concernant une couche ISO de niveau protocole ne doit pas introduire à ce niveau un procédé de communication particulier.
2. Notre solution est présentée ici : Implémentation du monitoring avec Javascript : exemples pour SPIP et WordPress interroge donc le contrôleur Authorise avec le paramètre display=’none’.
Une implémentation côté client s’appuyant sur la norme OpenID Connect telle qu’elle existe actuellement est bien préférable à une nouvelle complication des applications clientes et permet d’éviter la violation du principe d’indépendance des couches ISO.
RSS 2.0