Cette rubrique traite de développements exploratoires, au delà des spécifications ou en applications de spécifications non stables.

Connexion unique (Single Login Identification, SLI)

, par DnC

Une fonctionnalité attendue de la délégation d’autorisation est la capacité donnée à l’utilisateur final de ne se connecter qu’une seule fois pour accéder à différentes applications (Single Login Identification, SLI).

De façon standard, les flux d’OpenID Connect ne permettent pas de réaliser directement le SLI, mais des possibilités existent. On est là sur une technique peu divulguée, qui nécessite des développement significatifs du côté des applications.

A côté de ces méthodes standard, OAuthSD offre l’option de gérer le SLI et la ré-authentification silencieuse sans nécessiter de code spécifique du côté des applications clientes. Ceci est traité dans cet article : SLI, SLO et SRA sont dans un bateau : OAuthSD.

SSO et SLI

Lorsque l’on évoque SSO (Single Sign On), on englobe souvent deux fonctionnalités :
- le fait de ne s’enregistrer (sign on) qu’une seule fois sur un serveur d’identité et de pouvoir se connecter (entrer son login et son mot de passe) sur différentes applications sans avoir à s’enregistrer sur chacune d’elle. C’est à proprement parler le SSO.
- le fait de se connecter à une application et de naviguer vers une autre sans avoir à entrer à nouveau son login et son mot de passe. Il s’agit du Single Login Identification (SLI).

