Warum kann ich mich bei einem Webdienst nicht mehr anmelden? Cookies, SSO und gespeicherte Logins systematisch prüfen

Was beim Login technisch passiert: Session-Cookies, Token, Refresh-Mechanismen und SSO-Flows

Vom Credential-Check zur Sitzung: Authentifizierung vs. Autorisierung

Technisch beginnt ein Login fast immer mit einer Authentifizierung: Ein Dienst prüft, ob ein Nachweis (Passwort, FIDO2/WebAuthn, Einmalcode, Client-Zertifikat) zu einem Konto passt. Erst danach folgt die Autorisierung: Der Dienst legt fest, welche Aktionen mit dieser Identität erlaubt sind. In modernen Webdiensten wird diese zweite Phase häufig nicht mehr über eine serverseitig „gemerkte“ Sitzung allein, sondern über Token abgebildet, die konkrete Berechtigungen, Zielgruppen (Audience) und Laufzeiten tragen.

Viele Probleme, die als „Login fehlgeschlagen“ erscheinen, entstehen nicht beim Passwortcheck, sondern danach: Ein Browser sendet alte Cookies mit, ein Access-Token ist abgelaufen, ein Refresh-Token wurde rotiert, oder ein SSO-Provider liefert zwar eine Identität, aber der Ziel-Dienst lehnt die Session wegen fehlender Claims oder falscher Zeitsynchronisation ab. Entscheidend ist, welche Zustandsinformation wo gespeichert wird: im Browser (Cookies, Storage), in einer App (Secure Storage/Keychain) oder serverseitig (Session Store, Token-Blacklist/Revocation-Liste).

Session-Cookies im Detail: Domain, SameSite, Secure und Lebensdauer

Session-Cookies sind Browser-Cookies, die entweder nur bis zum Schließen des Browsers existieren oder ein Ablaufdatum besitzen. Der Browser sendet Cookies nur, wenn Domain und Pfad passen und wenn Sicherheitsattribute die Übertragung erlauben. Relevante Attribute sind Secure (nur über HTTPS), HttpOnly (nicht über JavaScript auslesbar) sowie SameSite, das steuert, ob Cookies in Cross-Site-Kontexten mitgeschickt werden.

SSO- und Identitätsflüsse sind häufig Cross-Site: Ein Login startet auf app.example, springt zu login.idp.example und kehrt zurück. Wenn ein Dienst dabei auf Cookies angewiesen ist, können restriktive SameSite-Einstellungen oder Browserregeln für Drittanbieter-Cookies den Rücksprung beeinflussen. Moderne Browser behandeln Drittanbieter-Cookies zunehmend restriktiv; in solchen Setups muss die Anwendung entweder auf First-Party-Mechanismen ausweichen oder den Flow so gestalten, dass die notwendigen Cookies in einem First-Party-Kontext gesetzt werden.

• Domain- und Subdomain-Bindung: Ein Cookie für app.example gilt nicht automatisch für api.example; ein Cookie mit Domain=.example kann Subdomains einschließen, wird aber bewusst nicht immer verwendet.
• SameSite-Verhalten: SameSite=Lax erlaubt Cookies in manchen Top-Level-Navigationsfällen, blockiert aber viele eingebettete oder skriptgetriebene Cross-Site-Requests; SameSite=None erfordert Secure und ist bei strengen Anti-Tracking-Einstellungen dennoch riskant.
• Session-Fixierung und Invalidierung: Dienste rotieren Session-IDs nach erfolgreicher Authentifizierung; parallele Tabs können dann ein altes Cookie weiterverwenden, bis der Browser das neue Cookie übernommen hat oder der Server das alte hart verwirft.
• Clock Skew und Ablauf: Bei serverseitigen Sessions sind Timeouts oft „sliding“ (verlängern sich bei Aktivität) oder „absolute“ (harter Endzeitpunkt); bei verteilten Systemen kann eine fehlerhafte Zeitbasis die Wahrnehmung „plötzlich ausgeloggt“ verstärken.

