Déconnexion

Le processus de déconnexion dans Logto (en tant que fournisseur d'identité basé sur OIDC) est un concept à multiples facettes en raison de l'implication à la fois de la session de connexion centralisée gérée par Logto et de l'état d'authentification distribué géré par les applications clientes.

Session de connexion

Pour mieux comprendre le processus de déconnexion, il est important de comprendre d'abord comment les sessions de connexion des utilisateurs et leur état d'authentification sont gérés dans Logto.

1. L'utilisateur accède à l'application web (RP).
2. L'application cliente redirige l'utilisateur vers Logto (IdP) pour l'authentification.
3. Le fournisseur OIDC vérifie l'état 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 s'authentifier.
5. Après une connexion réussie, Logto crée une nouvelle session pour l'utilisateur et redirige vers l'application cliente avec un code d'autorisation.
6. Le fournisseur OIDC crée une nouvelle session de connexion et une autorisation d'authentification pour l'utilisateur.
7. Le fournisseur OIDC redirige l'utilisateur vers le client avec un code d'authentification (flux de code d'autorisation).
8. Le client reçoit le code d'authentification et l'échange contre des jetons pour accéder aux informations de l'utilisateur.
9. Accorder des jetons à l'application cliente.

Composants

Session de connexion centralisée gérée par Logto

Dans le flux ci-dessus, la session de connexion centralisée est gérée par Logto. La session est créée lorsque l'utilisateur se connecte avec succès et est détruite lorsque l'utilisateur se déconnecte. La session est également détruite lorsque la session de l'utilisateur expire.

La session de connexion Logto est gérée à l'aide de cookies de session. Le cookie de session est défini lorsque l'utilisateur se connecte. Toutes les requêtes d'authentification sont validées par rapport au cookie de session. Si le cookie de session est présent et valide, l'utilisateur sera automatiquement authentifié et redirigé directement vers l'application cliente avec le code d'autorisation. Sinon, l'utilisateur sera invité à se connecter.

1. Cookie de session Logto partagé Pour un utilisateur qui se connecte à plusieurs applications clientes depuis le même agent utilisateur (par exemple, un navigateur), l'utilisateur aura un cookie de session partagé sous le domaine Logto. Cela signifie que l'utilisateur n'a besoin de se connecter qu'une seule fois et sera automatiquement authentifié pour d'autres applications clientes.

2. Cookie de session Logto isolé Pour un utilisateur qui se connecte à différentes applications clientes depuis différents appareils ou navigateurs, l'utilisateur aura des cookies de session isolés sous le domaine Logto. Cela signifie que l'utilisateur doit se connecter séparément pour chaque application cliente.

État d'authentification distribué géré par les applications clientes

Chaque application cliente maintient son propre état d'authentification. Qu'il s'agisse d'une application native, SPA ou web, toutes ont leur propre manière de gérer l'état d'authentification de l'utilisateur.

Après une connexion réussie, l'application cliente peut recevoir un jeton d’identifiant (ID token) et un jeton d’accès (access token). L'application cliente peut utiliser le jeton d’identifiant pour déterminer l'identité de l'utilisateur et le jeton d’accès pour accéder aux ressources de l'utilisateur. L'état d'authentification de l'utilisateur est représenté par le temps d'expiration du jeton d’accès.

• Applications natives et SPA : L'application cliente doit stocker et gérer ces jetons de manière sécurisée afin de maintenir l'état d'authentification de l'utilisateur. Par exemple, stocker les jetons dans le stockage local ou le stockage de session, et effacer les jetons lorsque l'utilisateur se déconnecte.
• Applications web : Les applications web, comme celles construites avec des frameworks comme Next.js, gèrent souvent leur propre session pour les utilisateurs connectés en plus des jetons émis par Logto. Une fois que l'utilisateur se connecte et que l'application web reçoit les jetons de Logto, elle peut stocker les jetons côté client comme les applications SPA, ou elle peut stocker les jetons côté serveur et gérer la session à l'aide de cookies ou d'autres mécanismes.

Mécanismes de déconnexion

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

Côté client, une simple déconnexion implique d'effacer la session locale et de supprimer les jetons (jeton d’identifiant, jeton d’accès, jeton de rafraîchissement) du stockage local ou du stockage de session. Cela entraîne une déconnexion uniquement côté client où la session centralisée reste intacte. Les utilisateurs qui se déconnectent de cette manière peuvent encore accéder à d'autres applications sous la même session du serveur d'autorisation jusqu'à ce que la session centralisée expire ou soit activement détruite.

Effacer la session de connexion chez Logto

Pour déconnecter explicitement l'utilisateur et effacer la session chez Logto, l'application cliente doit rediriger l'utilisateur vers le point de terminaison de fin de session de Logto.

Par exemple : https://{votre-domaine-logto}/oidc/session/end

Le point de terminaison de fin de session est un point de terminaison OIDC standard qui permet à l'application cliente de notifier le serveur d'autorisation que l'utilisateur s'est déconnecté. Le point de terminaison effacera la session de connexion centralisée chez Logto.

Une fois la session effacée, toute demande d'autorisation ultérieure nécessitera que l'utilisateur se connecte à nouveau.

Si un URI de redirection post-déconnexion est fourni, l'utilisateur sera redirigé vers l'URI spécifié après que la session soit effacée. Sinon, l'utilisateur sera redirigé vers la page de redirection post-déconnexion par défaut hébergée par Logto.

Déconnexion fédérée : Déconnexion par canal secondaire

Pour une gestion de déconnexion plus cohérente, Logto prend en charge la déconnexion par canal secondaire. La déconnexion par canal secondaire est un mécanisme qui permet à Logto de notifier toutes les applications clientes sous la même session de connexion lorsque l'utilisateur se déconnecte.

Cela est particulièrement utile dans les scénarios où l'utilisateur se déconnecte d'une application cliente et s'attend à être déconnecté de toutes les autres applications clientes sous la même session de connexion Logto.

Pour activer la déconnexion par canal secondaire pour vos applications clientes, accédez à la page des détails de l'application dans le tableau de bord Logto et enregistrez un URI de déconnexion par canal secondaire. Logto enverra un jeton de déconnexion à tous les URI enregistrés lorsque l'utilisateur initie une demande de déconnexion depuis n'importe quelle application cliente.

Si votre application cliente nécessite que la session de connexion soit incluse dans le jeton de déconnexion, activez les paramètres Is session required dans la configuration de déconnexion par canal secondaire. Une revendication sid sera incluse dans le jeton de déconnexion pour identifier la session de connexion de l'utilisateur chez Logto.

1. L'utilisateur initie une demande de déconnexion depuis une application cliente.
2. Logto reçoit la demande de fin de session, génère un jeton de déconnexion et envoie le jeton de déconnexion à tous les URI de déconnexion par canal secondaire enregistrés.
3. Chaque application cliente reçoit le jeton de déconnexion et effectue des actions de déconnexion.

Actions de déconnexion pour chaque application cliente lors de la réception du jeton de déconnexion :

• Valider le jeton de déconnexion.
• Effacer la session locale et supprimer les jetons du stockage local ou du stockage de session.

Méthodes de déconnexion dans les SDK Logto

Si vous intégrez Logto avec votre application cliente en utilisant les SDK de Logto :

• Pour les applications SPA et web, la méthode client.signOut() effacera le stockage local des jetons et redirigera l'utilisateur vers le point de terminaison de fin de session de Logto. Vous pouvez spécifier un URI de redirection post-déconnexion pour rediriger l'utilisateur après que la session soit effacée.
• Pour les applications natives (y compris les applications hybrides comme React Native et Flutter), seul le stockage local des jetons est effacé. Cela est dû au fait que dans les applications natives, nous utilisons le webview sans session pour gérer le processus de connexion. Aucun cookie de session n'est stocké dans le navigateur natif, il n'est donc pas nécessaire d'effacer la session de connexion chez Logto. Chaque demande d'authentification est une demande autonome qui ne transporte aucun cookie de session.

remarque:

Pour les applications natives qui ne prennent pas en charge le webview sans session ou ne reconnaissent pas les paramètres emphasized (application Android utilisant le SDK React Native ou Flutter), vous pouvez forcer l'utilisateur à se reconnecter en passant le paramètre prompt=login dans la requête d'autorisation.

FAQs

Je ne reçois pas les notifications de déconnexion par canal secondaire.

• Assurez-vous que l'URI de déconnexion par canal secondaire est correctement enregistré dans le tableau de bord Logto.
• Assurez-vous que votre application cliente a une session de connexion active valide et qu'elle est la même que celle qui a initié la demande de déconnexion.

Ressources connexes

Comprendre la déconnexion par canal secondaire OIDC.