Si le SSO est dans la nature même de OAuth 2 et OpenID Connect, il n’en est pas de même pour le SLI. En revanche, OpenID Connect offre "tout ce qu’il faut" pour le réaliser. Sans pour autant présenter de flux particulier pour cela : c’est donc une fonctionalité à développer du côté des applications (voir : Management de session OpenID Connect), ou bien une surcouche, non standard, à ajouter à la bibliothèque Oauth 2, à côté de la sur-couche OpenID Connect[. C’est ce qu’offre OAuthSD, voir : SLI, SLO et SRA sont dans un bateau : OAuthSD .

Bien entendu, le SLI n’est possible que dans un ensemble d’applications liées à un même serveur d’identité, c’est à dire dans le domaine d’une entreprise (corporate realm).

Applications situées dans le même domaine

Dans le cas d’applications situées dans le même domaine (par exemple dans diférents sous-domaine d’un domaine principal, en plus de ce domaine lui_même), une solution simple est de partager le cookie de session entre les applications. Pour cela, le concepteur des applications enregistrera le cookie pour le domaine principal au lieu de l’enregistrer pour le sous-domaine des applications (paramètres cookie_domain et cookie_path).

Cependant, les scopes sont particuliers aux applications. L’application cible doit donc ré-interroger le serveur d’autorisation pour obtenir un JWT qui lui soit propre.

Applications situées dans des domaines différents

Dans le cas d’applications situées dans des domaines différents le problème est un peu plus complexe.
La transmission d’autorisation est réputée sans solution sûre avec les flux OpenID Connect standard. En effet, l’application cible doit obtenir la certitude de l’origine du jeton reçu, et donc de l’identité de l’utilisateur final, sans pouvoir lui imposer une nouvelle demande d’identification.

Demande d’authentification silencieuse (Silent Authentication Request)

Le protocole OpenID Connect prend en charge un paramètre prompt = none sur la demande d’authentification qui permet aux applications d’indiquer que le serveur d’autorisations ne doit afficher aucune interaction de l’utilisateur (telle que l’authentification, le consentement). OAuthSD renverra la réponse demandée à l’application ou renverra une erreur si l’utilisateur n’est pas déjà authentifié, ou si un type de consentement ou une invite est requis avant de continuer.

OAuthSD va plus loin ...

A côté de ces méthodes standard, OAuthSD offre l’option de gérer le SLI et la ré-authentification silencieuse sans nécessiter de code spécifique du côté des applications clientes.

Management de session OpenID Connect

, par DnC

OpenID Connect Session Management.

Traduction du document OpenID Connect Session Management 1.0 - draft 28

...

Cette spécification définit le terme suivant :

Session

Période continue pendant laquelle un utilisateur final accède à un RP (Relying Party) en s’appuyant sur l’authentification de l’utilisateur final effectuée par le fournisseur OpenID.

2. Découverte du point de terminaison

Pour prendre en charge la gestion de session OpenID Connect, le RP doit obtenir les URL de point de terminaison associées à la gestion de session. Ces URL sont normalement obtenues via la réponse à la découverte de l’OP, comme décrit dans OpenID Connect Discovery 1.0 [OpenID.Discovery], ou PEUVENT être apprises via d’autres mécanismes.

2.1. Métadonnées de découverte du fournisseur OpenID

Ces paramètres de métadonnées de fournisseur OpenID DOIVENT être inclus dans les réponses de découverte du serveur lorsque la gestion de session et la découverte sont prises en charge :

check_session_iframe

CHAMPS OBLIGATOIRES. URL d’un iframe de l’OP qui prend en charge les communications entre origines croisées pour les informations d’état de session avec le client RP, à l’aide de l’API postMessage de HTML5. La page est chargée à partir d’un iframe invisible incorporé dans une page du RP afin de pouvoir s’exécuter dans le contexte de sécurité de l’OP. Il accepte les requêtes postMessage en provenance de l’iframe du RP concerné et utilise postMessage pour renvoyer le statut de connexion de l’utilisateur final vers l’OP.

end_session_endpoint

CHAMPS OBLIGATOIRES. URL de l’OP sur laquelle un RP peut effectuer une redirection pour demander à l’utilisateur final d’être déconnecté de l’OP.

3. Création et mise à jour de sessions

Dans OpenID Connect, la session du RP commence généralement lorsque le RP valide le jeton d’identification de l’utilisateur final. Reportez-vous à la spécification OpenID Connect Core 1.0 [OpenID.Core] pour savoir comment obtenir un jeton ID et le valider. Lorsque l’OP prend en charge la gestion de session, il DOIT également renvoyer l’état de session en tant que paramètre supplémentaire session_state dans la réponse d’authentification. La réponse d’authentification OpenID Connect est spécifiée dans la Section 3.1.2.5 d’OpenID Connect Core 1.0.

Ce paramètre est :

session_state
Etat de session. Chaîne JSON [RFC7159] représentant l’état de connexion de l’utilisateur final sur l’OP. Il NE DOIT PAS contenir le caractère espace (""). Cette valeur est opaque pour le RP. Ceci est OBLIGATOIRE si la gestion de session est prise en charge.

La valeur de l’état de session est initialement calculée sur le serveur. La même valeur d’état de session est également recalculée par l’if iframe dans le client du navigateur. La génération de valeurs appropriées pour l’état de session est spécifiée dans la section 4.2 et est basée sur un hachage cryptographique salé de l’ID client, de l’URL d’origine et de l’état du navigateur OP. Pour l’URL d’origine, le serveur peut utiliser l’URL d’origine de la réponse d’authentification, conformément à l’algorithme spécifié à la section 4 de la RFC 6454 [RFC6454].

4. Notification de changement d’état de session

Un jeton d’identité vient généralement avec une date d’expiration. Le RP PEUT s’y fier pour expirer la session du RP. Cependant, il est tout à fait possible que l’utilisateur final se soit déconnecté de l’OP avant la date d’expiration. Par conséquent, il est hautement souhaitable de pouvoir connaître le statut de connexion de l’utilisateur final à l’OP.

Pour ce faire, il est possible de répéter la demande d’authentification avec prompt = aucune. Cependant, cela entraîne un trafic réseau, ce qui est problématique sur les appareils mobiles qui deviennent de plus en plus populaires. Par conséquent, une fois que la session est établie avec la demande d’authentification et la réponse, il est souhaitable de pouvoir vérifier l’état de la connexion sur l’opérateur sans générer de trafic sur le réseau en interrogeant un OP iframe caché à partir d’un RP iframe avec un postMessage à origine restreinte, comme suit.

4.1. RP iframe

Le RP charge un iframe invisible à partir de lui-même. Cette iframe DOIT connaître l’ID de l’OP iframe, comme décrit à la section 4.2, afin de pouvoir envoyer un message à l’OP iframe. L’iframe RP interroge l’OP iframe avec postMessage à un intervalle approprié pour l’application RP. Avec chaque postMessage, il envoie l’état de session défini dans la section 4.2.

Le postMessage de l’iframe RP fournit la concaténation suivante en tant que données :

ID client + "" + état de session

Il doit également pouvoir recevoir le postMessage de l’OP iframe. Les données reçues seront soit modifiées, soit inchangées, sauf si la syntaxe du message envoyé est déterminée par le terminal opérateur comme étant malformée, auquel cas les données reçues seront erronées. Dès réception de la modification, le RP DOIT effectuer une nouvelle authentification avec invite = aucune pour obtenir l’état de la session en cours sur le terminal opérateur. À la réception d’une erreur, le RP NE DOIT PAS effectuer de nouvelle authentification avec invite = aucune, afin de ne pas causer de boucles infinies potentielles générant un trafic réseau vers le terminal opérateur.

Voici un exemple de pseudo-code non normatif pour l’iframe RP :

Javascript

  1. var stat = "unchanged";
  2. var mes = client_id + " " + session_state;
  3.  
  4. function check_session()
  5. {
  6. var targetOrigin = "https://server.example.com";
  7. var win = window.parent.document.getElementById("op").
  8. contentWindow;
  9. win.postMessage( mes, targetOrigin);
  10. }
  11.  
  12. function setTimer()
  13. {
  14. check_session();
  15. timerID = setInterval("check_session()",3*1000);
  16. }
  17.  
  18. window.addEventListener("message", receiveMessage, false);
  19.  
  20. function receiveMessage(e)
  21. {
  22. var targetOrigin = "https://server.example.com";
  23. if (e.origin !== targetOrigin ) {return;}
  24. stat = e.data;
  25.  
  26. if stat == "changed" then take the actions below...
  27. }

Télécharger

4. Notification de changement d’état de session

Un jeton d’identité vient généralement avec une date d’expiration. Le RP PEUT s’y fier pour expirer la session du RP. Cependant, il est tout à fait possible que l’utilisateur final se soit déconnecté de l’OP avant la date d’expiration. Par conséquent, il est hautement souhaitable de pouvoir connaître le statut de connexion de l’utilisateur final à l’OP.

Pour ce faire, il est possible de répéter la demande d’authentification avec prompt = aucune. Cependant, cela entraîne un trafic réseau, ce qui est problématique sur les appareils mobiles qui deviennent de plus en plus populaires. Par conséquent, une fois que la session est établie avec la demande d’authentification et la réponse, il est souhaitable de pouvoir vérifier l’état de la connexion sur l’opérateur sans générer de trafic sur le réseau en interrogeant un OP iframe caché à partir d’un RP iframe avec un postMessage à origine restreinte, comme suit.

4.2. OP iframe

Le RP charge également un OP iframe invisible à partir de check_session_iframe de l’OP. Le RP DOIT assigner un attribut id à l’iframe afin qu’il puisse l’adresser, comme décrit ci-dessus. L’OP iframe DOIT imposer que l’appelant ait la même origine que son cadre parent. Il DOIT rejeter les demandes postMessage de toute autre source.

Comme spécifié dans la section 4.1, le postMessage de l’iframe RP fournit la concaténation suivante en tant que données :

ID client + "" + état de session

L’op iframe a accès à l’état du navigateur dans l’OP (dans un cookie ou dans un stockage HTML5) qu’il utilise pour calculer et comparer l’état de session OP passé par le RP. L’op iframe DOIT le recalculer à partir de l’ID client précédemment obtenu, de l’URL d’origine de la source (à partir de postMessage) et de l’état actuel du navigateur OP. L’état de session inclut toutes ces informations pour des raisons de confidentialité, de sorte que différents clients actifs dans le même navigateur ont des valeurs d’état de session distinctes.

Si le postMessage reçu est syntaxiquement incorrect, de sorte que l’ID client publié et l’URL d’origine ne peuvent pas être déterminés ou sont incorrects sur le plan syntaxique, l’OP iframe DOIT poster (postMessage) à la source la chaîne d’erreur. Si la valeur reçue et la valeur calculée ne correspondent pas, l’OP iframe DOIT poster à la source la chaîne modifiée. S’il y a correspondance, alors il DOIT poster la chaîne inchangée.

Voici un exemple non normatif de pseudo-code pour l’OP iframe :

Javascript

  1. window.addEventListener("message", receiveMessage, false);
  2.  
  3. function receiveMessage(e){ // e.data has client_id and session_state
  4.  
  5. // Validate message origin
  6. var client_id = e.data.split(' ')[0];
  7. var session_state = e.data.split(' ')[1];
  8. var salt = session_state.split('.')[1];
  9.  
  10. // if message syntactically invalid
  11. // postMessage('error', e.origin) and return
  12.  
  13. // get_op_browser_state() is an OP defined function
  14. // that returns the browser's login status at the OP.
  15. // How it is done is entirely up to the OP.
  16. var opbs = get_op_browser_state();
  17.  
  18. // Here, the session_state is calculated in this particular way,
  19. // but it is entirely up to the OP how to do it under the
  20. // requirements defined in this specification.
  21. var ss = CryptoJS.SHA256(client_id + ' ' + e.origin + ' ' +
  22. opbs + ' ' + salt) + "." + salt;
  23.  
  24. var stat = '';
  25. if (session_state == ss) {
  26. stat = 'unchanged';
  27. } else {
  28. stat = 'changed';
  29. }
  30.  
  31. e.source.postMessage(stat, e.origin);
  32. };

Télécharger

L’état du navigateur OP sera généralement stocké dans un cookie ou dans un stockage local HTML5. C’est l’origine liée au serveur d’autorisations. Il capture des événements significatifs tels que les connexions, les déconnexions, le changement d’utilisateur, le changement de statut d’authentification pour les clients utilisés par l’utilisateur final, etc. Ainsi, l’OP DEVRAIT mettre à jour la valeur de l’état du navigateur en réponse à de tels événements significatifs. En conséquence, le prochain appel à check_session () après un tel événement renverra la valeur modifiée. Il est RECOMMANDÉ que le terminal opérateur ne mette pas à jour l’état du navigateur trop fréquemment en l’absence d’événements significatifs, afin d’éviter un trafic réseau excessif sur le client en réponse à des événements erronés.

Le calcul de l’état de session renvoyé en réponse à des demandes d’authentification infructueuses DEVRAIT, en plus de l’état du navigateur, incorporer suffisamment d’aléa sous la forme d’un sel afin d’empêcher l’identification d’un utilisateur final lors d’appels successifs au point de terminaison d’autorisation de l’OP.

Dans le cas d’un client autorisé (réponse d’authentification réussie), l’OP DEVRAIT changer la valeur de l’état de session renvoyé au client dans l’un des événements suivants :

- L’ensemble des utilisateurs authentifiés auprès du navigateur change (connexion, déconnexion, ajout de session).
- Statut d’authentification des clients utilisés par les modifications apportées à l’utilisateur final.

De plus, l’état du navigateur utilisé pour vérifier l’état de la session DEVRAIT changer avec de tels événements. Les appels à check_session () renverront les modifications apportées par rapport aux versions antérieures de l’état de session après de tels événements. Il est RECOMMANDÉ que l’état du navigateur NE DEVRAIT PAS varier trop souvent en l’absence de tels événements afin de minimiser le trafic sur le réseau causé par la réponse du client aux notifications modifiées.

Dans le cas d’une demande d’authentification infructueuse, la valeur de l’état de session renvoyée DEVRAIT varier avec chaque demande. Cependant, l’état de la session du navigateur n’a pas besoin de changer sauf si un événement significatif se produit. En particulier, de nombreuses valeurs d’état de session peuvent être simultanément valides, par exemple en introduisant un sel aléatoire dans les états de session émis en réponse à des demandes d’authentification infructueuses.

Si un cookie est utilisé pour conserver l’état du navigateur OP, l’indicateur HttpOnly ne peut probablement pas être défini pour ce cookie car il doit être accessible à partir de JavaScript. Par conséquent, les informations pouvant être utilisées pour identifier l’utilisateur ne doivent pas être placées dans le cookie, car elles pourraient être lues par du JavaScript non associé.

Dans certaines implémentations, les notifications modifiées ne se produiront que lorsque la session de l’utilisateur final sera modifiée, alors que dans d’autres implémentations, elles pourront également survenir à la suite de modifications apportées à d’autres sessions entre l’agent d’utilisateur et le terminal opérateur. Les PR doivent être préparés à toute éventualité, en gérant en silence tous les faux positifs susceptibles de se produire.

L’état du navigateur OP sera généralement stocké dans un cookie ou dans un stockage local HTML5. C’est l’origine liée au serveur d’autorisations. Il capture des événements significatifs tels que les connexions, les déconnexions, le changement d’utilisateur, le changement de statut d’authentification pour les clients utilisés par l’utilisateur final, etc. Ainsi, l’OP DEVRAIT mettre à jour la valeur de l’état du navigateur en réponse à de tels événements significatifs. En conséquence, le prochain appel à check_session () après un tel événement renverra la valeur modifiée. Il est RECOMMANDÉ que le terminal opérateur ne mette pas à jour l’état du navigateur trop fréquemment en l’absence d’événements significatifs, afin d’éviter un trafic réseau excessif sur le client en réponse à des événements erronés.

Le calcul de l’état de session renvoyé en réponse à des demandes d’authentification infructueuses DEVRAIT, en plus de l’état du navigateur, incorporer suffisamment d’aléa sous la forme d’un sel afin d’empêcher l’identification d’un utilisateur final lors d’appels successifs au point de terminaison d’autorisation de l’OP.

Dans le cas d’un client autorisé (réponse d’authentification réussie), l’OP DEVRAIT changer la valeur de l’état de session renvoyé au client dans l’un des événements suivants :
- L’ensemble des utilisateurs authentifiés auprès du navigateur change (connexion, déconnexion, ajout de session).
- Statut d’authentification des clients utilisés par les modifications apportées à l’utilisateur final.

De plus, l’état du navigateur utilisé pour vérifier l’état de la session DEVRAIT changer avec de tels événements. Les appels à check_session () renverront les modifications apportées par rapport aux versions antérieures de l’état de session après de tels événements. Il est RECOMMANDÉ que l’état du navigateur NE DEVRAIT PAS varier trop souvent en l’absence de tels événements afin de minimiser le trafic sur le réseau causé par la réponse du client aux notifications modifiées.

Dans le cas d’une demande d’authentification infructueuse, la valeur de l’état de session renvoyée DOIT varier avec chaque demande. Cependant, l’état de la session du navigateur n’a pas besoin de changer sauf si un événement significatif se produit. En particulier, de nombreuses valeurs d’état de session peuvent être simultanément valides, par exemple en introduisant un sel aléatoire dans les états de session émis en réponse à des demandes d’authentification infructueuses.

Si un cookie est utilisé pour conserver l’état du navigateur OP, l’indicateur HttpOnly ne peut probablement pas être défini pour ce cookie car il doit être accessible à partir de JavaScript. Par conséquent, les informations pouvant être utilisées pour identifier l’utilisateur ne doivent pas être placées dans le cookie, car elles pourraient être lues par du JavaScript non associé.

Dans certaines implémentations, les notifications modifiées ne se produiront que lorsque la session de l’utilisateur final sera modifiée, alors que dans d’autres implémentations, elles pourront également survenir à la suite de modifications apportées à d’autres sessions entre l’agent d’utilisateur et le terminal opérateur. Les PR doivent être préparés à toute éventualité, en gérant en silence tous les faux positifs susceptibles de se produire.

5. Déconnexion initiée par le RP

Un RP peut notifier à l’OP que l’utilisateur final s’est déconnecté du site et peut également vouloir se déconnecter de l’OP. Dans ce cas, le RP, après avoir déconnecté l’utilisateur final du RP, redirige l’agent utilisateur de l’utilisateur final vers l’URL du point de terminaison de déconnexion du PO. Cette URL est normalement obtenue via l’élément end_session_endpoint de la réponse à la découverte du PO ou peut être apprise via d’autres mécanismes.

Cette spécification définit également les paramètres suivants qui sont transmis en tant que paramètres de requête dans la demande de déconnexion :

id_token_hint

CONSEILLÉ. Le jeton d’ID précédemment émis a été transmis au point de terminaison de la déconnexion en tant qu’indication de la session authentifiée actuelle de l’utilisateur final avec le client. Ceci est utilisé comme indication de l’identité de l’utilisateur final que le RP demande à être déconnecté par l’OP. Le PO n’a pas besoin d’être répertorié en tant que public du jeton ID lorsqu’il est utilisé en tant que valeur id_token_hint.

post_logout_redirect_uri

OPTIONNEL. URL à laquelle le RP demande que l’agent utilisateur de l’utilisateur final soit redirigé après la déconnexion. La valeur DOIT avoir déjà été enregistrée auprès de l’OP, soit à l’aide du paramètre d’enregistrement post_logout_redirect_uris, soit via un autre mécanisme. S’il est fourni, l’OP DEVRAIT honorer cette demande après la déconnexion.

state

OPTIONNEL. Valeur opaque utilisée par le RP pour maintenir l’état entre la demande de déconnexion et le rappel au noeud final spécifié par le paramètre de requête post_logout_redirect_uri. S’il est inclus dans la demande de déconnexion, l’OP retransmet cette valeur au RP en utilisant le paramètre de requête d’état lors de la redirection de l’agent d’utilisateur vers le RP.

Au point de terminaison de la déconnexion, l’OP DEVRAIT demander à l’utilisateur final s’il souhaite également se déconnecter de l’OP. Si l’utilisateur final dit "oui", alors l’OP DOIT déconnecter l’utilisateur final.

5.1. Redirection vers RP après la déconnexion

Dans certains cas, le RP demande à ce que l’agent d’utilisateur de l’utilisateur final soit redirigé vers le RP après la déconnexion. La redirection post-déconnexion n’est effectuée que lorsque la déconnexion est lancée par le RP, auquel cas la cible de la redirection est la valeur du paramètre de requête post_logout_redirect_uri utilisée par le RP initiateur ; sinon ce n’est pas fait. Cette spécification définit ce paramètre d’enregistrement dynamique à cette fin, conformément à la section 2.1 d’OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration].

