Le code du serveur OAuthSD peut être paramétré pour implémenter (ou non) le SLI. La déconnexion unique (SLO) et la ré-authentification silencieuse (SRA) découlent du SLI.
Identification unique (Single Login Identification, SLI)
Lorsque le SLI est autorisé (ENABLE_SLI = true) ET que l’application cliente a été enregistrée sur le serveur avec le scope ’sli’, le contrôleur authorize traite une demande d’autorisation sans paramètre prompt comme ceci :
La présence d’un cookie SLI enregistré sur l’agent est testée,
si le cookie SLI est présent, non périmé et validé, il est utilisé pour l’authentification (le formulaire de login n’est pas présenté à l’utilisateur), le contrôleur retournant les jetons au client (le code d’autorisation dans le cas du flux d’autorisation avec code). A ce moment, la validité du cookie SLI est rafraichie à sa valeur initiale.
En cas d’échec : soit il y a retour standard au client avec une erreur, soit le contrôleur présente le formulaire de login si la constante REAUTHENTICATE_NO_ROUNDTRIP est true. Dans un cas comme dans l’autre, le cookie SLI est d’abord détruit.
Si le cookie SLI est absent :
- si l’application cliente ne présente pas le scope ’sli’, le contrôleur agit de façon standard.
- si l’application cliente autorise le SLI, et si l’authentification mentionnée précédemment réussit, un cookie SLI est enregistré sur l’agent dans le domaine du serveur. C’est le seul cas où le cookie SLI est créé.
Notes :
Toute erreur "technique" (autre que les erreurs non-répétées de l’utilisateur dans l’entrée de son login ou de son mot de passe) conduit à la destruction du cookie SLI afin de protéger l’application contre les tentatives d’intrusion. Dans un tel cas le serveur ne répond pas pour ne pas orienter l’attaquant.
Une tentative de connexion sous un identifiant d’utilisateur différent provoque également la destruction du cookie SLI, et conduit à la présentation du formulaire d’identification.
Une tentative de se connecter depuis un poste de travail différent a le même effet.
La fonctionnalité SLI est active dans les trois flux OpenID Connect, donc avec le plus sécurisé : Autorisation avec code. Ceci est un avantage par rapport à des solutions souvent présentées utilisant le flux Implicite.
Le comportement des demandes avec prompt = ’none’, ’login’ et ’consent’ reste conforme au standard.
Lorsque l’utilisateur change d’application et bénéficie du SLI, de nouvelles demandes de consentement pourraient lui être présentées.
Déconnexion unique (Single Login Out, SLO)
Le serveur expose un point de terminaison logout, permettant de déconnecter l’utilisateur de toutes les applications clientes.
La demande de déconnexion unique se fait comme une demande d’introspection en fournissant le jeton d’identité.
Lorsque la déconnexion est effectuée, tous les jetons d’accès enregistrés sur le serveur pour le sujet considéré sont effacés. De ce fait, les cookies SLI éventuellement présents sur les agents de l’utilisateur seront détruits si une tentative de connexion est effectuée.
Notez que les application clientes doivent gérer la déconnexion à leur niveau, il n’y a pas de miracle !
Si on souhaite connaître l’état actuel de connexion d’une application, il suffit de répéter la demande d’authentification avec prompt = ’none’. Si la déconnexion a eu lieu, le serveur répondra avec ’login_required’. Cette solution a l’avantage de répondre totalement à la norme OpenID Connect dans son état définitif.
Ré-authentification silencieuse (Silent Re-Authentication, SRA)
Dans le cadre du serveur OAuthSD, cette fonctionnalité résulte directement du SLI [2].
S’agissant des applications n’autorisant pas le SLI, elles ne bénéficient pas du SRA. Mais il est probable que les raisons qui ont conduit à ne pas autoriser le SLI conduiraient à ne pas autoriser le SRA.
Notons :
qu’il est toujours possible de Rafraîchir (actualiser) un jeton d’accès,
l’existence de la méthode id_token_hint : ré-authentification silencieuse du sujet avec l’ID Token.
Le Cookie SLI
Le cookie SLI est un concept propre à DnC permettant au serveur OAuthSD d’offrir toutes les fonctionnalités de la connexion unique (SLI, SLO, SRA, SLO) sans modification des applications clientes pourvu qu’elles soient déjà interfacées avec OpenID Connect. Compte-tenu de la complexité et de la diversité des solutions proposées par ailleurs, qui n’ont pas fait à ce jour (début 2019) de spécification définitive, c’est une contribution majeure d’OAuthSD à OpenID Connect.
Le cookie SLI est créé par le contrôleur Authorize si le SLI est autorisé pour l’application cliente (scope ’sli’).
Le cookie SLI est doublement sécurisé :
Le cookie SLI est chiffré par un algorithme symétrique fort dont la clé est connue du seul serveur.
Il est enregistré dans le domaine du serveur, n’est disponible qu’à travers une connexion sécurisée par HTTPS et pour le protocole HTTP seulement (il n’est pas accessible par les scripts côté user-agent).
RSS 2.0