Warum schlägt der Login im Webdienst immer wieder fehl? Cookies, SSO und gespeicherte Anmeldedaten systematisch prüfen

Was beim Login tatsächlich passiert: Session-Cookies, Local Storage, Tokens und Identity Provider

Ein Login wirkt oft wie ein einzelner Schritt, technisch entsteht jedoch eine Kette aus Weiterleitungen, Zustandswechseln und gespeicherten Artefakten im Browser. Ob ein Dienst „eingeloggt bleibt“, ob ein erneutes Passwort verlangt wird oder ob ein Konto „plötzlich das falsche“ ist, hängt weniger vom Formular selbst ab als von Session-Cookies, Token-Lebenszeiten, Browser-Speichern und der Rolle eines Identity Providers (IdP). Wer wiederkehrende Anmeldefehler eingrenzen will, braucht ein klares Bild davon, welche Komponente wofür zuständig ist.

Die Session im Browser: Cookie als Träger des Zustands

Klassische Webanwendungen verwalten den eingeloggten Zustand über eine serverseitige Session. Der Browser erhält nach erfolgreicher Anmeldung ein Cookie (häufig mit einer zufälligen Session-ID), das bei jeder weiteren Anfrage an die passende Domain automatisch mitgeschickt wird. Der Server ordnet diese Kennung einem Session-Objekt zu und erkennt so, dass die Anfrage zu einer bereits authentifizierten Sitzung gehört. Entscheidend ist: Das Cookie enthält in der Regel nicht das Passwort, sondern nur einen Verweis auf einen serverseitigen Zustand.

Für Fehlerbilder relevant sind Attribute wie Domain, Path, Secure, HttpOnly und SameSite. Ein Cookie mit Secure wird nur über HTTPS gesendet; ein falsch gesetztes Domain-Attribut kann dazu führen, dass Subdomains unerwartet dieselbe Session teilen oder gerade nicht teilen. SameSite beeinflusst, ob Cookies bei Cross-Site-Weiterleitungen (typisch bei SSO) übertragen werden; restriktive Einstellungen können Logins scheinbar „unterbrechen“, weil die Rückkehr zum Dienst ohne die erwarteten Cookies erfolgt.

Token statt Session: JWT, Access Token und Refresh Token

Moderne Dienste setzen häufig auf tokenbasierte Authentifizierung. Der Browser oder eine App erhält ein Access Token mit begrenzter Laufzeit, das bei API-Aufrufen als Authorization: Bearer … übermittelt wird. Zusätzlich existiert oft ein Refresh Token, mit dem sich neue Access Tokens beschaffen lassen, ohne dass erneut interaktiv ein Passwort eingegeben wird. Das Token kann als JWT (JSON Web Token) umgesetzt sein, muss es aber nicht; in beiden Fällen bleibt die Laufzeitlogik zentral: Access Tokens sind kurzlebig, Refresh Tokens länger, aber stärker geschützt und meist an zusätzliche Bedingungen gebunden (Gerätebindung, Token-Rotation, Widerruf).

Typische Störungen entstehen, wenn die Token-Uhr „auseinanderläuft“ (z. B. durch fehlerhafte Systemzeit), wenn ein Refresh Token serverseitig widerrufen wurde oder wenn Token-Rotation inkonsistent behandelt wird. Dann zeigt die Oberfläche mitunter „Login fehlgeschlagen“, obwohl die eigentliche Ursache ein abgelaufenes Access Token ist, das nicht erneuert werden kann. In SSO-Szenarien kann außerdem ein gültiger IdP-Login zwar neue Tokens liefern, die Anwendung nimmt sie aber nicht an, weil sie noch eine alte lokale Sitzung priorisiert.

Local Storage und Session Storage: Bequem, aber konfliktanfällig

Viele Single-Page-Apps speichern Authentifizierungszustand oder Hilfsdaten im localStorage oder sessionStorage (z. B. Token, Ablaufzeiten, „onboarding completed“-Marker, zuletzt gewähltes Konto). Diese Speicher sind nicht automatisch an HTTP-Anfragen gebunden wie Cookies, sondern werden per JavaScript gelesen und geschrieben. Das macht sie flexibel, aber auch störanfällig: Ein Tab kann einen Zustand aktualisieren, ein anderer Tab arbeitet noch mit alten Werten. Nach Updates der Anwendung bleiben alte Schlüssel liegen, die neue Logik falsch interpretiert. Im privaten Modus oder bei strengen Datenschutz-Einstellungen kann die Persistenz eingeschränkt sein; dann „vergisst“ eine App den Login nach einem Reload.