Token-basierte Logins: JWT, Scopes und Refresh-Token-Rotation

Bei tokenbasierter Authentifizierung erhält der Client nach erfolgreichem Login typischerweise ein Access-Token. Dieses Token ist häufig kurzlebig und trägt Informationen wie exp (Ablauf), aud (Ziel), iss (Aussteller) und Berechtigungen in Form von Scopes oder Claims. Der Vorteil liegt in klaren Laufzeiten und einer eindeutigen Bindung an einen Aussteller; der Nachteil ist, dass Fehlkonfigurationen schnell in harte Ablehnungen münden.

Damit eine Sitzung ohne erneuten interaktiven Login bestehen kann, kommt ein Refresh-Token oder ein vergleichbarer Mechanismus zum Einsatz. Viele Provider setzen auf Refresh-Token-Rotation: Bei jeder Erneuerung wird ein neues Refresh-Token ausgegeben, das alte verliert sofort seine Gültigkeit. Das reduziert Missbrauch, hat aber Nebenwirkungen in Multi-Device- oder Multi-Tab-Szenarien. Wenn zwei Geräte oder zwei Browserprofile dasselbe Konto nutzen, kann ein Refresh auf Gerät A den Refresh-Token auf Gerät B „veralten“ lassen, sofern die Implementierung Token an eine konkrete Client-Instanz bindet oder Reuse Detection aktiviert ist.

Ein weiteres Fehlerbild entsteht, wenn ein Access-Token zwar erneuert wurde, aber zwischengeschaltete Caches oder Service Worker noch mit altem Autorisierungsheader arbeiten. Bei SPAs ist zudem die Wahl des Speichers relevant: Tokens im localStorage überleben Browserneustarts, sind aber bei XSS-Risiken problematischer; Cookies mit HttpOnly sind schwerer auszulesen, erfordern jedoch saubere CSRF-Strategien und korrekte SameSite-Konfiguration.

SSO-Flows (OIDC/SAML): Redirects, State/Nonce und Session-Kopplung

Single-Sign-On verbindet mindestens zwei Sitzungen: die Session beim Identitätsanbieter (IdP) und die Session beim Service Provider (SP) beziehungsweise der Anwendung. Bei OpenID Connect (OIDC) läuft der Browser über Redirects, die an registrierte Redirect-URIs gebunden sind. Parameter wie state schützen vor CSRF und binden die Rückkehr an die ursprünglich gestartete Anmeldung; nonce bindet ein ID-Token an die konkrete Authentifizierungsanfrage und verhindert Replay.

Typische Bruchstellen liegen an den Grenzen zwischen IdP, Browser und Anwendung: Ein Tab startet den Flow, ein anderer Tab überschreibt den gespeicherten state; ein Content-Blocker entfernt Query-Parameter; strikte Cookie-Regeln verhindern, dass die IdP-Session im Hintergrund erkannt wird; oder die Anwendung erwartet bestimmte Claims (z. B. Gruppen, Mandant, amr-Werte), die der IdP in einer bestimmten Policy nur unter Bedingungen liefert. Auch Logout ist im SSO-Kontext nicht trivial: Ein Logout in der Anwendung beendet nicht zwingend die IdP-Session, und umgekehrt kann eine IdP-Session fortbestehen, sodass der nächste Login „ohne Passwort“ erfolgt, obwohl der lokale Zustand bereits bereinigt wurde.

• Redirect-URI-Mismatch: Wenn die Rücksprungadresse nicht exakt registriert ist (Schema, Host, Pfad), lehnt der IdP den Flow ab; häufig sichtbar an Fehlern wie redirect_uri_mismatch.
• State/Nonce-Verlust: Tab-Wechsel, harte Reloads oder strikte Speicherbereinigung können den erwarteten state-Eintrag entfernen; der IdP liefert dann zwar eine Antwort, die Anwendung verwirft sie als nicht zuordenbar.
• SSO-Session vs. App-Session: Eine gültige IdP-Session kann eine neue App-Session erzeugen, auch wenn in der Anwendung „abgemeldet“ wurde; umgekehrt kann eine abgelaufene App-Session trotz gültiger IdP-Session zu Schleifen führen, wenn Token-Refresh oder Silent Login scheitert.
• Front-Channel- und Back-Channel-Logout: Je nach Implementierung wird Logout über Browser-Redirects (Front-Channel) oder serverseitige Benachrichtigung (Back-Channel) propagiert; fehlende Unterstützung führt zu „Phantom-Logins“ oder noch aktiven Sitzungen auf anderen Geräten.

