Accueil > OpenID Connect OAuth Server par DnC > Développer > OpenID Connect > API OpenID Connect : Logout

API OpenID Connect : Logout

Le point d’extrémité logout permet la déconnexion "unique" (Single Logout, SLO) à partir d’une application (front channel single logout, RP generated logout etc.) : toutes les connexions d’un utilisateur sur les différentes applications sont invalidées.

Implémentation de la déconnexion

ll n’y a pas à ce jour (fin 2018) de "norme" définissant la déconnexion pour OpenID Connect. Pour s’en convaincre, il suffit de voir cet article très complet : OpenID Connect Logout et de considérer l’état d’avancement de la proposition de norme : Draft : Management de session OpenID Connect. Les nombreuses références à des propositions de standard (drafts) et la complexité des solutions proposées montrent la difficulté dans laquelle se trouve la communauté Openid pour adopter une solution. DnC propose pour OAuthSD une solution de déconnexion centralisée particulièrement simple s’appuyant sur le cookie SLI.

La déconnexion est générale (Single Logout, SLO) : toutes les connexions d’un utilisateur sur différentes applications sont invalidées.

Point d’extrémité de déconnexion unique (Single Logout Endpoint)

https://oa.dnc.global/logout

Forme de la demande de déconnexion unique

Une application effectue une demande de déconnexion comme une demande d’introspection en passant le jeton d’identité.

Le jeton est passé avec le paramètre "token" par l’une des méthodes suivantes : Auth Header, GET ou POST. Se reporter à API Open ID Connect : Introspection pour la description de l’appel.

Exemple d’appel :

  1. if ( $jwt['active'] == 'true' ) {
  2.  
  3.     // Post Methode  
  4.     $data1 = array(
  5.         'token' => $res['id_token'],
  6.     );
  7.  
  8.     // Effectuer un logout
  9.     $h = curl_init($logout_endpoint);
  10.     curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
  11.     curl_setopt($h, CURLOPT_TIMEOUT, 10);
  12.     curl_setopt($h, CURLOPT_POST, true);
  13.     curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));  
  14.     curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data1));
  15.  
  16.     $res = curl_exec($h);
  17.     curl_close($h);
  18.  
  19.     if  ( empty($res['error'] ) ) {
  20.         // Continuer avec la déconnexion locale
  21.         ...
  22.     } else {
  23.         // ne pas déconnecter localement, signaler l'erreur.
  24.         ...
  25.     }
  26.  
  27. } else
  28.     // JWT is inactive
  29.     exit('Error : Invactive ID Token');
  30. }

Télécharger

Réponse du serveur

En cas de succès, le serveur retourne une réponse HTTP 200. Tous les jetons d’accès enregistrés sur le serveur pour l’utilisateur final connecté à l’application 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.

Notons que, contrairement au mécanisme de SLI qui est attaché à un agent utilisateur (un navigateur sur un poste de travail), la déconnexion unique s’applique à tous les agents que l’utilisateur aurait utilisés pour se connecter à des applications puisque tous les jetons d’accès enregistrés pour cet utilisateur seront effacés.

En cas d’échec de la requête, le serveur n’effectue pas la déconnexion et retourne une réponse HTTP 403.

Connaître l’état de connexion d’une application

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 l’erreur ’login_required’ et un code HTTP 403. Cette solution a l’avantage de répondre totalement à la norme OpenID Connect dans son état définitif.

Discussion, alternative

Au reçu du code HTTP 200, l’application cliente à partir de laquelle a été émis la déconnexion pourra procéder à la déconnexion locale (probablement effacer des données de session et détruire un cookie de connexion etc.).

La question se pose pour les autres applications clientes que l’utilisateur aurait connectées précédemment.

Ces applications seront déconnectées (ne pourront se reconnecter automatiquement par Silent Re-Authentication (SRA)) à la fin de la validité de leur session locale. Même si elles apparaissent connectées, les requêtes qu’elles tenteront d’effectuer en direction des ressources protégées par le serveur OIDC n’aboutiront pas. Le retour d’erreur en résultant permettra au concepteur de l’application de prévoir une déconnexion locale.

Si la durée de la session locale de l’application cliente est courte, on aboutira à une déconnexion dans un délai court. A la limite, il existe des application sans session qui interrogent le serveur OIDC à chaque sollicitation pour authentifier la requête qui leur est faite. Les applications mono page et les services HTTP REST (sant état) appartiennent à cette catégorie.

Quoiqu’il en soit, le concepteur d’une application devrait intégrer un mécanisme de suivi de la validité du jeton d’accès pour informer l’utilisateur local et déconnecter localement l’application si le jeton est périmé. C’est l’objet de notre Monitoring de l’état de l’authentification et SLO. Le dispositif de Logout rentre ainsi dans le cadre du management de session.

Une alternative à notre méthode de déconnexion est décrite ici : Draft : Management de session OpenID Connect. Bien qu’il soit inscrit dans ce projet de spécification que la connaissance de l’état de connexion actuel d’une application (pour faire apparaître la déconnexion) peut être fait "sans générer de trafic sur le réseau", il n’en est rien car on "interroge l’OP ... à un intervalle approprié". La technique introduit donc un délai d’apparition de la déconnexion.

Notre méthode de déconnexion apparaît donc très intéressante, notamment si on considère sa simplicité de mise en oeuvre au regard des importantes modifications à apporter aux applications requises par le management de session OpenID Connect dont l’avenir, de plus, nous parait mal assuré.