Hinzu kommt die praktische Trennung zwischen „ausloggen“ und „lokale Daten leeren“. Ein Logout-Button invalidiert idealerweise Server-Session oder Tokens, entfernt aber nicht zwangsläufig alle clientseitigen Schlüssel. Bleiben dort veraltete Hinweise erhalten, kann die UI einen Login-Status anzeigen, während API-Aufrufe bereits scheitern, oder umgekehrt sofort wieder eine Anmeldung starten, weil ein alter „redirect in progress“-Marker hängen geblieben ist.

Identity Provider und SSO: Wer authentifiziert wen?

Bei Single-Sign-On liegt die eigentliche Authentifizierung nicht beim Webdienst, sondern beim Identity Provider. Der Dienst (Service Provider / Relying Party) delegiert die Anmeldung an den IdP und erhält nach erfolgreichem Login eine Bestätigung, je nach Protokoll als SAML-Assertion oder als OAuth2/OIDC-Antwort mit Autorisierungscode und anschließender Token-Ausgabe. Der IdP führt wiederum eine eigene Sitzung, meist per Cookies auf der IdP-Domain. Dadurch entstehen mindestens zwei Zustände: die Anwendungssitzung und die IdP-Sitzung.

Das erklärt ein verbreitetes Verhalten: Ein Logout in der Anwendung beendet nur die Anwendungssitzung, die IdP-Sitzung bleibt bestehen. Beim nächsten „Login“ wird deshalb ohne Passworteingabe sofort wieder ein Konto übernommen, das beim IdP noch aktiv ist. Umgekehrt kann eine aktive Anwendungssitzung bestehen, obwohl die IdP-Sitzung bereits abgelaufen ist; dann funktioniert die Anwendung bis zum nächsten Token-Refresh und fällt anschließend abrupt in einen Login-Loop.

• Anwendungssitzung (Service Provider): Zustand typischerweise über Set-Cookie auf der Dienst-Domain; Probleme äußern sich als „logout ohne Wirkung“ oder als plötzliches Ausloggen bei Domain-/Subdomain-Wechsel.
• IdP-Sitzung (SSO): Cookies auf der IdP-Domain steuern, ob interaktive Anmeldung nötig ist; ein „Login“ kann ohne Passwort erfolgen, wenn die IdP-Sitzung noch gültig ist.
• Autorisierungscode-Flow (OIDC): Der Browser transportiert einen kurzlebigen Code über Redirects; Fehler entstehen durch blockierte Drittanbieter-Cookies, falsche Redirect-URIs wie https://app.example.com/callback oder abgelaufene Codes.
• Token-Laufzeiten und Widerruf: exp-Ablauf beim Access Token und serverseitiger Widerruf beim Refresh Token führen zu unterschiedlichen Symptomen; ein UI-Refresh kann den Fehler erst sichtbar machen.
• Mehrere Konten und parallele Sessions: Gleichzeitige IdP-Sitzungen (z. B. mehrere Profile oder Container-Tabs) können bei Kontoauswahl kollidieren; die Anwendung erhält Tokens für ein anderes Konto als erwartet.

Warum „Passwort stimmt“ trotzdem nicht hilft: Zustandskollisionen entlang der Kette

Ein korrektes Passwort ist nur ein Baustein. Entscheidend ist, ob nach der Passwortprüfung die richtigen Zustandsdaten erzeugt, gespeichert und bei den Folgerequests wieder vorgelegt werden. Ein veraltetes Session-Cookie kann eine neue Anmeldung überlagern, wenn der Server die alte Session noch akzeptiert, aber der darin gespeicherte Autorisierungsstatus nicht mehr passt. Ein aktualisiertes Token kann ungenutzt bleiben, wenn die Anwendung weiterhin aus dem localStorage liest, statt den neuen Wert zu übernehmen. Bei SSO kann die Rückleitung vom IdP erfolgreich sein, aber ein zu restriktives Cookie-Setup verhindert, dass die Anwendung die neue Sitzung sauber etabliert.

Für die Einordnung von Login-Problemen ist daher weniger die Frage „wurde ein Passwort eingegeben?“ zentral, sondern welche der drei Ebenen gerade scheitert: IdP-Authentifizierung, Token-/Session-Erzeugung oder die persistente Ablage/Übermittlung im Browser. Erst wenn diese Ebenen getrennt betrachtet werden, lassen sich Symptome wie Konto-Verwechslungen, Login-Loops oder scheinbar zufälliges Ausloggen technisch sauber zuordnen.

