Warum schlägt der Login immer wieder fehl? Cookies, SSO und gespeicherte Zugangsdaten richtig prüfen

Was beim Login technisch passiert: Cookies, Sessions, Tokens und SSO-Flows im Überblick

Ein Login wirkt an der Oberfläche wie ein einzelner Schritt, technisch besteht er jedoch aus mehreren Zuständen, die sich über Browser, Server und oft auch über externe Identity Provider verteilen. Genau diese Verteilung erklärt, warum ein „falsches Passwort“ nur eine von vielen möglichen Ursachen ist. Entscheidend ist, welche Komponente den aktuellen Anmeldestatus hält: ein Cookie im Browser, eine serverseitige Session, ein signiertes Token oder ein föderierter SSO-Kontext, der über mehrere Domains hinweg gilt.

Viele Störungen entstehen nicht beim Prüfen der Zugangsdaten selbst, sondern danach: beim Speichern des Sitzungskontexts, beim Erneuern abgelaufener Tokens oder beim Wiederverwenden alter Informationen aus Browser-Speichern. Wer Login-Probleme eingrenzen will, muss deshalb das Modell aus „Client-Zustand“ und „Server-Zustand“ trennen und die jeweiligen Lebensdauern (Expiry) sowie Bindungen an Gerät, Browser-Profil oder Netzwerkumgebung berücksichtigen.

Cookies und Sessions: Zustände zwischen Browser und Server

Das klassische Web-Login basiert auf einer serverseitigen Session, die über ein Cookie referenziert wird. Nach erfolgreicher Authentifizierung erzeugt der Server eine Session-ID und sendet sie als Cookie an den Browser. Bei jedem weiteren Request liefert der Browser dieses Cookie an die passende Domain zurück; der Server lädt die dazugehörige Session aus Speicher oder Datenbank und erkennt den Benutzer wieder. Bricht diese Kette, wirkt es nach außen wie ein „unerklärlicher Logout“ oder ein Login, der sich im Kreis dreht.

Cookie-Attribute bestimmen, wann und wohin der Browser den Wert sendet. Domain und Path begrenzen die Reichweite; Secure erlaubt Versand nur über HTTPS; HttpOnly schützt vor Zugriff aus JavaScript; SameSite steuert, ob Cookies in Cross-Site-Kontexten mitgesendet werden. Gerade SameSite=Lax oder SameSite=Strict kann SSO- und Redirect-Flows beeinflussen, wenn ein Dienst während des Logins über andere Domains springt und dabei auf Cookies angewiesen ist.

Sessions haben zusätzlich serverseitige Timeouts, die unabhängig vom Cookie-Ablauf sind. Selbst mit „gültigem“ Cookie kann die zugehörige Session bereits gelöscht sein (Idle-Timeout, Neustart, Speicherbereinigung). Umgekehrt kann ein Cookie ablaufen, obwohl die Session noch existiert, was den Nutzer aus Sicht des Browsers abmeldet.

Tokens (JWT & Co.): Signierte Ansprüche statt Session-ID

Viele moderne Dienste verwenden Tokens, häufig als JSON Web Token (JWT) oder als opaque Access Token. Statt einer zufälligen Session-ID trägt ein Token selbst Informationen (Claims) oder eine Referenz, die der Server prüft. Typisch ist ein Setup aus Access Token (kurzlebig) und Refresh Token (längerlebig), um ohne erneute Passworteingabe neue Access Tokens zu erhalten. Fehlerbilder entstehen, wenn ein Access Token abläuft und die Erneuerung scheitert, etwa weil der Refresh Token widerrufen wurde oder nicht mehr zum aktuellen Client-Kontext passt.

Token-Laufzeiten sind bewusst kurz, um Risiko zu begrenzen. Deshalb wirken Uhrzeitabweichungen (Client-Clock-Skew), strenge Gültigkeitsfenster oder Token-Bindungen an bestimmte Faktoren besonders stark. Manche Systeme binden Tokens an einen bestimmten Client-Kontext (z. B. per Proof-of-Possession-Mechanismen), andere invalidieren Tokens nach Passwortänderung, Policy-Update oder Sicherheitsereignissen. Ein „Login klappt, aber nach Minuten folgen 401/403“ ist in tokenbasierten Architekturen oft ein Erneuerungsproblem, kein Authentifizierungsproblem.

SSO-Flows: Redirect-Ketten, Identitätsanbieter und Vertrauensbeziehungen

