Zum Hauptinhalt springen

Abmelden

Das Abmelden in Logto (als OIDC-Identitätsanbieter) umfasst sowohl:

  • Eine zentralisierte Logto-Sitzung (Browser-Cookie unter der Logto-Domain) als auch
  • Verteilten clientseitigen Auth-Status (Tokens und lokale App-Sitzung in jeder App).

Um das Abmeldeverhalten zu verstehen, hilft es, diese beiden Ebenen zu trennen und dann zu sehen, wie Grants sie verbinden.

Zentrale Konzepte​

Was ist eine Logto-Sitzung?​

Eine Logto-Sitzung ist der zentralisierte Anmeldestatus, der von Logto verwaltet wird. Sie wird nach erfolgreicher Authentifizierung erstellt und durch Cookies unter der Logto-Domain repräsentiert.

Wenn das Sitzungs-Cookie gültig ist, kann der Benutzer stillschweigend (SSO) über mehrere Apps hinweg authentifiziert werden, die demselben Logto-Tenant vertrauen.

Wenn keine gültige Sitzung existiert, zeigt Logto die Anmeldeseite an.

Was sind Grants?​

Ein Grant repräsentiert den Autorisierungsstatus für eine bestimmte Kombination aus Benutzer + Client-Anwendung.

  • Eine Logto-Sitzung kann Grants für mehrere Client-Apps haben.
  • Ein Grant ist das, womit ausgegebene Tokens verknüpft sind.
  • In dieser Dokumentation wird Grant als die bereichsübergreifende Autorisierungseinheit verwendet.

Wie hängen Sitzung, Grants und Client-Auth-Status zusammen?​

  • Logto-Sitzung steuert die zentralisierte SSO-Erfahrung.
  • Lokale Client-Sitzung / Tokens steuern, ob jede App den Benutzer aktuell als angemeldet behandelt.
  • Grants verbinden diese beiden Welten, indem sie den app-spezifischen Autorisierungsstatus repräsentieren.

Sign-in Rückblick (warum Sign-out mehrschichtig ist)​

Sitzungs-Topologie über Apps / Geräte hinweg​

Wenn sich ein Benutzer in mehreren Apps im selben Browser anmeldet, können diese Apps dasselbe Logto-Sitzungs-Cookie wiederverwenden und SSO-Verhalten gilt.

Isolierte Sitzungs-Cookies (verschiedene Geräte / Browser)​

Verschiedene Browser / Geräte halten unterschiedliche Logto-Cookies, daher ist der Anmeldestatus isoliert.

Abmelde-Mechanismen​

1) Nur clientseitiges Abmelden​

Die Client-App löscht ihre eigene lokale Sitzung und Tokens (ID- / Zugangstoken / Auffrischungstoken). Dadurch wird der Benutzer nur aus dem lokalen Zustand dieser App abgemeldet.

  • Die Logto-Sitzung kann weiterhin aktiv sein.
  • Andere Apps unter derselben Logto-Sitzung können weiterhin SSO nutzen.

2) End-Sitzung bei Logto (globales Abmelden in aktueller Logto-Implementierung)​

Um die zentralisierte Logto-Sitzung zu löschen, leitet die App den Benutzer zum End-Sitzung-Endpunkt weiter, zum Beispiel:

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

Im aktuellen Logto SDK-Verhalten:

  1. signOut() leitet zu /session/end weiter.
  2. Dann geht es zu /session/end/confirm.
  3. Das Standard-Bestätigungsformular sendet automatisch logout=true.

Dadurch wird das aktuelle SDK-Abmelden als globales Abmelden behandelt.

Was passiert beim globalen Abmelden​

Beim globalen Abmelden gilt:

  • Die zentralisierte Logto-Sitzung wird widerrufen.
  • Zugehörige App-Grants werden je nach Autorisierungsstatus der App behandelt:
    • Wenn offline_access nicht gewährt ist, werden die zugehörigen Grants widerrufen.
    • Wenn offline_access gewährt ist, werden Grants durch End-Sitzung nicht widerrufen.
  • Bei offline_access-Fällen bleiben Auffrischungstoken und Grants bis zum Ablauf des Grants gültig.

Grant-Lebensdauer und Auswirkung von offline_access​

  • Die Standard-Grant-TTL in Logto beträgt 180 Tage.
  • Wenn offline_access gewährt ist, wird der App-Grant durch End-Sitzung standardmäßig nicht widerrufen.
  • Die mit diesem Grant verknüpfte Auffrischungstoken-Kette kann weiterlaufen, bis der Grant abläuft (oder explizit widerrufen wird).

Föderiertes Abmelden: Back-Channel-Logout​

Für bereichsübergreifende Konsistenz unterstützt Logto Back-Channel-Logout.

Wenn sich ein Benutzer von einer App abmeldet, kann Logto alle Apps, die an derselben Sitzung teilnehmen, benachrichtigen, indem ein Logout-Token an jede registrierte Back-Channel-Logout-URI gesendet wird.

Wenn Is session required in den Back-Channel-Einstellungen der App aktiviert ist, enthält das Logout-Token sid, um die Logto-Sitzung zu identifizieren.

Typischer Ablauf:

  1. Benutzer startet Abmelden in einer App.
  2. Logto verarbeitet End-Sitzung und sendet Logout-Token(s) an registrierte Back-Channel-Logout-URI(s).
  3. Jede App validiert das Logout-Token und löscht ihre eigene lokale Sitzung / Tokens.

Abmelde-Methoden in Logto SDKs​

  • SPA und Web: client.signOut() löscht den lokalen Token-Speicher und leitet zum Logto-End-Sitzung-Endpunkt weiter. Du kannst eine Post-Logout-Redirect-URI angeben.
  • Native (einschließlich React Native / Flutter): löscht in der Regel nur den lokalen Token-Speicher. Sitzungslose Webviews bedeuten, dass kein persistentes Logto-Browser-Cookie gelöscht werden muss.
hinweis:

Für native Anwendungen, die keine sitzungslose Webview unterstützen oder die emphasized Einstellungen nicht erkennen (Android-App mit React Native oder Flutter SDK), kannst du den Benutzer zwingen, sich erneut anzumelden, indem du den Parameter prompt=login in der Authentifizierungsanfrage übergibst.

Erzwinge Re-Authentifizierung bei jedem Zugriff​

Für sicherheitskritische Aktionen füge prompt=login in Auth-Anfragen ein, um SSO zu umgehen und jedes Mal die Eingabe der Zugangsdaten zu erzwingen.

Wenn du offline_access anforderst (um Auffrischungstoken zu erhalten), füge auch consent, prompt=login consent hinzu.

Typische kombinierte Einstellung:

prompt=login consent

FAQs​

Ich erhalte keine Back-Channel-Logout-Benachrichtigungen.​

  • Stelle sicher, dass die Back-Channel-Logout-URI korrekt im Logto-Dashboard registriert ist.
  • Stelle sicher, dass deine App einen aktiven Anmeldestatus für denselben Benutzer / Sitzungs-Kontext hat.

OIDC Back-Channel-Logout verstehen.