Fehlerbilder und Diagnose: Login-Schleife, 401/403, CSRF-Probleme, abgelaufene Tokens und widersprüchliche Zustände

Wiederkehrende Login-Probleme wirken oft zufällig, folgen aber typischen Mustern: ein Redirect-Karussell zwischen Login- und Zielseite, plötzliche 401 Unauthorized– oder 403 Forbidden-Antworten, CSRF-Fehler nach Formular-Submit oder eine Sitzung, die auf einem Gerät „gültig“ erscheint, während ein anderes Gerät sofort abweist. Die Diagnose gelingt zuverlässiger, wenn Fehlerbilder konsequent den Ebenen Cookie, Token, Session-Store, SSO-Provider und Browser-Speicher zugeordnet werden.

Praktisch bewährt sich die Trennung zwischen „Authentisierung“ (Identität, Token-Ausstellung) und „Autorisierung“ (Berechtigungen, Scope, Rollen) sowie zwischen „Clientzustand“ (Cookies, Storage, Passwortmanager) und „Serverzustand“ (Sessions, Token-Revocation, Gerätebindung). In hybriden SSO-Ketten (z. B. OIDC/SAML vor einer eigenen Anwendung) entstehen Fehler häufig an Übergängen: ein Token wird korrekt ausgestellt, aber im falschen Kontext gespeichert; ein Cookie wird gesetzt, aber wegen Attributen oder Browser-Policy nicht gesendet; oder eine alte Session kollidiert mit einer neu gestarteten Anmeldung.

Login-Schleife (Redirect Loop): wenn Cookies nicht dort ankommen, wo sie gebraucht werden

Eine Login-Schleife entsteht typischerweise, wenn der Server eine authentisierte Sitzung erwartet, der Browser aber das zuständige Cookie nicht mitsendet oder es sofort verwirft. Häufige Ursachen sind ein fehlerhaft gesetztes Domain-Attribut (Cookie gilt nicht für die tatsächliche Hostname-Variante), ein unpassendes Path, blockierte Third-Party-Cookies in eingebetteten Login-Flows oder ein Konflikt zwischen SameSite-Einstellungen und Cross-Site-Redirects. Bei SSO-Flows zeigt sich das als ständiger Wechsel zwischen IdP und Service Provider, ohne dass der „eingeloggt“-Zustand stabil wird.

Diagnostisch zählt hier nicht der sichtbare Erfolg der Eingabe, sondern die Frage, ob nach dem Redirect ein erwartetes Session-Cookie vorhanden ist und bei Folgerequests gesendet wird. Browser-DevTools liefern die relevantesten Signale: im Netzwerk-Trace die Kette aus 302/303 und die gesetzten Set-Cookie-Header; im Application/Storage-Tab, ob Cookies tatsächlich gespeichert wurden und ob Attribute wie Secure und SameSite=None zur Auslieferung über https passen.

401 vs. 403: Token fehlt, ist ungültig oder Berechtigung reicht nicht

Die Unterscheidung zwischen 401 und 403 ist diagnostisch wertvoll, wird aber in der Praxis nicht immer sauber umgesetzt. Ein 401 weist im Kern darauf hin, dass keine gültige Authentisierung vorliegt: Token fehlt, ist abgelaufen, Signaturprüfung schlägt fehl oder der Session-Handle ist serverseitig nicht mehr bekannt. Ein 403 signalisiert dagegen, dass die Identität zwar erkannt wurde, aber der Zugriff verboten bleibt, etwa durch fehlende Rollen, falsche Scopes oder restriktive Mandanten-/Tenant-Zuordnung.

Wichtig sind Übergangsszenarien: Manche Systeme liefern 403, wenn ein CSRF-Check fehlschlägt, andere verwenden 401 bei „silent reauth“-Fehlern. In SSO-Umgebungen kann ein 401 außerdem bedeuten, dass ein Backend nur ein internes Session-Cookie akzeptiert, der Client aber ausschließlich ein Access Token sendet (oder umgekehrt). Der Blick in WWW-Authenticate-Header (falls vorhanden) und serverseitige Logs zur Token-Validierung (Issuer, Audience, Clock Skew) schafft hier Klarheit.

CSRF-Probleme: wenn Session und Formularzustand auseinanderlaufen

