Mise en œuvre de la déconnexion et de la gestion des sessions OIDC : Un guide complet

Qu'est-ce que la gestion des sessions OIDC#

OpenID Connect (OIDC) est une couche d'identité simple construite sur le protocole OAuth 2.0. Il permet aux clients de vérifier l'identité de l'utilisateur final sur la base de l'authentification effectuée par le serveur d'autorisation, ainsi que d'obtenir des informations de profil de base sur l'utilisateur final de manière interopérable et similaire à REST.

L'OIDC est conçu pour être facile à utiliser et à mettre en œuvre, avec un accent sur la simplicité et la flexibilité. Il est largement utilisé pour l'authentification unique (SSO) et la vérification d'identité dans les applications web, les applications mobiles et les API.

Comprendre le statut d'authentification et la gestion des sessions dans l'OIDC est crucial. Cet article explique comment les sessions OIDC et le statut d'authentification des utilisateurs sont gérés dans le contexte des interactions entre le fournisseur d'identité (IdP) et la partie de confiance (RP) ou fournisseur de service (SP).

Cet article comprend plusieurs termes clés.

• Fournisseur d'identité (IdP) : Le service qui stocke et authentifie les identités des utilisateurs.
• Fournisseur de service (SP) ou Partie de confiance (RP) : Une application web ou un service qui fournit des services aux utilisateurs et s'appuie sur l'IdP pour l'authentification des utilisateurs.
• Session de connexion ou Session d'authentification : La session qui est établie lorsqu'un utilisateur se connecte à l'IdP.
• Consentement : Les informations centralisées d'authentification et d'autorisation de l'utilisateur qui sont générées et gérées par l'IdP.
• Authentification unique (SSO) : Un service de session et d'authentification utilisateur qui permet à un utilisateur d'utiliser un ensemble d'identifiants de connexion (par exemple, nom et mot de passe) pour accéder à plusieurs applications.

Comment fonctionne le flux d'authentification OIDC#

Pour mieux comprendre la session OIDC et la gestion du statut d'authentification utilisateur, examinons brièvement le flux d'authentification OIDC pour une application web:

1. L'utilisateur accède à l'application web (RP).
2. Le RP redirige l'utilisateur vers le fournisseur OIDC (IdP) pour l'authentification.
3. Le fournisseur OIDC vérifie le statut de session de connexion de l'utilisateur. Si aucune session n'existe ou si la session a expiré, l'utilisateur est invité à se connecter.
4. L'utilisateur interagit avec la page de connexion pour s'authentifier.
5. La page de connexion soumet le résultat de l'interaction au fournisseur OIDC.
6. Le fournisseur OIDC crée une nouvelle session de connexion et un consentement d'authentification pour l'utilisateur.
7. Le fournisseur OIDC redirige l'utilisateur vers le RP avec un code d'authentification (flux de code d'autorisation).
8. Le RP reçoit le code d'authentification et l'échange contre des jetons pour accéder aux informations utilisateur.

Qu'est-ce que la gestion des sessions de connexion RP#

Une session de connexion est établie lorsqu'un utilisateur se connecte à l'IdP. Cette session est utilisée pour suivre le statut d'authentification de l'utilisateur à l'IdP. La session inclut généralement des informations telles que l'identité de l'utilisateur, l'heure de l'authentification et l'heure d'expiration de la session. Elle est créée lorsque l'utilisateur se connecte pour la première fois et est maintenue jusqu'à ce que l'utilisateur se déconnecte ou que la session expire.

Un cookie de session sera sécurisé dans le navigateur de l'utilisateur pour maintenir l'état de la session. Le cookie de session est utilisé pour identifier la session de l'utilisateur et authentifier l'utilisateur pour les demandes d'authentification ultérieures. Ce cookie est généralement configuré avec les attributs HttpOnly et Secure pour empêcher l'accès côté client et garantir une communication sécurisée.

Une session pour un RP unique#

Pour chaque RP auquel l'utilisateur accède depuis différents appareils ou navigateurs, une session de connexion utilisateur distincte sera établie. Cela signifie que le statut d'authentification de l'utilisateur est maintenu séparément pour chaque RP. Si l'utilisateur se déconnecte d'un RP, l'utilisateur sera toujours authentifié sur les autres RPs jusqu'à ce que la session expire ou que l'utilisateur se déconnecte de tous les RPs.

Session centralisée pour plusieurs RPs#

Cette gestion centralisée des sessions permet également à l'IdP de maintenir un état d'authentification cohérent à travers plusieurs RPs tant que la session de l'utilisateur est active et que les demandes d'authentification proviennent du même agent utilisateur (appareil/navigateur). Ce mécanisme permet des capacités SSO, où l'utilisateur peut accéder à plusieurs RPs sans avoir à se reconnecter.

Statut d'authentification côté client#

Dans OIDC, l'application client (RP) repose sur les jetons émis par l'IdP pour vérifier l'identité de l'utilisateur et le statut d'authentification ou d'autorisation. La "session de connexion" côté client est maintenue par les jetons émis par l'IdP.

• ID Token: Un jeton de courte durée qui contient des informations utilisateur et est utilisé pour vérifier l'identité de l'utilisateur authentifié.
• Access Token: Un jeton qui accorde l'accès aux ressources protégées au nom de l'utilisateur. La durée de vie du jeton d'accès peut être courte ou longue, selon la configuration. Les applications clientes peuvent se fier à la validité du jeton d'accès pour déterminer le statut d'authentification de l'utilisateur. Si le jeton d'accès a expiré ou a été effacé, l'utilisateur peut être considéré comme "déconnecté" ou "non authentifié" et doit se ré-authentifier.
• Refresh Token: Si la portée offline_access est demandée et accordée, l'application cliente peut recevoir un jeton de rafraîchissement. Cela fournit un moyen d'étendre le statut d'authentification de l'utilisateur sans nécessiter que l'utilisateur se ré-authentifie. L'application cliente peut utiliser le jeton de rafraîchissement pour obtenir un nouveau jeton d'accès lorsque le jeton d'accès actuel expire. Tant que le jeton de rafraîchissement est valide, le statut d'authentification de l'utilisateur peut être maintenu sans besoin d'interaction utilisateur.

La combinaison de ces jetons permet à l'application cliente de maintenir le statut d'authentification de l'utilisateur et d'accéder aux ressources protégées au nom de l'utilisateur. L'application cliente doit stocker ces jetons en toute sécurité et gérer leur cycle de vie. (Par exemple, pour les applications SPA, les jetons peuvent être stockés dans le stockage local du navigateur ou le stockage de session. Pour les applications web, les jetons peuvent être stockés dans les données de session côté serveur ou les cookies.)

Mécanismes de déconnexion OIDC#

Le processus de déconnexion dans OIDC est un concept à multiples facettes en raison de l'implication à la fois des sessions de connexion centralisées gérées par l'IdP et des jetons côté client distribués.

Effacer les jetons et la session locale côté client#

Déconnecter ou révoquer le statut d'authentification d'un utilisateur côté client est relativement simple. L'application cliente peut supprimer les jetons stockés (ID token, access token et refresh token) du navigateur de l'utilisateur ou de la mémoire. Cette action invalide effectivement le statut d'authentification de l'utilisateur côté client.

Pour les applications web qui gèrent leurs propres sessions de connexion utilisateur, des étapes supplémentaires peuvent être nécessaires. Cela inclut l'effacement du cookie de session et de toutes les données de session (telles que les jetons émis par le fournisseur d'identité, ou IdP) pour garantir que l'utilisateur est entièrement déconnecté.

Effacer la session de connexion centralisée à l'IdP#

L'IdP maintient une session de connexion centralisée pour chaque utilisateur. Tant que cette session est active, l'utilisateur peut être automatiquement ré-authentifié même si les jetons côté client ont été effacés, permettant ainsi de nouveaux jetons d'être émis à l'application cliente sans nécessiter d'interaction ultérieure avec l'IdP.

Pour déconnecter complètement un utilisateur de l'IdP, l'application cliente (RP) peut initier une demande de déconnexion à l'IdP. L'application (RP) doit rediriger l'utilisateur vers le point de terminaison de fin de session de l'IdP pour terminer la session de connexion et effacer les cookies de session. Cela assure une déconnexion complète à travers toutes les applications (RPs) partageant une même session centralisée. Une fois la session de connexion terminée, chaque fois que l'IdP reçoit une demande de jeton de la part de tout RP lié partageant la même session, l'IdP demandera à l'utilisateur de se ré-authentifier.

Déconnexion en back-channel OIDC#

Dans certains cas, lorsqu'un utilisateur se déconnecte d'une application (RP), il peut également vouloir être automatiquement déconnecté de toutes les autres applications (RPs) sans aucune interaction utilisateur supplémentaire. Cela peut être réalisé à l'aide du mécanisme de déconnexion en back-channel.

Lorsque l'IdP reçoit une demande de déconnexion d'un RP, il ne se contente pas de vider la session de connexion mais envoie également une notification de déconnexion en back-channel à tous les RPs utilisant la même session et ayant un point de terminaison de déconnexion en back-channel enregistré.

Lorsque les RPs reçoivent la notification de déconnexion en back-channel, ils peuvent effectuer les actions nécessaires pour effacer la session et les jetons de l'utilisateur, assurant ainsi que l'utilisateur est complètement déconnecté de toutes les applications.