Single Sign-On entkoppelt die Anmeldung vom eigentlichen Webdienst. Der Dienst (Service Provider / Relying Party) delegiert die Authentifizierung an einen Identity Provider (IdP). Technisch läuft das meist über Redirects: Der Browser wird zum IdP geschickt, dort entsteht eine eigene Session (oft ein IdP-Cookie), und anschließend kehrt der Browser mit einer einmaligen Antwort zum Dienst zurück. Je nach Standard kommen SAML 2.0 (XML-basiert), OpenID Connect (OIDC auf OAuth 2.0) oder proprietäre Varianten zum Einsatz.

In OIDC ist ein wiederkehrendes Muster: Der Dienst startet eine Authorization Request, erhält einen Authorization Code und tauscht diesen serverseitig gegen Tokens. Zusätzlich dienen Parameter wie state (CSRF-Schutz) und nonce (Replay-Schutz) der Integrität. Wenn Browser-Tracking-Schutz, Cookie-Regeln oder Content-Security-Policies einzelne Schritte blockieren, fällt der Flow häufig mit generischen Meldungen aus, obwohl die Credentials korrekt waren. In SAML-Setups treten ähnliche Effekte auf, etwa wenn die Assertion abläuft, die Uhrzeiten zwischen Systemen driften oder die Audience nicht exakt zum Service Provider passt.

Wichtig ist die Trennung der Abmeldeebenen: „Logout“ beim Dienst entfernt in vielen Implementierungen nur die lokale Session oder löscht lokale Cookies. Das SSO-Login beim IdP bleibt bestehen, sodass ein erneuter Aufruf sofort wieder zu einer gültigen Identität führt. SAML Single Logout (SLO) oder OIDC RP-Initiated Logout existieren, sind aber nicht überall vollständig umgesetzt und hängen stark von korrekten Redirect-URIs, Session-Management und Browser-Cookie-Policies ab.

Browser-Speicher, Passwortmanager und parallele Sitzungen

Neben Cookies halten Browser weitere Zustände, die Login- und SSO-Verhalten beeinflussen: localStorage und sessionStorage für clientseitige Token-Caches, IndexedDB für größere Daten (z. B. Offline-Apps) oder Speicher-Partitionierungen, die je nach Browser-Version und Schutzmechanismen variieren. Einige SDKs speichern Token oder Zwischenzustände in Web Storage; das beschleunigt Logins, kann aber zu inkonsistenten Zuständen führen, wenn alte Daten zurückkehren (Profil-Synchronisation, Restore von Tabs, Wiederherstellung nach Crash).

Passwortmanager greifen in den Ablauf ein, ohne selbst Teil des Protokolls zu sein. Autofill kann falsche Benutzernamen in Mehrkonto-Szenarien eintragen oder auf einer SSO-Login-Seite die lokale Dienst-Anmeldung mit einer IdP-Anmeldung verwechseln. Gespeicherte Anmeldedaten lösen außerdem nicht das Problem abgelaufener Tokens oder widerrufener Sessions; sie beschleunigen nur den Schritt „Credentials eingeben“, nicht den Zustand danach.

• Cookie-Ebene (Browser): Versand nur bei passender Domain/Route und korrekten Attributen wie SameSite, Secure und HttpOnly; Blockaden durch Tracking-Schutz führen oft zu Redirect-Loops.
• Session-Ebene (Dienst): serverseitige Session kann vorzeitig enden (Idle-Timeout, Server-Restart, Invalidation nach Policy-Änderung), auch wenn das Cookie noch vorhanden ist.
• Token-Ebene (API/OIDC): Access Tokens laufen kurz; Erneuerung hängt am Refresh Token und an Bindungen wie Client-Kontext, Widerruf oder Zeitfenstern (Claims wie exp und nbf).
• SSO-Ebene (IdP): IdP-Session bleibt häufig bestehen; lokales Logout ohne IdP-Logout führt zu sofortigem Wiederanmelden beim nächsten Login-Versuch.
• Mehrgeräte- und Mehrkonto-Effekte: parallele Logins können „letzte Anmeldung gewinnt“-Regeln auslösen, Refresh Tokens rotieren oder alte Sessions invalidieren; Symptome zeigen sich als wiederholte Re-Authentifizierung trotz korrekter Daten.