CSRF-Schutz koppelt Schreiboperationen an einen serverseitig erwarteten Zustand. Scheitert diese Kopplung, erscheinen Fehlermeldungen wie „CSRF token mismatch“ oder pauschale 403-Antworten nach einem POST. Ursache ist oft nicht „ein falscher Token“ im engeren Sinne, sondern ein verlorenes oder ersetztes Session-Cookie: Der Server erwartet CSRF-Token X zur Session S1, der Browser sendet aber Session S2 (oder gar keine). Besonders anfällig sind Konstellationen mit mehreren Tabs, parallelen Logins (z. B. Test- und Produktivkonto), oder wenn ein IdP-Flow die Session im Hintergrund erneuert und dabei serverseitige Session-Daten rotiert.

Bei Diagnosen lohnt der Abgleich von Request-Details: wird das Session-Cookie beim POST mitgesendet, stimmt der Origin/Referer, und passt der CSRF-Header (z. B. X-CSRF-Token) zum erwarteten Mechanismus? Bei Cross-Site-Szenarien spielt SameSite=Lax eine Rolle: ein Session-Cookie kann bei bestimmten navigationsgetriebenen Flows noch ankommen, bei XHR/fetch aber nicht, wenn Credentials nicht gesendet werden oder der Browser strenger behandelt.

Abgelaufene Tokens, Refresh-Fehler und Token-Rotation

Access Tokens sind bewusst kurzlebig; Stabilität entsteht erst durch Refresh-Mechanismen oder serverseitige Sessions. Typische Fehler zeigen sich zeitverzögert: Nach einer Inaktivitätsphase liefert das Backend 401, der Client versucht still zu erneuern, erhält aber keinen gültigen Refresh (fehlender Refresh Token, Rotation bereits erfolgt, oder die Refresh-Session beim IdP ist abgelaufen). Bei Rotation kann zusätzlich ein Race Condition auftreten: Zwei parallele Requests versuchen zu refreshen, einer gewinnt und rotiert, der andere verwendet den bereits invalidierten Refresh Token und erzeugt eine Fehlerkaskade.

Die Diagnose konzentriert sich auf Token-Metadaten und Timing: exp (Ablauf), iat (Ausstellung), nbf (gültig ab) sowie die Übereinstimmung von iss und aud. Abweichende Systemzeiten (Client oder Server) können in restriktiven Validierungen sofort zu „expired“ führen. Ebenso erzeugen Token-Caches im Browser (Memory vs. Storage) widersprüchliche Zustände: Ein Tab hält ein altes Token im Speicher, während ein anderer Tab bereits erneuert hat.

Widersprüchliche Zustände: mehrere Geräte, mehrere Tabs, mehrere Identitäten

Parallele Sitzungen sind nicht nur ein Komfortthema, sondern eine Fehlerquelle. Viele Dienste unterstützen mehrere Sessions pro Nutzer, andere erzwingen „Single Session“ oder invalidieren ältere Sessions nach Passwortwechsel, MFA-Änderung oder Policy-Update. In SSO-Ketten kommt hinzu, dass IdP-Session und Dienst-Session unabhängig laufen: Der IdP meldet „eingeloggt“, der Dienst hat die eigene Session aber verloren; oder der Dienst ist aktiv, während der IdP bereits abgelaufen ist, sodass der nächste „silent“ Redirect scheitert.

Widersprüche entstehen auch durch gespeicherte Anmeldedaten und Autofill: Ein Passwortmanager kann unbemerkt alte Zugangsdaten, falsche Nutzerkennungen oder ein anderes Konto eintragen, während im Hintergrund noch eine gültige Session für ein vorheriges Konto existiert. Das äußert sich als „Login klappt, aber falscher Account“ oder als Berechtigungsfehler nach erfolgreicher Authentisierung. Technisch sind das keine klassischen Login-Fehler, sondern Identitätsverwechslungen, die durch Browser-Storage und Sessions verstärkt werden.