5.1.1. Client Registration Metadata

This Client Metadata parameter MAY be included in the Client’s Registration information when Session Management and Dynamic Registration are supported :

post_logout_redirect_uris

OPTIONAL. Array of URLs supplied by the RP to which it MAY request that the End-User’s User Agent be redirected using the post_logout_redirect_uri parameter after a logout has been performed.

6. Validation

Si l’une des procédures de validation définies dans la présente spécification échoue, les opérations nécessitant des informations qui n’ont pas été correctement validées DOIVENT être annulées et les informations qui n’ont pas été validées NE DOIVENT PAS être utilisées.

7. Considérations de mise en œuvre

Cette spécification définit les fonctionnalités utilisées par les parties utilisatrices et les fournisseurs OpenID ayant choisi d’implémenter la gestion de session. Toutes ces parties utilisatrices et fournisseurs OpenID DOIVENT implémenter les fonctions listées dans cette spécification comme étant "REQUIRED" ou décrites avec un "MUST". Aucune autre considération d’implémentation pour les implémentations de Session Management n’est définie par cette spécification.

8. Considérations de sécurité

L’OP iframe DOIT imposer que l’appelant ait la même origine que son cadre parent. Il DOIT rejeter les demandes postMessage provenant de toute autre source, afin d’empêcher les attaques de script entre sites.