Parallele Sitzungen sind besonders fehleranfällig, wenn Sicherheitsrichtlinien Refresh Tokens rotieren und ältere Refresh Tokens ungültig werden. Dann kann ein zweites Gerät durch eine Hintergrund-Erneuerung das erste Gerät „abschneiden“, das anschließend mit einem nicht mehr gültigen Tokenbestand arbeitet. Das wirkt wie sporadisches Ausloggen, ist aber eine Folge konsistenter Sicherheitsmechanismen. Technisch sauber trennen lassen sich solche Ursachen nur, wenn klar ist, welches Artefakt den Zustand hält und welche Komponente dessen Gültigkeit definiert.

Fehler eingrenzen: Browser-Speicher, Passwortmanager, Redirects und Token-Laufzeiten als typische Ursachen

Wiederkehrende Login-Fehler entstehen selten durch „falsches Passwort“ allein. Häufig kollidieren mehrere Zustände: veraltete Cookies, widersprüchliche Einträge in Web Storage, automatisch ausgefüllte Zugangsdaten aus Passwortmanagern, Redirect-Ketten zwischen Identitätsanbieter und Zielsystem sowie Token, deren Lebensdauer nicht mehr zur Sitzung passt. Eine saubere Eingrenzung beginnt mit der Frage, ob der Fehler an einem Gerät, an einem Browser-Profil oder kontoübergreifend auftritt, und ob der Zustand nach einem vollständigen Neuanmelden reproduzierbar bleibt.

Browser-Speicher: Cookies, Local Storage und Session Storage als Fehlerquelle

Viele Webdienste speichern den „eingeloggt“-Zustand nicht nur serverseitig, sondern stützen ihn auf Browserdaten. Cookies tragen oft Session-IDs; localStorage und sessionStorage enthalten Zustände von Single-Page-Apps, CSRF-Token, Feature-Flags oder Hinweise, welcher Identity Provider zuletzt genutzt wurde. Problematisch wird es, wenn ein Cookie erneuert wird, der zugehörige Storage-Eintrag aber alt bleibt – oder umgekehrt. In der Praxis äußert sich das als Endlosschleife zwischen Login-Seite und App, als sporadische 401/403-Fehler nach erfolgreicher Anmeldung oder als „Sie sind abgemeldet“-Meldung direkt nach dem Redirect zurück zur Anwendung.

Für die Eingrenzung zählt Präzision: Das Löschen „aller Browserdaten“ ist als erster Schritt zu grob, weil es auch Cache und Historie entfernt und damit Reproduzierbarkeit erschwert. Sinnvoller ist das gezielte Entfernen von Website-Daten für genau die betroffenen Domains (inklusive Subdomains). Bei SSO-Szenarien sind typischerweise mindestens zwei Zonen beteiligt: die Domain des Webdienstes und die Domain des Identity Providers. Zusätzlich können CDN- oder API-Subdomains Cookies setzen, die nur auf den ersten Blick „fremd“ wirken, technisch aber zum Authentifizierungsfluss gehören.

Passwortmanager und gespeicherte Anmeldedaten: Auto-Fill kann den falschen Flow erzwingen

