Aller au contenu principal

Déconnexion

La déconnexion dans Logto (en tant que fournisseur d'identité OIDC) implique à la fois :

  • Une session Logto centralisée (cookie de navigateur sous le domaine Logto), et
  • Un état d'authentification côté client distribué (jetons et session locale de l'application dans chaque application).

Pour comprendre le comportement de la déconnexion, il est utile de séparer ces deux couches puis de voir comment les grants les relient.

Concepts de base​

Qu'est-ce qu'une session Logto ?​

Une session Logto est l'état de connexion centralisé géré par Logto. Elle est créée après une authentification réussie et représentée par des cookies sous le domaine Logto.

Si le cookie de session est valide, l'utilisateur peut être authentifié silencieusement (SSO) sur plusieurs applications qui font confiance au même tenant Logto.

Si aucune session valide n'existe, Logto affiche la page de connexion.

Qu'est-ce qu'un grant ?​

Un grant représente l'état d'autorisation pour une combinaison utilisateur + application cliente spécifique.

  • Une session Logto peut avoir des grants pour plusieurs applications clientes.
  • Un grant est ce à quoi les jetons émis sont associés.
  • Dans cette documentation, utilisez grant comme unité d'autorisation inter-applications.

Comment la session, les grants et l'état d'authentification du client sont liés​

  • Session Logto contrôle l'expérience SSO centralisée.
  • Session locale / jetons du client contrôlent si chaque application considère actuellement l'utilisateur comme connecté.
  • Grants relient ces deux mondes en représentant l'état d'autorisation spécifique à l'application.

Récapitulatif de la connexion (pourquoi la déconnexion est multi-couches)​

Topologie des sessions entre applications / appareils​

Si un utilisateur se connecte à plusieurs applications depuis le même navigateur, ces applications peuvent réutiliser le même cookie de session Logto et le comportement SSO s'applique.

Cookies de session isolés (appareils / navigateurs différents)​

Des navigateurs / appareils différents détiennent des cookies Logto différents, donc l'état de session de connexion est isolé.

Mécanismes de déconnexion​

1) Déconnexion côté client uniquement​

L'application cliente efface sa propre session locale et ses jetons (jetons d’identifiant / d’accès / de rafraîchissement). Cela déconnecte l'utilisateur uniquement de l'état local de cette application.

  • La session Logto peut toujours être active.
  • D'autres applications sous la même session Logto peuvent toujours utiliser le SSO.

2) Fin de session sur Logto (déconnexion globale dans l'implémentation Logto actuelle)​

Pour effacer la session Logto centralisée, l'application redirige l'utilisateur vers l'endpoint de fin de session, par exemple :

https://{your-logto-domain}/oidc/session/end

Dans le comportement actuel du SDK Logto :

  1. signOut() redirige vers /session/end.
  2. Puis cela va vers /session/end/confirm.
  3. Le formulaire de confirmation par défaut envoie automatiquement logout=true.

En conséquence, la déconnexion via le SDK est traitée comme une déconnexion globale.

Que se passe-t-il lors d'une déconnexion globale​

Lors d'une déconnexion globale :

  • La session Logto centralisée est révoquée.
  • Les grants associés aux applications sont traités selon l'état d'autorisation de chaque application :
    • Si offline_access n'est pas accordé, les grants associés sont révoqués.
    • Si offline_access est accordé, les grants ne sont pas révoqués par la fin de session.
  • Pour les cas offline_access, les jetons de rafraîchissement et les grants restent valides jusqu'à expiration du grant.

Durée de vie du grant et impact de offline_access​

  • Le TTL par défaut d'un grant Logto est de 180 jours.
  • Si offline_access est accordé, la fin de session ne révoque pas ce grant d'application par défaut.
  • La chaîne de jetons de rafraîchissement associée à ce grant peut continuer jusqu'à expiration du grant (ou révocation explicite).

Déconnexion fédérée : back-channel logout​

Pour la cohérence inter-applications, Logto prend en charge le back-channel logout.

Lorsqu'un utilisateur se déconnecte d'une application, Logto peut notifier toutes les applications participant à la même session en envoyant un jeton de déconnexion à chaque URI de back-channel logout enregistré.

Si Is session required est activé dans les paramètres de back-channel de l'application, le jeton de déconnexion inclut sid pour identifier la session Logto.

Flux typique :

  1. L'utilisateur initie la déconnexion depuis une application.
  2. Logto traite la fin de session et envoie le(s) jeton(s) de déconnexion à l'(aux) URI(s) de back-channel logout enregistrée(s).
  3. Chaque application valide le jeton de déconnexion et efface sa propre session locale / ses jetons.

Méthodes de déconnexion dans les SDK Logto​

  • SPA et web : client.signOut() efface le stockage local des jetons et redirige vers l'endpoint de fin de session Logto. Vous pouvez fournir une URI de redirection post-déconnexion.
  • Natif (y compris React Native / Flutter) : efface généralement uniquement le stockage local des jetons. Le webview sans session signifie qu'il n'y a pas de cookie Logto persistant à effacer.
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 à saisir à nouveau ses identifiants en passant le paramètre prompt=login dans la requête d'autorisation.

Imposer la ré-authentification à chaque accès​

Pour les actions à haute sécurité, incluez prompt=login dans les requêtes d'authentification pour contourner le SSO et forcer la saisie des identifiants à chaque fois.

Si vous demandez offline_access (pour recevoir des jetons de rafraîchissement), incluez également consent, prompt=login consent.

Paramètre combiné typique :

prompt=login consent

FAQ​

Je ne reçois pas les notifications de back-channel logout.​

  • Vérifiez que l'URI de back-channel logout est correctement enregistrée dans le tableau de bord Logto.
  • Vérifiez que votre application a un état de connexion actif pour le même utilisateur / contexte de session.

Comprendre le back-channel logout OIDC.