Le paramètre id_token_hint associé à une demande de déconnexion peut être utilisé pour déterminer quel RP a lancé la demande de déconnexion. Les demandes de déconnexion sans valeur id_token_hint valide constituent un moyen de déni de service potentiel ; par conséquent, les opérateurs peuvent vouloir demander une confirmation explicite de l’utilisateur avant d’agir.

...

SLI, SLO et SRA sont dans un bateau : OAuthSD

, par DnC

Dans le cadre des flux OpenID Connect, le serveur OAuthSD implémente la fonction d’identification unique (Single Login Identification, SLI), la déconnexion unique (Single Login Out, SLO) ainsi que la ré-authentification silencieuse (Silent Re-Authentication, SRA). Ceci sans modification du code d’interface des applications avec OIDC, tout étant pris en compte au niveau du contrôleur authorize.

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) en résultant.

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 dans le domaine du serveur (et non dans celui de l’application) est testée,
- si le cookie SLI est présent, non périmé et validé, il est utilisé pour l’authentification, 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 ile contrôleur présente le formulaire de login si la constante LOGIN_AFTER_SLI_FAILS 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 :
- Le comportement des demandes avec prompt = ’none’, ’login’ et ’consent’ reste conforme au standard.

Déconnexion unique (Single Login Out, SLO)

Lorsque le SLI est autorisé au niveau du serveur (quelque soit l’application), le serveur expose un nouveau point de terminaison logout, permettant de déconnecter le sujet (l’utilisateur final connecté à l’applcation cliente) de toutes les applications.

La demande de déconnexion unique se fait comme une demande d’introspection en fournissant le jeton d’identité.

Pour que la déconnexion soit effective, le contrôleur logout doit vérifier qu’il existe un cookie SLI valide sur l’agent du sujet, ainsi que quelques autres vérifications internes.

Lorsque la déconnexion est effectuée, tous les jetons enregistrés sur le serveur pour le sujet considéré sont effacés. le (ou les) cookies SLI restent sur les agents, mais ne fonctionnent plus, et se périmerons d’eux-mêmes.

Ré-authentification silencieuse (Silent Re-Authentication, SRA)

Cette fonctionnalité, qui fait souvent appel à de nombreux développements du côté des applications, résulte directement du SLI.
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 un jeton d’accès.