• Redirect-Kette prüfen: In DevTools die Folge aus 302/303 nachvollziehen und kontrollieren, ob nach Set-Cookie ein passender Cookie bei Folgerequests im Header Cookie: erscheint.
• Cookie-Attribute verifizieren: Relevante Felder sind Domain, Path, Expires/Max-Age, Secure und SameSite; bei Cross-Site-SSO ist SameSite=None nur zusammen mit Secure wirksam.
• 401/403 differenzieren: Bei 401 zuerst Token-/Session-Präsenz und Gültigkeit prüfen; bei 403 Scopes/Rollen/Mandant und Policy-Entscheidungen sowie mögliche CSRF-Blockaden abgleichen.
• Token-Timing abgleichen: JWT-Claims wie exp, iat, nbf sowie die lokale Zeitquelle prüfen; auffällige Abweichungen deuten auf Clock-Skew-Probleme oder fehlerhafte Validierungsfenster hin.
• Parallelität ausschließen: Für Reproduzierbarkeit nur ein Tab, ein Browser-Profil und ein Konto verwenden; konfliktträchtig sind gleichzeitige Logins in normal und private oder unterschiedliche Subdomains (z. B. app.example.com vs. login.example.com).
• Widersprüchliche Identitäten erkennen: Auffälligkeiten sind wechselnde Nutzer-IDs im Token (sub), unterschiedliche E-Mail/UPN in Claims oder ein Wechsel des Mandanten-Claims; häufig ausgelöst durch Autofill/Passwortmanager-Einträge für eine ähnliche URL.

Wenn diese Checks keinen eindeutigen Befund liefern, liegt der Fehler häufig in einer Grenzfläche: ein Proxy verändert Header, ein CDN cached Redirects, oder ein SameSite-/CSP-Setup blockiert den erwarteten Flow. In solchen Fällen sind korrelierte Log-IDs (Client und Server) und ein sauberer Trace der Auth-Entscheidungskette wichtiger als weitere Wiederholungen des Logins, weil jede Wiederholung den Zustand durch Token-Rotation oder Session-Neuanlage weiter verändern kann.

Maßnahmen mit Augenmaß: korrekt abmelden, Browserdaten gezielt bereinigen, Passwortmanager prüfen und parallele Sitzungen kontrollieren

Wiederkehrende Login-Probleme lassen sich oft nicht durch „mehrfaches Passwort-Eingeben“ lösen, sondern durch sauberes Sitzungs- und Speichermanagement. In modernen Webdiensten greifen mehrere Schichten ineinander: Anwendungssession (Cookie), Identitätsanbieter-Login (SSO), Refresh-/Access-Token sowie lokal gespeicherte Anmeldedaten im Browser oder Passwortmanager. Maßnahmen sollten deshalb gezielt an der Stelle ansetzen, an der der Zustand „hängen bleibt“.

Korrekt abmelden: nicht nur die App-Session beenden

Ein „Abmelden“ innerhalb eines Webdienstes beendet häufig nur die lokale Anwendungssession. Bei SSO-Szenarien (z. B. OpenID Connect) bleibt die Sitzung beim Identity Provider (IdP) oft aktiv; der nächste Login führt dann ohne sichtbare Eingabe automatisch wieder in denselben Konto-Kontext. Das ist funktional, erzeugt aber Fehlersymptome, wenn im Hintergrund ein falscher Mandant, ein veralteter Token-Status oder ein gesperrtes Konto weiterhin referenziert wird.

Für eine saubere Trennung sind Abmeldevorgänge in der richtigen Reihenfolge relevant: erst in der Anwendung abmelden, danach beim IdP (SSO) die zentrale Sitzung beenden. Manche Plattformen bieten dafür einen expliziten „Von allen Geräten abmelden“-Schalter; technisch wird damit typischerweise die Serverseite invalidiert (Session-Store) und/oder Refresh-Tokens werden widerrufen. Ohne diese serverseitige Invalidierung bleiben bereits ausgestellte Tokens bis zum Ablaufzeitpunkt oft gültig.

Browserdaten gezielt bereinigen: Cookies, Site-Storage, Service Worker

„Cache leeren“ ist meist zu grob. Für Login-Probleme sind in der Praxis eher Cookies (Session/CSRF), Local Storage/Session Storage (SSO-Zustände, Feature-Flags), IndexedDB (Offline-Daten) sowie Service Worker (Zwischenschichten, die Requests umschreiben) entscheidend. Ein selektives Zurücksetzen pro betroffener Domain vermeidet Nebenwirkungen bei anderen Diensten und reduziert Fehlinterpretationen durch parallel aktive Sessions in anderen Tabs.

