API OpenID Connect : Logout (Logout Endpoint)

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.

Importance de la déconnexion unique pour la sécurité

La déconnexion unique (SLO) est la contrepartie de la connexion unique (SSO). L’authentification unique améliore l’expérience de l’utilisateur en minimisant le nombre de procédures de connexion et en lui permettant d’avoir des connexions ouvertes sur différentes applications sans avoir à fournir les informations d’identification à chaque fois.

Ce faisant, il existe un risque que l’utilisateur omette de se déconnecter d’une ou plusieurs applications, ce qui pourrait être exploité par un utilisateur malveillant. Avec la déconnexion unique, l’utilisateur peut mettre fin à toutes les sessions sans avoir à se déconnecter activement de chaque application, même si elles ont été ouvertes sur différents postes de travail ou mobiles. En conséquence, une application implémentant la déconnexion unique protège les utilisateurs et leurs données car il garantit qu’il ne reste aucune connexion active.

Implémentation de la déconnexion unique

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 : OpenID Connect Session Management. 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, différentes machines et quelque soit le lieu, 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 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 (Introspection Endpoint) pour la description de l’appel.

Exemple d’appel :

if ( $jwt['active'] == 'true' ) {
// Post Methode
$data1 = array(
'token' => $id_token,
);
// Effectuer un logout
$h = curl_init($logout_endpoint);
curl_setopt($h, CURLOPT_RETURNTRANSFER, true);
curl_setopt($h, CURLOPT_TIMEOUT, 10);
curl_setopt($h, CURLOPT_POST, true);
curl_setopt($h, CURLOPT_HTTPHEADER, array('Content-Type: application/x-www-form-urlencoded'));
curl_setopt($h, CURLOPT_POSTFIELDS, http_build_query($data1));
$res = curl_exec($h);
curl_close($h);
if ( empty($res['error'] ) ) {
// Continuer avec la déconnexion locale
...
} else {
// ne pas déconnecter localement, signaler l'erreur.
...
}
} else
// JWT is inactive
exit('Error : Invactive ID Token');
}

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.

NoPassConnect tire parti de cette fonctionnalité en permettant la déconnexion à distance à l’aide d’un mobile.

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 : OpenID Connect Session Management. 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é.