Parallelität und Geräteeffekte: Mehrere Tabs, Geräte und Profile als Fehlerverstärker

Parallele Sitzungen verändern den Ablauf, ohne dass sich an den Zugangsdaten etwas ändert. Mehrere Tabs teilen sich Cookies, konkurrieren aber um gespeicherte Transaktionsdaten wie state oder PKCE-Verifier, wenn diese unglücklich im sessionStorage oder in einem globalen In-Memory-Store liegen. Mehrere Geräte teilen sich diese Zustände nicht, können jedoch über serverseitige Regeln gekoppelt sein: Ein Anbieter kann Refresh-Token je Client beschränken, Sitzungen pro Konto limitieren oder bei sicherheitsrelevanten Ereignissen (Passwortwechsel, MFA-Reset) alle Tokens widerrufen.

Auch Browserprofile und Passwortmanager spielen indirekt hinein. Ein Passwortmanager kann zwar korrekt ausfüllen, aber ein bestehender SSO-Status entscheidet, welcher Account tatsächlich verwendet wird. Wenn ein IdP bereits mit einem anderen Konto angemeldet ist, setzt ein erneuter App-Login ohne erzwungene Kontoauswahl oft auf diese bestehende Identität. Technisch ist das kein „falsches Passwort“, sondern eine bereits etablierte IdP-Session, die den Flow deterministisch in Richtung des eingeloggten Kontos lenkt.

Fehlerquellen sauber isolieren: Browser-Speicher, Cookie-Regeln, Passwortmanager und parallele Sitzungen

Wiederkehrende Login-Probleme wirken oft zufällig, folgen aber meist einer klaren Ursache: Ein Browser sendet unerwartete Cookies, ein Token liegt noch im lokalen Speicher, ein Passwortmanager überschreibt Eingaben oder eine parallele Sitzung auf einem zweiten Gerät verändert den Serverzustand. Eine saubere Isolation trennt diese Ebenen, bis eindeutig feststeht, ob der Fehler im Client (Browser/Endgerät), im Identitätsfluss (SSO/OAuth/OIDC) oder auf der Serverseite (Session-Handling, Richtlinien, Accountzustand) entsteht.

Browser-Speicher trennen: Cookies, Cache, Local Storage und Service Worker

Für die Anmeldung sind nicht nur Cookies relevant. Moderne Web-Apps halten Zustände in Local Storage oder Session Storage, speichern Refresh-Informationen in IndexedDB und betreiben Offline-Logik über Service Worker. Ein reines „Cache leeren“ behebt deshalb viele Fälle nicht, während ein vollständiges Entfernen von Website-Daten oft sofort wirkt. Wichtig ist außerdem die Abgrenzung zwischen Profilen: Ein zweites Browser-Profil oder ein privates Fenster startet ohne bestehende Cookies und ohne die meisten Speicherartefakte, ist aber kein Ersatz für das Löschen persistenter Website-Daten, wenn Service Worker oder IndexedDB beteiligt sind.

Typische Symptome unterscheiden sich: Ein sofortiger Redirect zurück zur Login-Seite deutet auf fehlende oder zurückgewiesene Session-Cookies hin. Ein erfolgreicher Login, gefolgt von 401/403 bei API-Aufrufen, passt eher zu einem Access-Token, das abgelaufen ist oder nicht zu den angeforderten Ressourcen passt. Endlos-Schleifen zwischen IdP und Anwendung entstehen häufig, wenn Zustandsparameter zwar im Frontend erzeugt, aber im Browser nicht korrekt persistiert werden (blockierte Cookies, Inkonsistenz zwischen Subdomains, falsche SameSite-Regeln).