Hilfreich ist die Unterscheidung nach Symptom: Ein sofortiger Re-Login ohne Eingabemaske spricht für aktive IdP-Sitzungen oder persistente Cookies. Endlosschleifen zwischen Login-Seite und App deuten auf widersprüchliche Cookie-Zustände (z. B. SameSite/Domain-Scoping) oder blockierte Drittanbieter-Cookies im SSO-Redirect hin. Ein „Login erfolgreich, aber anschließend wieder ausgeloggt“ passt zu ablaufenden Access-Tokens ohne funktionierenden Refresh-Flow oder zu Zeitabweichungen auf dem Endgerät.

Passwortmanager prüfen: falsche Einträge, Autofill-Konflikte, Passkeys

Passwortmanager reduzieren Eingabefehler, verursachen aber eigene Störungen, wenn mehrere Datensätze zu einer Domain existieren (z. B. https://app.example.com und https://login.example.com) oder wenn ein altes Passwort in einer „historischen“ URL gespeichert wurde. Zusätzlich können SSO-Seiten mehrere Formularschritte nutzen; Autofill befüllt dann gelegentlich das falsche Feld oder triggert eine Submission im falschen Moment.

Seit breiter Verfügbarkeit von Passkeys (WebAuthn) kommt ein weiterer Zustand hinzu: Ein Konto kann parallel Passwort und Passkey unterstützen, oder ein Anbieter erzwingt nach Registrierung bevorzugt den passwortlosen Flow. Dann wirken Passwortänderungen scheinbar „wirkungslos“, weil weiterhin per Passkey authentifiziert wird. Umgekehrt scheitert ein Passkey-Login, wenn der falsche Credential gewählt wird oder die Plattform zwischen mehreren Konten auf derselben Domain wechselt.

• Domain-Matching korrigieren: Einträge auf die tatsächlich genutzte Login-URL ausrichten, etwa https://login.example.com statt nur example.com; Dubletten mit abweichenden Subdomains bereinigen.
• Autofill-Konflikte isolieren: Testweise Autofill deaktivieren oder im privaten Fenster anmelden, um zu prüfen, ob Form-Overlays oder automatische Submissions den Flow stören.
• Passkey-Flow verifizieren: Wenn ein Dienst Passkeys nutzt, den ausgewählten Credential bewusst prüfen; bei Kontowechseln den falschen Passkey entfernen oder den richtigen neu registrieren (sofern vom Dienst vorgesehen).
• „Alte“ Zugangsdaten erkennen: Nach Passwortänderungen gespeicherte Einträge aktualisieren; bei mehreren Identitäten (privat/geschäftlich) den Benutzernamen im Manager eindeutig benennen, damit Autofill nicht „das letzte Konto“ nimmt.

Parallele Sitzungen kontrollieren: Geräte, Tabs, Mandanten und Token-Laufzeiten

Gleichzeitige Logins auf mehreren Geräten sind Normalfall, können aber Zustände „überholen“. Typische Auslöser: Passwortänderung auf Gerät A, während Gerät B noch mit Refresh-Token arbeitet; Abmeldung auf einem Gerät, die serverseitig Tokens widerruft; Wechsel zwischen Mandanten/Organisationen, bei dem eine alte Session weiterhin Standard bleibt. In solchen Situationen entsteht der Eindruck eines „sporadischen“ Fehlers, obwohl der Dienst konsistent reagiert.

Pragmatisch ist die Kontrolle der aktiven Sitzungen in den Kontoeinstellungen des jeweiligen Anbieters, sofern vorhanden: Geräte- und Sitzungsliste, zuletzt verwendete Clients, ausstehende Sicherheitsereignisse. Wenn ein globales Abmelden angeboten wird, sollte es als gezielte Maßnahme dienen, nicht als Routine, weil damit auch funktionierende Sessions beendet und erneut authentifiziert werden müssen (inklusive MFA). Danach lohnt es sich, zuerst auf genau einem Gerät den Login sauber aufzubauen und erst dann weitere Geräte wieder anzumelden, um Seiteneffekte durch konkurrierende Refresh-Vorgänge zu vermeiden.

Bei SSO-Konstellationen mit mehreren Identitäten ist außerdem der Browser-Kontext entscheidend: getrennte Profile oder separate Browser verhindern, dass Cookies und IdP-Sessions zwischen „Arbeitskonto“ und „Privatkonto“ kollidieren. In Teams mit gemeinsam genutzten Testkonten sollte zusätzlich geprüft werden, ob Sicherheitsrichtlinien parallele Sessions begrenzen oder ob neue Logins ältere Sitzungen automatisch invalidieren. Solche Regeln sind gewollt und werden fälschlich als Störung interpretiert, wenn der Zusammenhang nicht sichtbar ist.