Gestion des sessions OIDC

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 en fonction 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 semblable à REST.

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 la connexion 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 OIDC est crucial. Cet article explique comment les sessions OIDC et le statut d'authentification des utilisateurs sont gérés dans le cadre des interactions entre le fournisseur d'identité (IdP) et le participant de confiance (RP) ou fournisseur de services (SP).

Cet article inclut plusieurs termes clés.

• Fournisseur d'identité (IdP) : Le service qui stocke et authentifie les identités des utilisateurs.
• Fournisseur de services (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.
• Grant : 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.
• Connexion unique (SSO) : Un service de session et d'authentification des utilisateurs 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 gestion des sessions OIDC et du statut d'authentification des utilisateurs, passons brièvement en revue 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 la 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 être authentifié.
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 d'autorisation pour l'utilisateur.
7. Le fournisseur OIDC redirige l'utilisateur vers le RP avec un code d'authentification (flux du code d'autorisation).
8. Le RP reçoit le code d'authentification et l'échange contre des jetons pour accéder aux informations de l'utilisateur.

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

Une session de connexion est établie lorsque l'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 d'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 indicateurs HttpOnly et Secure pour empêcher l'accès côté client et garantir une communication sécurisée.

Une session pour un seul RP#

Pour chaque RP auquel l'utilisateur accède à partir de 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, il restera authentifié sur les autres RP jusqu'à ce que la session expire ou que l'utilisateur se déconnecte de tous les RP.

Session centralisée pour plusieurs RP#

Cette gestion centralisée des sessions permet également à l'IdP de maintenir un état d'authentification cohérent sur plusieurs RP 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 de SSO, où l'utilisateur peut accéder à plusieurs RP sans avoir à se reconnecter.

Statut d'authentification côté client#

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

• Jeton d'identité : Un jeton de courte durée qui contient des informations sur l'utilisateur et est utilisé pour vérifier l'identité de l'utilisateur authentifié.
• Jeton d'accès : 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 de courte ou longue durée, 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 est expiré ou supprimé, l'utilisateur peut être considéré comme "déconnecté" ou "non authentifié" et doit se réauthentifier.
• Jeton de rafraîchissement : Si la portée offline_access est demandée et accordée, l'application cliente peut recevoir un jeton de rafraîchissement. Il permet de prolonger le statut d'authentification de l'utilisateur sans nécessiter sa réauthentification. 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 interaction de l'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 de manière sécurisée et gérer leur cycle de vie. (Par exemple, pour les applications SPA, les jetons peuvent être stockés dans le stockage local ou le stockage de session du navigateur. 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 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 un utilisateur côté client est relativement simple. L'application cliente peut supprimer les jetons stockés (jeton d'identité, jeton d'accès et jeton de rafraîchissement) du navigateur ou de la mémoire de l'utilisateur. 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. Celles-ci incluent la suppression 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 aux nouveaux jetons d'être émis à l'application cliente sans nécessiter d'interaction supplémentaire 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 garantit une déconnexion complète de toutes les applications (RP) partageant la 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 l'un des RP liés partageant la même session, l'IdP demandera à l'utilisateur de se réauthentifier.

Déconnexion back-channel OIDC#

Dans certains cas, lorsqu'un utilisateur se déconnecte d'une application (RP), il peut également souhaiter être automatiquement déconnecté de toutes les autres applications (RP) sans interaction supplémentaire de l'utilisateur. Cela peut être accompli en utilisant le mécanisme de déconnexion back-channel.

Lorsque l'IdP reçoit une demande de déconnexion d'un RP, il efface non seulement la session de connexion mais envoie également une notification de déconnexion back-channel à tous les RP utilisant la même session et ayant un point de terminaison back-channel de déconnexion enregistré.

Lorsque les RP reçoivent la notification de déconnexion back-channel, ils peuvent effectuer les actions nécessaires pour effacer la session de l'utilisateur et les jetons, garantissant que l'utilisateur est entièrement déconnecté de toutes les applications.