Cookie-Regeln und Tracking-Schutz: SameSite, Partitionierung, Drittanbieter-Cookies

SSO-Flows sind häufig Cross-Site: Anwendung und Identity Provider (IdP) liegen auf unterschiedlichen Domains. Seit Jahren verschärfen Browser das Cookie-Verhalten. Cookies ohne explizites SameSite werden in vielen Fällen wie SameSite=Lax behandelt; ein Cookie, das in einem eingebetteten Kontext oder beim Redirect benötigt wird, muss oft SameSite=None; Secure tragen. Zusätzlich blockieren Tracking-Schutzmechanismen in manchen Konstellationen Drittanbieter-Cookies komplett oder partitionieren sie pro „Top-Level-Site“. Das betrifft besonders Login-Seiten, die innerhalb eines iFrames geladen werden oder stille Token-Erneuerung über versteckte Frames nutzen.

Auch Domain- und Pfad-Scoping entscheidet: Ein Cookie mit Domain=login.example.com ist auf app.example.com nicht verfügbar; ein zu eng gesetzter Path kann verhindern, dass der Browser es bei API-Aufrufen mitsendet. Umgekehrt können „verwaiste“ Cookies auf der Parent-Domain (Domain=.example.com) einen neuen Login sabotieren, wenn parallel ein altes Cookie mit gleicher Bezeichnung existiert und je nach Pfad/Domain priorisiert wird.

• Cross-Site-Flow prüfen: In den DevTools unter Network die Redirect-Kette verfolgen und im Request-Header Cookie sowie im Response-Header Set-Cookie kontrollieren; auffällig sind fehlende Secure-Flags bei SameSite=None oder Cookies, die wegen Richtlinien als „blocked“ markiert sind.
• Blocker ausschließen: Für einen Test Browser-Erweiterungen, Tracking-Schutz-Ausnahmen oder Enterprise-Policies als Ursache isolieren, indem ein sauberes Profil ohne Add-ons genutzt wird und die Anwendung außerhalb von iFrames geladen wird (direkter Aufruf der URL statt eingebetteter Startseiten).
• Cookie-Kollisionen erkennen: In der Cookie-Übersicht identische Namen mit unterschiedlichen Domain/Path prüfen; im Zweifel nur die Website-Daten der betroffenen Domains löschen statt „alles“, um Nebenwirkungen zu begrenzen.

Passwortmanager und Autofill: falsche Konten, falsche Felder, verdeckte Überschreibungen

Passwortmanager reduzieren Fehler, erzeugen aber eigene: Ein gespeichertes Login für eine ähnliche URL wird automatisch vorgeschlagen und unbemerkt übernommen. Bei SSO ist außerdem relevant, dass die Anwendung häufig zwischen lokalem Login und IdP-Login umschaltet; Autofill kann dann Felder befüllen, die im nächsten Schritt nicht mehr gelten, oder nach dem Absenden die Eingaben erneut überschreiben. Auch Sonderfälle wie mehrere Tenants/Organisationen unter derselben Domain führen dazu, dass ein korrektes Passwort im falschen Konto landet und die Plattform daraufhin Sperr- oder Rate-Limit-Mechanismen triggert.

Zur Isolation eignet sich ein Test ohne Autofill: Browser-internes Autofill deaktivieren und den Passwortmanager für die betroffene Domain temporär pausieren. Bleibt der Fehler bestehen, liegt er wahrscheinlicher in Cookies/Tokens oder im Accountzustand. Verschwindet er, sollten gespeicherte Einträge konsolidiert werden (korrekte URL, korrekter Benutzername, keine Duplikate), insbesondere wenn mehrere Subdomains oder Regionen genutzt werden.