Passwortmanager und Browser-Autofill beschleunigen Logins, können aber auch Fehlzustände stabilisieren. Typisch ist das Befüllen eines Login-Formulars, das nicht mehr zum aktuellen Identitätsfluss passt: Ein Dienst wechselt von Benutzername/Passwort auf passwortlose Anmeldung, von einem alten Tenant auf einen neuen, oder er nutzt eine andere Login-URL. Dann wird zwar „korrekt“ ausgefüllt, aber inhaltlich falsch. Auch mehrere gespeicherte Einträge für ähnliche URLs (https://app.example vs. https://login.app.example) können dazu führen, dass im falschen Kontext Credentials angeboten werden.

Bei SSO ist außerdem relevant, ob der Passwortmanager die Anmeldung am Identity Provider oder am Service Provider übernimmt. Wird am Service Provider ein Formular befüllt, obwohl eigentlich ein Redirect zum Identity Provider stattfinden sollte, entsteht häufig ein Bruch im Ablauf. Für die Analyse sollte daher geprüft werden, ob eine Eingabe wirklich erforderlich ist oder ob eine automatische Weiterleitung erwartet wird. In Unternehmensumgebungen kommen zusätzlich Passkey-Prompts und integrierte Systemdialoge hinzu, die getrennt vom klassischen Passwortspeicher funktionieren.

• Mehrdeutige Speicherstellen trennen: Gespeicherte Einträge für ähnliche Origins bereinigen, insbesondere Kombinationen wie https://dienst.example und https://login.dienst.example, sowie alte Redirect-Endpunkte wie https://dienst.example/auth/callback.
• Auto-Fill testweise deaktivieren: Kurzzeitig automatische Formularbefüllung im Passwortmanager oder Browser abschalten, um zu prüfen, ob der Fehler ohne Einfüllen reproduzierbar bleibt; danach gezielt den korrekten Eintrag neu speichern.
• Konten- und Tenant-Mismatch erkennen: Wenn nach erfolgreichem Login falsche Daten erscheinen, ist häufig ein gespeichertes Konto am Identity Provider aktiv; ein echter Wechsel erfordert oft Logout am IdP und das Entfernen der zugehörigen Cookies.

Redirects, Callback-URLs und Fehlkonfigurationen im Auth-Flow

Redirect-Probleme wirken wie „Login geht nicht“, sind aber häufig Transport- oder Validierungsfehler: Die Anwendung startet den Auth-Flow, der Identity Provider authentifiziert, danach scheitert der Rückweg. Ursachen sind inkonsistente oder veraltete Callback-/Redirect-URLs, falsche Protokolle (HTTP/HTTPS), Domain-Wechsel oder zusätzliche Parameter, die der Dienst erwartet. Auch Reverse-Proxies können Redirects umschreiben und damit den Vergleich zwischen registrierter Redirect-URI und tatsächlicher URL brechen. Viele IdPs reagieren dann mit generischen Fehlseiten oder leiten ohne sichtbare Erklärung zurück zur Login-Seite.

Zur Eingrenzung hilft ein Blick auf die Navigation: Bleibt die Adresse im Browser während des Fehlers beim Identity Provider stehen, ist die Rückleitung blockiert; springt sie mehrfach zwischen idp.example und dienst.example, deutet das auf Cookie-/SameSite-Probleme oder nicht akzeptierte Rückgabeparameter hin. Entwicklertools mit Netzwerk-Ansicht zeigen zudem, ob der Callback mit 400, 401 oder 403 beantwortet wird und ob Set-Cookie-Header verworfen werden. In restriktiven Browserprofilen (Tracking-Schutz, Content Blocker) ist das Verwerfen von Auth-Cookies ein häufiges Muster, das nur bei Cross-Site-Redirects sichtbar wird.

Token-Laufzeiten und parallele Sitzungen: Wenn „gültig“ nicht mehr „brauchbar“ bedeutet

SSO-basierte Dienste arbeiten in der Regel mit kurzlebigen Access Tokens und langlebigeren Refresh Tokens oder serverseitigen Sessions. Ein Login kann technisch „erfolgreich“ sein, während die Anwendung unmittelbar danach ein abgelaufenes Access Token wiederverwendet, weil ein Cache oder Storage-Eintrag nicht aktualisiert wurde. Umgekehrt kann ein Refresh Token serverseitig widerrufen werden (etwa nach Passwortänderung, Sicherheitsrichtlinie oder administrativem Logout), während der Browser noch den alten Zustand präsentiert. Das Ergebnis sind wiederholte Re-Authentifizierungen, die scheinbar „grundlos“ auftreten, oft erst nach einem Wechsel zwischen Geräten oder nach Standby/Resume.

Parallele Sitzungen verschärfen das Bild: Einige Dienste erlauben mehrere aktive Sessions, andere erzwingen „Single Session“ pro Konto oder pro Gerätetyp. Meldet sich ein Konto auf einem zweiten Gerät an und der Dienst invalidiert die vorherige Session, bleibt auf dem ersten Gerät ein lokaler „eingeloggt“-Status bestehen, bis die nächste API-Anfrage scheitert. Typische Indikatoren sind Fehler direkt nach dem Öffnen eines Tabs am Folgetag, Zugriff nur nach hartem Reload oder eine Anmeldung, die klappt, aber bei der ersten Aktion wieder abbricht.

• Token-Zustand gegen Zeit abgleichen: Auftreten nach festen Intervallen (z. B. nach Standby oder nach mehreren Stunden) deutet auf Ablauf von Access Tokens und fehlgeschlagenes Refresh hin; die Prüfung erfolgt über DevTools-Network und Statuscodes wie 401 unmittelbar nach /token– oder /session-Aufrufen.
• Widerruf vs. Ablauf unterscheiden: Wiederholte invalid_grant-Antworten am Token-Endpunkt (IdP-abhängig) sprechen eher für widerrufene Refresh Tokens als für reine Zeitüberschreitung; dann ist ein vollständiger Logout am Identity Provider erforderlich.
• Multi-Device-Effekt prüfen: Wenn der Fehler nur auf einem Gerät auftritt, während ein zweites Gerät stabil bleibt, liegt häufig eine inkonsistente Sitzung vor; Abhilfe schafft das Beenden aller Sessions im Konto-Portal (falls vorhanden) und anschließend ein Neustart des Browserprofils.

Sauber neu authentifizieren: vollständiges Logout, parallele Sessions auf mehreren Geräten und kontrollierte Bereinigung

Wiederkehrende Login-Probleme lassen sich häufig erst dann eindeutig einordnen, wenn eine Neu-Authentifizierung tatsächlich „sauber“ erfolgt. In der Praxis scheitert das daran, dass ein Logout nur lokal wirkt, nur eine von mehreren Sitzungen beendet oder ein Single-Sign-On (SSO) weiterhin eine gültige IdP-Sitzung nutzt. Zusätzlich bleiben Artefakte im Browser-Speicher zurück, die nach einer erneuten Anmeldung dieselben Fehler erneut auslösen. Eine kontrollierte Bereinigung reduziert diese Nebenwirkungen, ohne unnötig Daten zu zerstören.

Was „vollständiges Logout“ in SSO-Umgebungen tatsächlich bedeutet

Bei klassischen Logins endet eine Sitzung oft mit dem Löschen eines Session-Cookies. In SSO-Setups existieren jedoch mindestens zwei Ebenen: die Anwendungssitzung (Service Provider) und die Sitzung beim Identity Provider (IdP). Ein Logout, der nur die Anwendungssitzung beendet, kann beim nächsten Aufruf unmittelbar wieder eine stille Anmeldung auslösen, sobald der IdP noch eine aktive Sitzung besitzt. Umgekehrt kann ein Logout beim IdP zwar neue Token-Ausstellungen verhindern, während parallel noch lokal gecachte Access Tokens in der Anwendung wirken, bis sie ablaufen oder serverseitig widerrufen werden.

Technisch relevant sind dabei Logout-Arten, die Anbieter unterschiedlich umsetzen: Front-Channel-Logout (Browser wird zu Logout-Endpunkten umgeleitet), Back-Channel-Logout (Server-to-Server-Signal) und Single Logout (SLO) über mehrere Services. Häufige Fehlerbilder entstehen, wenn eine Ebene erfolgreich abgemeldet ist, die andere jedoch nicht, oder wenn ein Logout-Endpunkt zwar Sitzungen beendet, der Browser aber weiterhin Cookies für eine andere Subdomain oder ein anderes Kontext-Path mitführt.

Parallele Sessions: mehrere Geräte, mehrere Browserprofile, mehrere Tabs

Parallele Sitzungen sind kein Sonderfall, sondern Standard: Smartphone, Laptop, Firmenrechner, dazu private und verwaltete Browserprofile. Je nach Sicherheitsdesign führen mehrere aktive Sessions zu Inkonsistenzen. Manche Dienste erlauben mehrere gleichzeitige Sessions pro Konto; andere erzwingen „Single Session“ und invalidieren beim neuen Login die vorherige Sitzung. Wird dann auf dem alten Gerät weiter gearbeitet, entstehen sporadische 401/403-Fehler, unerwartete Re-Auth-Prompts oder fehlgeschlagene Formularaktionen, weil CSRF-Token an eine inzwischen ungültige Sitzung gebunden sind.

Zusätzliche Komplexität entsteht, wenn ein Tab noch einen veralteten Authentifizierungszustand hält, während ein anderer Tab bereits neu angemeldet wurde. Moderne Webapps speichern Tokens oder Sessionindikatoren in localStorage oder sessionStorage und synchronisieren via storage-Events nicht immer zuverlässig über alle Kontexte hinweg. Auch Service Worker können Requests abfangen und mit gecachten Headern oder Offline-Strategien versehen, was Fehlersuche ohne gezielte Bereinigung erschwert.

• Geräteinventar festlegen: Alle aktiven Zugänge identifizieren (z. B. Desktop-Browser, mobiles Web, native App), weil Sitzungen und Token parallel weiterlaufen können, auch wenn der Browser abgemeldet wirkt.
• Browserkontext trennen: Tests in einem frischen Profil oder Private-Window durchführen, um Einflüsse aus Erweiterungen, altem Cache und vorhandenen Cookies zu isolieren; bei Chromium-basierten Browsern ist ein separates Profil dem Mischbetrieb in einem Fenster vorzuziehen.
• Tab-Synchronität prüfen: Nach Logout/Login alte Tabs schließen und die Anwendung nur aus einem neu geladenen Tab heraus öffnen, um veraltete In-Memory-States und alte Authorization-Header zu vermeiden.
• Serverseitige Session-Liste nutzen: Wenn der Dienst eine Übersicht aktiver Sitzungen anbietet, dort gezielt Sessions beenden („Sign out of all devices“); das ist wirksamer als lokales Cookie-Löschen, wenn serverseitig widerrufen wird.

Kontrollierte Bereinigung: weniger „alles löschen“, mehr zielgerichtet

Ein vollständiges Entfernen aller Browserdaten wirkt zwar oft, vernichtet jedoch auch Diagnoseinformationen und führt in verwalteten Umgebungen zu Nebeneffekten (erneute MFA-Anmeldung, Abmeldung aus anderen Diensten). Zielführender ist eine abgestufte Bereinigung: zuerst nur die betroffene Site, dann schrittweise angrenzende Identitäts- und SSO-Domains. Wichtig ist die Unterscheidung zwischen Cookies (Session- und Persistenzcookies), Web Storage (localStorage/sessionStorage), IndexedDB (oft für App-/Auth-Caches in SPAs) und Service-Worker-Cache.

Für SSO-Fehlerbilder lohnt ein Blick auf Cookie-Scopes: Cookies können für example.com oder nur für app.example.com gesetzt sein, außerdem mit SameSite, Secure und HttpOnly restriktiv konfiguriert. Ein Logout, der nur Cookies einer Subdomain entfernt, kann deshalb wirkungslos bleiben. Ebenso können zwei getrennte Umgebungen (Produktiv/Test) kollidieren, wenn beide unter ähnlichen Domains laufen und Cookie-Namen identisch sind, aber unterschiedliche Signierschlüssel verwenden.

• Site-Daten der Anwendung löschen: In den Browser-Einstellungen gezielt Daten für die betroffene Origin entfernen (Cookies, „Website-Daten“); dadurch verschwinden typische Reste wie alte state-Parameter, App-spezifische Token-Caches und fehlerhafte Session-Cookies, ohne den gesamten Browser zu bereinigen.
• SSO/IdP-Domain zusätzlich bereinigen: Wenn SSO verwendet wird, auch die Daten der IdP-Origin entfernen (z. B. https://login.microsoftonline.com oder eine Unternehmens-IdP-Domain), falls ein lokales Logout immer wieder durch eine bestehende IdP-Sitzung übersteuert wird.
• Service Worker deaktivieren/entfernen: Bei hartnäckigen Schleifen den Service Worker der Site entfernen, weil gecachte App-Shells oder alte Assets Auth-Flows beeinflussen können; Indikator sind wiederkehrende Requests trotz Cache-Löschung.
• Erweiterungen als Störfaktor isolieren: Login-Interferenzen durch Privacy-Tools, Script-Blocker oder Passwortmanager-Overlays ausschließen, indem der Test in einem sauberen Profil ohne Add-ons erfolgt; besonders relevant bei geblockten Third-Party-Cookies oder umgeschriebenen Headern.

Neu anmelden, aber richtig: Reihenfolge und typische Stolpersteine

Nach der Bereinigung entscheidet die Reihenfolge über ein reproduzierbares Ergebnis. Zunächst sollte eine serverseitige Abmeldung vorhandener Sitzungen erfolgen, sofern verfügbar, erst danach die lokale Bereinigung. Anschließend sollte der Login aus einem frischen Browserkontext erfolgen, damit der Auth-Flow nicht aus alten Redirect-Ketten oder gespeicherten Formularzuständen gespeist wird. Bei Konten mit mehreren Identitäten (privat/geschäftlich, mehrere Tenants) hilft es, vor dem erneuten Login Auswahl-Dialoge nicht zu überspringen, sondern bewusst die erwartete Identität zu wählen; ansonsten führt SSO häufig in das zuletzt aktive Konto zurück.

Gespeicherte Anmeldedaten und AutoFill können die Diagnose verzerren. Wird ein falscher Benutzername automatisch eingetragen oder ein altes Passwort ungefragt eingefügt, wirken Fehlermeldungen wie „Konto gesperrt“ oder „Ungültige Anmeldedaten“ wie ein Serverproblem, obwohl lokal falsche Daten reproduziert werden. Auch passwortlose Verfahren (Passkeys/WebAuthn) können auf einem Gerät erfolgreich, auf einem anderen jedoch nicht verfügbar sein; dann erscheint der Login inkonsistent, obwohl er lediglich an eine Gerätemethode gebunden ist.