• Gespeicherte URL präzisieren: Einträge auf die tatsächlich genutzte Login-URL begrenzen (z. B. https://login.example.com statt https://example.com), um Fehlzuordnungen zwischen App- und IdP-Seite zu vermeiden.
• Autofill-Übernahmen sichtbar machen: Nach dem Laden der Login-Seite prüfen, ob sich Feldwerte ohne Eingabe ändern; bei Bedarf den Eintrag im Manager neu speichern und alte Datensätze löschen.
• Mehrkonten-Fälle entschärfen: Pro Konto getrennte Einträge mit eindeutigem Benutzernamen (inkl. Suffix wie user@firma.tld) pflegen, wenn der Dienst verschiedene Identitäten unter derselben Domain zulässt.

Parallele Sitzungen und Gerätewechsel: Token-Rotation, Session-Invalidierung, „Logout überall“

Parallele Logins auf mehreren Geräten beeinflussen sich je nach Dienst erheblich. Manche Systeme erlauben mehrere gleichzeitige Sessions, andere begrenzen auf eine aktive Sitzung pro Benutzer oder pro Clienttyp. Bei strenger Session-Politik kann ein Login am Smartphone die Session am Desktop invalidieren; die Desktop-App wirkt dann „angemeldet“, scheitert aber bei der nächsten API-Anfrage. Bei OAuth/OIDC kommt hinzu, dass Refresh-Token teils rotiert werden: Wird ein Refresh-Token auf Gerät A verwendet und danach ein alter Token auf Gerät B erneut genutzt, kann der IdP aus Sicherheitsgründen beide Ketten ungültig machen.

Eine saubere Eingrenzung erfordert deshalb kontrollierte Bedingungen: Nur ein Gerät aktiv, alle anderen Sitzungen abmelden, dann Schritt für Schritt wieder parallelisieren. Wenn ein Dienst Funktionen wie „Sitzungen verwalten“ oder „Überall abmelden“ anbietet, ist diese Option bei schwer nachvollziehbaren Effekten oft der schnellste Reset, weil sie serverseitig invalidiert und nicht nur lokal Cookies löscht. Anschließend sollten Browser-Daten für App und IdP konsistent entfernt werden, damit keine alten Cookies oder gespeicherten Zustände sofort wieder eine ungültige Session referenzieren.

Wenn parallelisierte Sitzungen zuverlässig Fehler erzeugen, liefert das ein starkes Indiz für serverseitige Sicherheitslogik (Session-Limits, Token-Rotation, Risikoprüfungen) statt lokaler Browserdefekte. Umgekehrt sprechen reproduzierbare Probleme in einem einzelnen Profil, die im frischen Profil verschwinden, klar für lokale Persistenz: Cookies, Storage oder Autofill. Die Trennung dieser Achsen verhindert, dass mehrere Maßnahmen gleichzeitig ergriffen werden und die eigentliche Ursache im Rauschen verschwindet.

Wann „vollständig abmelden“ nötig ist: Token-Widerruf, Single-Logout, Gerätebindung und kontrollierte Bereinigung

„Abmelden“ ist in vielen Webdiensten kein einzelner Schalter, sondern eine Kette aus Aktionen: Session-Cookie wird gelöscht, Refresh-Token wird ungültig gemacht, SSO-Sitzung beim Identity Provider (IdP) wird beendet, und gerätespezifische Vertrauensstellungen werden zurückgesetzt. Login-Probleme entstehen häufig, wenn nur ein Teil dieser Kette greift. Ein sichtbarer Logout im Frontend kann daher trügerisch sein, wenn der Browser unmittelbar wieder eine gültige IdP-Sitzung oder ein weiter gültiges Refresh-Token nutzt.

„Vollständig abmelden“ bedeutet in diesem Kontext: lokale Artefakte (Cookies, Storage, Cache) werden gezielt entfernt und serverseitig werden Token und Sitzungen so widerrufen, dass eine erneute Anmeldung tatsächlich eine neue Authentifizierung erzwingt. Das wird vor allem dann erforderlich, wenn widersprüchliche Zustände zwischen Gerät, Browserprofil, IdP und Service Provider (SP) entstanden sind.

Token-Widerruf und Laufzeiten: Warum ein Logout nicht sofort „wirkt“

Moderne Authentifizierung basiert oft auf kurzlebigen Access-Tokens (z. B. JWT) und langlebigeren Refresh-Tokens. Ein Logout im Dienst kann lediglich das aktuelle Access-Token verwerfen; ist ein Refresh-Token weiter gültig, stellt der Client im Hintergrund neue Access-Tokens aus, ohne dass eine erneute Passworteingabe erscheint. Umgekehrt kann ein Dienst serverseitig Token widerrufen, während im Browser noch UI-Elemente „angemeldet“ signalisieren, bis der nächste API-Aufruf scheitert.

Hinzu kommt: Nicht jeder Token ist jederzeit widerrufbar. JWTs werden häufig aus Performancegründen ohne zentrale Session-State-Prüfung akzeptiert; ein Widerruf funktioniert dann nur über zusätzliche Mechanismen wie Token-Blacklist, verkürzte Gültigkeitsdauern, „logout_at“-Claims oder eine Pflicht zur Introspektion. In solchen Architekturen ist „vollständig abmelden“ weniger ein sofortiger Schnitt als das Erzwingen eines Zustands, in dem keine Erneuerung mehr möglich ist (Refresh-Token invalid) und der Browser keine gültige SSO-Sitzung mehr besitzt.

Single Logout: Grenzen zwischen Service Provider und Identity Provider

Bei SSO mit SAML oder OpenID Connect existieren mindestens zwei relevante Sitzungen: die Anwendungssitzung beim SP und die zentrale SSO-Sitzung beim IdP. Ein Logout-Link in der Anwendung beendet oft nur die SP-Sitzung. Der nächste Login-Button triggert dann eine SSO-Weiterleitung, und der IdP liefert ohne Interaktion sofort ein neues Assertion/Token zurück. Das wirkt wie ein „Logout, der nicht funktioniert“, ist aber in vielen Setups erwartetes Verhalten.

Single Logout (SLO) versucht, SP- und IdP-Sitzung gemeinsam zu beenden. In der Praxis scheitert SLO jedoch regelmäßig an technischen und organisatorischen Grenzen: mehrere SPs, fehlende Front-Channel-Erreichbarkeit, restriktive Third-Party-Cookie-Policies oder parallele Browser-Tabs mit noch aktiven Flows. Deshalb ist eine kontrollierte Bereinigung häufig die robustere Maßnahme, um einen klaren Ausgangszustand herzustellen.

• SP-Logout vs. IdP-Logout trennen: SP-Logout beendet nur die Anwendungssitzung; IdP-Logout erfordert eine IdP-Route wie https://idp.example/logout oder einen OIDC-Endpunkt wie https://idp.example/oidc/logout?id_token_hint=…&post_logout_redirect_uri=…
• Front-Channel-Einschränkungen beachten: SLO, das auf Browser-Weiterleitungen und Cookies basiert, kann durch Tracking-Schutz/Third-Party-Cookie-Blockaden ausgebremst werden; sichtbar wird das, wenn der Logout nur in einzelnen Browsern oder nur im privaten Fenster „richtig“ wirkt.
• Back-Channel-Logout ist nicht universell: OIDC Back-Channel-Logout existiert, wird aber nicht in jedem IdP/SP-Paar sauber umgesetzt; fehlende Unterstützung äußert sich als „ein Dienst bleibt angemeldet, andere nicht“ trotz zentralem Logout.

Gerätebindung, „Remember this device“ und parallele Sitzungen

Viele Dienste koppeln Anmeldungen an ein Gerät oder Browserprofil: über gerätespezifische Cookies, kryptografische Schlüssel (WebAuthn/Passkeys), Token-Bindung oder „Device IDs“ im Backend. Zusätzlich kommen MFA-„Remember“-Funktionen hinzu, die ein Gerät für einen Zeitraum als vertrauenswürdig markieren. Wenn sich Login-Probleme nur auf einem Gerät zeigen, spricht das häufig für eine beschädigte oder veraltete Gerätebindung, nicht für ein falsches Passwort.

Parallele Sitzungen verschärfen Inkonsistenzen: Wird das Passwort geändert oder ein Konto zurückgesetzt, bleiben bestehende Sessions auf anderen Geräten oft gültig, solange Refresh-Tokens nicht widerrufen werden. Manche Sicherheitsrichtlinien erzwingen umgekehrt einen globalen Logout; dann scheitern Geräte mit Offline- oder Sleep-Phasen beim nächsten Aufwachen mit schwer interpretierbaren Fehlern, weil lokale Tokens noch vorhanden sind, aber serverseitig bereits widerrufen wurden.

• Gerätevertrauen zurücksetzen (dienstseitig): In Account-Sicherheitsseiten finden sich häufig Aktionen wie Sign out of all sessions oder Revoke all refresh tokens; diese Maßnahmen sind wirksamer als ein lokales Browser-Logout, wenn ein Gerät „festhängt“.
• MFA-Remember gezielt entfernen: Einträge wie Trusted devices oder Remembered browsers sollten entfernt werden, wenn MFA unerwartet übersprungen wird oder ein Gerät trotz korrekter Anmeldung in eine MFA-Schleife gerät.
• Session-Kollisionen vermeiden: Gleichzeitige Logins in mehreren Konten desselben IdP in einem Browserprofil (z. B. privat/normal gemischt oder mehrere Tabs mit verschiedenen Mandanten) erzeugen leicht falsche Account-Zuordnungen, wenn Cookies domänenweit geteilt werden.

Kontrollierte Bereinigung: lokal aufräumen, ohne alles zu zerstören

Eine vollständige Abmeldung umfasst eine lokale Bereinigung, die zielgerichtet bleibt: Zuerst sollte nur die Site-spezifische Datenspur entfernt werden, nicht pauschal der gesamte Browser. Relevant sind Cookies (inklusive Subdomains), Local Storage/Session Storage und in manchen Fällen der Cache, wenn Logout-Redirects oder IdP-Metadaten falsch zwischengespeichert wurden. Bei SSO-Setups müssen zudem sowohl SP-Domain als auch IdP-Domain berücksichtigt werden, weil beide eigene Cookies setzen.

Eine kontrollierte Reihenfolge reduziert Nebenwirkungen: Zunächst alle Tabs des betroffenen Dienstes schließen, damit keine Hintergrundskripte sofort wieder Tokens erneuern. Danach Abmelden im Dienst, anschließend (falls vorhanden) Abmelden am IdP. Erst wenn der Zustand weiter „klebt“, folgt die Bereinigung der Site-Daten für beide Domains. Private Fenster eignen sich als Gegenprobe, weil dort keine Altlasten existieren; ist der Login dort stabil, liegt der Fehler mit hoher Wahrscheinlichkeit in gespeicherten Zuständen des regulären Profils.

• Site-Daten für SP löschen: In Browser-Einstellungen gezielt die Daten für https://app.example entfernen (Cookies und Website-Daten), statt „Alle Cookies“ zu löschen; bei Subdomains zusätzlich https://*.example prüfen, wenn der Browser diese Ansicht anbietet.
• Site-Daten für IdP löschen: Entsprechend die IdP-Domain bereinigen, z. B. https://login.example-idp.com; sonst führt ein erneuter Login sofort wieder über eine bestehende IdP-Sitzung in denselben Zustand zurück.
• Passwortmanager und AutoFill kontrollieren: Falsch zugeordnete Einträge (gleiche URL, unterschiedliche Mandanten) führen zu wiederholten Fehlanmeldungen; relevant sind gespeicherte Ziele wie https://tenantA.example vs. https://tenantB.example oder abweichende IdP-Redirect-URLs.
• Zwischengespeicherte Anmeldedaten des Betriebssystems prüfen: Unter Windows können Web-SSO-Komponenten und Apps Anmeldedaten im Credential Manager halten; das ist vor allem bei eingebetteten WebViews relevant, wenn Browser-Logout keine Wirkung zeigt, aber die Desktop-App sofort wieder Zugriff erhält.