Zwei Auth‑Systeme zusammenführen, ohne bestehende Nutzer auszusperren

Das Problem: zwei Logins in einer App und Nutzer hängen dazwischen

Zwei getrennte Login‑Systeme schaffen einen merkwürdigen Zwischenzustand für Nutzer. Sie melden sich auf einem Bildschirm an und landen dann an einer anderen Login‑Abfrage. Lokal kann das noch harmlos aussehen, während reale Nutzer von zufälligen Logouts, fehlendem Zugriff oder endlosen Redirect‑Loops berichten.

Die Hinweise sind meist unspektakulär, aber offensichtlich, wenn man hinsieht: zwei unterschiedliche Login‑Bildschirme, zwei Cookie‑Sätze mit ähnlichen Namen und gemischte Auth‑Prüfungen, die manchmal ein Session‑Cookie erwarten und anderes Mal ein JWT. Im Network‑Tab sieht man vielleicht, dass ein Endpunkt ein Cookie wie session setzt, während ein anderer etwas wie auth_token setzt.

Das tritt oft bei schnellem Prototyping und AI‑generiertem Code auf. Ein Tool fügt ein fertiges Auth‑Paket hinzu, später kommt ein Prompt mit einem benutzerdefinierten Login „nur fürs Erste“ dazu, oder eine Framework‑Vorlage wird mit einer bestehenden API gemerged. Nichts ersetzt den alten Pfad vollständig, also bleiben beide aktiv.

Was zuerst kaputtgeht, ist häufig die Infrastruktur um das Login, nicht das Login‑Formular selbst:

• Passwort‑Resets aktualisieren eine Nutzertabelle, die App liest aber die andere.
• E‑Mail‑Verifizierung wird in einem Flow erzwungen, im anderen übersprungen.
• Rollen‑ und Berechtigungsprüfungen lesen unterschiedliche Claims oder unterschiedliche DB‑Spalten.
• „Remember me“‑Sessions stimmen nie mit der Middleware überein, die Seiten schützt.

Riskant ist, dass das Entfernen der falschen Komponente reale Nutzer ohne Vorwarnung aussperren kann. Du löschst ein „doppeltes" Cookie und denkst, du hast aufgeräumt, aber dieses Cookie war vielleicht die einzige Sache, die ältere Sessions gültig hielt. Oder du dropst eine vermeintlich „unbenutzte" Sessions‑Tabelle und stellst fest, dass Background‑Jobs (oder ein Mobile‑Client) sie brauchten, um Tokens zu refreshen.

Behandle Konsolidierung wie eine Nutzer‑Migration, nicht wie ein Code‑Aufräumen. Das Ziel ist eine klare Quelle der Wahrheit, mit kontrollierter Überlappung, sodass bestehende Konten und Sessions weiter funktionieren.

Mache ein klares Inventar dessen, was gerade existiert

Bevor du etwas änderst, liste jedes auth‑relevante Teil auf. Die meisten Konsolidierungsfehler passieren, weil eine unsichtbare Überprüfung (Middleware, API‑Guard, Edge‑Funktion) noch das alte Cookie‑ oder Session‑Format erwartet.

Nenne die beiden Ansätze in einfachen Worten, auch wenn der Code unordentlich ist. Zum Beispiel: „NextAuth cookie session“ vs „custom JWT in localStorage“. Schreibe dann auf, was jedes System kontrolliert: die Login‑UI, API‑Zugriffe, Datenbank‑Einträge, Admin‑Seiten, Background‑Jobs und Drittanbieter‑Callbacks.

Beantworte für jedes System diese Fragen:

• Was beweist, dass der Nutzer eingeloggt ist (Cookie‑Name, Header, Token‑Format)?
• Wo wird das durchgesetzt (Middleware, Server‑Routen, Edge‑Funktionen, API‑Handler)?
• Welche Daten liest und schreibt es (users‑Tabelle, sessions‑Tabelle, Refresh‑Tokens, Rollen)?
• Welche Seiten oder Endpunkte hängen davon ab (Admin, Billing, Uploads, Webhooks)?
• Welche Secrets und Validierungsregeln sind involviert (JWT‑Secret, OAuth‑Keys, Passwort‑Hashing)?

Während du inventarisierst, markiere Produktionsrisiken, die du schon sehen kannst: Secrets im Repo, Token‑Checks, die nur decodieren statt zu verifizieren, SQL aus Strings gebaut und Routen, die Berechtigungsprüfungen umgehen.

Wie du das Auth‑System auswählst, das du behältst

Das Ziel ist nicht das „beste" System in der Theorie, sondern dasjenige, das am sichersten läuft, am einfachsten zu warten ist und dich nachts am wenigsten überrascht.

Beginne mit deinen Prioritäten. Für die meisten Teams sind Sicherheit und Wartbarkeit wichtiger als Bequemlichkeit. Wenn niemand im Team ein System wirklich versteht, ist das ein echtes Risiko, auch wenn es poliert wirkt.

Prüfe außerdem, welches Auth‑System reale Nutzer tatsächlich verwenden. Vertraue nicht nur der UI. Schau in Sign‑in‑Logs, in die jüngsten Writes in Session‑Tabellen und in Support‑Tickets mit „kann mich nicht einloggen" oder „wird wieder ausgeloggt". Oft bedient ein System den Großteil des Traffics, während das andere nur in Randfällen genutzt wird.

Bestätige zuletzt die benötigten Features. Das System, das du behältst, muss das unterstützen, was deine App heute braucht.

Kurze Auswahl‑Checklist

Behalte das System, das deine Must‑haves mit dem wenigsten Custom‑Code abdeckt:

• Login‑Methoden, die du brauchst (E‑Mail/Passwort, Magic‑Links, Social Login, SSO)
• Rollen, Teams und Berechtigungen (falls vorhanden)
• Sichere Defaults (Passworthandling, Token‑Rotation, CSRF‑Schutz wo nötig)
• Klare Grenzen im Code (ein Ort, um Sessions zu erstellen, ein Ort, um Auth zu prüfen)
• Einfaches Debugging und verständliche Fehlermeldungen

Wenn du unentschlossen bist, ist ein praktischer Tiebreaker die Verteilung der Grenzen und des Datenmodells. Die Option, die Auth‑Prüfungen über zufällige Routen verteilt, in mehrere Tabellen schreibt „nur für den Fall" und extra Cookies erzeugt, wird weiterhin Bugs produzieren.

Beispiel: Wenn ein Framework‑Auth zuverlässig Session‑Cookies handhabt, während ein Custom‑Login zusätzlich ein eigenes Cookie und eine Session‑Zeile setzt, behalte das Framework‑Auth und migriere den Custom‑Login‑Flow hinein.

Verstehe deine Nutzer, Sessions und dein Datenmodell, bevor du Code anfässt

Bevor du konsolidierst, kläre, was „ein Nutzer" in deiner App gerade bedeutet. Zwei Auth‑Systeme erzeugen oft zwei Identitäten für dieselbe Person, und die App wechselt leise zwischen ihnen. Wenn du diesen Schritt überspringst, entstehen zufällige Logouts, fehlende Daten und Kontoverwirrung.

Verfolge, wie ein Nutzerdatensatz erstellt und gematcht wird. Sind Logins an E‑Mail, eine interne UUID, eine Provider‑ID (Google/GitHub) oder eine Mischung gebunden? Achte auf Randfälle: E‑Mail‑Änderungen, Groß/ Kleinschreibung (User@ vs user@) und Nutzer, die sich zweimal mit unterschiedlichen Methoden registriert haben.

Verifiziere, wo Passwörter tatsächlich liegen. Ein System speichert Passwort‑Hashes in einer users‑Tabelle, das andere speichert vielleicht gar keine Passwörter (z. B. reines Social Login). Gehe nicht davon aus, dass du Passwörter zwischen Systemen „verschieben" kannst. Meistens kannst und solltest du das nicht.

Mappe dann Sessions Ende‑zu‑Ende: was wird im Browser gesetzt, was auf dem Server gespeichert und was prüft die App bei jeder Anfrage. Es ist üblich, mehrere aktive Session‑Typen gleichzeitig zu finden.

Schreibe eine einseitige Momentaufnahme:

• Nutzer‑Identifier: Spalten und Regeln zum Abgleich von Accounts
• Aktivierte Auth‑Methoden: Passwort, Magic‑Link, OAuth‑Provider
• Session‑Mechanismus: Cookies, DB‑basierte Sessions, JWTs, Refresh‑Tokens
• Wo der Session‑Status gespeichert ist: Tabellen, Cache, Local Storage
• Duplikate: zwei users‑Tabellen, zwei sessions‑Tabellen, „shadow"‑Profile‑Tabellen

Achte auch auf „harmlose" Duplikate, die es nicht sind — z. B. eine profiles‑Tabelle, die tatsächlich die Quelle der Wahrheit für Permissions oder Subscription‑Status ist.

Entwerfe die Migration so, dass bestehende Konten weiter funktionieren

Der Zielzustand ist eine Quelle der Wahrheit für Identität (wer der Nutzer ist) und Autorisierung (was er tun darf). Alles andere wird zu einer Kompatibilitäts‑Schicht, die du später entfernen kannst.

Entscheide, welcher reale Nutzerdatensatz gelten soll. Dieser Datensatz sollte die kanonische Nutzer‑ID, E‑Mail und Rollen/Berechtigungsfelder besitzen. Sorge dann dafür, dass jeder Login‑Pfad auf dieselbe Nutzer‑ID landet, selbst wenn die Anfrage im Legacy‑System startet.

Wenn die Systeme unterschiedliche Nutzer‑IDs verwenden, erstelle ein Mapping. Der sicherste Ansatz ist eine explizite Brücke: speichere die alte ID auf dem behaltenen Nutzerdatensatz oder füge eine kleine Mapping‑Tabelle hinzu. Vermeide, IDs in‑place umzuschreiben, wenn sie in vielen Tabellen referenziert werden.

Passwörter sind der häufigste Migrationsbruch. Wenn du Passwort‑Hashes sicher wiederverwenden kannst, kopiere den Hash plus die benötigten Metadaten (Algorithmus, Salt, Kostenfaktoren) und behalte den alten Verifier noch eine Weile. Erzwinge Resets nur, wenn du alte Hashes wirklich nicht validieren kannst oder ein Sicherheitsproblem es verlangt.

Setze Richtlinien für häufige Randfälle, bevor du startest:

• Duplizierte E‑Mails: wähle einen Gewinner nach letztem Login oder verifizierter E‑Mail und setze den anderen in Quarantäne.
• Fehlende Profile: erstelle minimale Profile beim ersten erfolgreichen Login.
• Testnutzer und Seed‑Daten: markiere und schließe sie von den Migrationszahlen aus.
• Verwaiste Sessions: laufe sie sicher ab, statt zu versuchen, sie „zu reparieren".

Beispiel: Wenn du Framework‑Auth plus einen Custom‑Login hast, behalte die Framework‑User‑Tabelle und importiere Custom‑User mit einem old_id‑Feld. Nutzer loggen sich weiter ein und du kannst den Custom‑Pfad schrittweise stilllegen.

Schritt‑für‑Schritt Rollout‑Plan, der Massenaussperrungen vermeidet

Der sicherste Weg ist eine kurze Überlappungsphase, in der die App beide Systeme lesen kann, gefolgt von einem kontrollierten Stopp des Schreibens ins alte System. Du willst, dass bestehende Sessions weiter funktionieren, während neue Logins zur neuen Quelle der Wahrheit wechseln.

Beginne an den Rändern: Middleware, die Cookies liest, API‑Auth‑Guards und Session‑Lookup‑Code. Dort entstehen Überraschungs‑Logouts.

Ein praktischer Rollout:

• Phase 1 (Kompatibilität): Akzeptiere beide Token/Cookie‑Formate und mappe beide auf dieselbe interne Nutzer‑ID.
• Phase 2 (stille Migration): Wenn eine Anfrage mit einer alten Session hereinkommt, stelle eine neue Session aus und setze das neue Cookie zusätzlich zum alten.
• Phase 3 (Write‑Switch): Erstelle neue Sessions nur noch im behaltenen System. Schreibe nicht mehr in die alte Session‑Tabelle und setze beim Login das alte Cookie nicht mehr.
• Phase 4 (Cleanup): Nach einem klaren Cutoff‑Datum und Monitoring entferne alten Codepfad, Cookies und Tabellen.

Zwischen den Phasen beobachte reale Signale, bevor du weitermachst: Login‑Erfolgsrate, 401/403‑Spitzen, „user not found"‑Fehler und Support‑Tickets wegen Ausgeloggt‑Seins. Wenn etwas auffällig ist, rolle den Write‑Switch (Phase 3) zurück, bevor du die Lese‑Kompatibilität (Phase 1) entfernst.

Beispiel: Wenn die App sowohl ein Framework‑Cookie als auch ein Custom‑JWT‑Cookie setzt, lies beide für ein bis zwei Wochen weiter, aber mint nach dem Switch nur noch das Framework‑Cookie.

Cookies und Tokens: Extras entfernen, ohne Sessions zu brechen

Cookies und Tokens sind die ersten Fehlerquellen bei Konsolidierung. Ein System nutzt möglicherweise ein signiertes Session‑Cookie, das andere ein JWT plus Refresh‑Token. Nutzer sind an einer Stelle eingeloggt und an einer anderen ausgeloggt.

Fange damit an, jedes auth‑bezogene Cookie und Token aufzulisten und wo es gesetzt wird. Berücksichtige Server‑Middleware, Client‑Code und Framework‑Hilfen. Das ist der einzige sichere Weg, doppelte Auth‑Cookies zu entfernen.

Inventarisiere das Wesentliche:

• Cookie‑Name und Zweck (session, refresh, CSRF, „remember me")
• Wer es setzt (Server‑Route, Client‑Code, Framework‑Plugin)
• Scope (Domain, Path, SameSite, Secure, HttpOnly)
• Wie es validiert wird (Signing‑Key, Encryption‑Key, Token‑Secret)
• Wo es gelesen wird (API, SSR‑Seiten, Edge‑Middleware)

Cookie‑Kollisionen sind ein häufiges, verstecktes Problem. Zwei Systeme können denselben Cookie‑Namen mit unterschiedlichen Signing‑Keys wiederverwenden oder Cookies in unterschiedlichen Scopes setzen (app.example.com vs example.com). Das führt zu zufälligen Logouts, Redirect‑Loops oder Authentifizierung als die falsche Session.

Wenn du eine Kollision findest, plane eine saubere Umbenennung statt beide dauerhaft kompatibel zu halten. Führe einen neuen Cookie‑Namen für das System ein, das du behältst, akzeptiere kurzzeitig beide und entferne dann das alte Cookie.

Logout braucht während der Überlappung besondere Aufmerksamkeit. Nutzer klicken „Logout" und erwarten, dass alles gelöscht wird. Während der Migration lösche Logout deshalb sowohl alte als auch neue Cookies (und widerrufe serverseitig Refresh‑Tokens, falls vorhanden). Sonst erhältst du „Geisterlogins", bei denen das alte Cookie sie sofort wieder einloggt.

Beispiel: Ein AI‑Tool hat NextAuth‑Sessions hinzugefügt und ein Custom‑JWT‑Cookie namens auth. Wenn beide existieren, akzeptiert der Server vielleicht NextAuth, während der Client weiter das JWT sendet. Wähle eines, benenne gegebenenfalls das behaltene Cookie um und baue eine temporäre Brücke, die ein gültiges altes Cookie in die neue Session überführt.

Datenbank‑Bereinigung: Sessions, Nutzer und übrig gebliebene Auth‑Tabellen

Datenbankfehler sind der Weg, wie Konsolidierung zu Massen‑Logouts oder Sicherheitslücken wird. Behandle Bereinigung als Migration, nicht als Löschen‑Button.

Mappe jede auth‑bezogene Tabelle und entscheide, was damit passieren soll:

• Behalten: aktiv vom gewählten System genutzt (users, sessions, refresh tokens)
• Zusammenführen: enthält reale Nutzerdaten, die weitergeführt werden müssen (profile, emails, Passwort‑Hashes)
• Archivieren: nützlich für Support und Rollback (legacy sessions, legacy accounts)
• Löschen: wirklich unbenutzt nach Verifikation

Schreibe reversible Migrationen bevor du Prod anfasst. Statt Legacy‑Session‑Zeilen zu löschen, kopiere sie in eine Archiv‑Tabelle mit Timestamp und ändere die App so, dass sie die Legacy‑Tabelle nicht mehr liest.

Mache Referenzen langweilig (und korrekt)

Auth‑Daten sind nicht isoliert. Rollen, Organisations‑Mitgliedschaften, Berechtigungen und Audit‑Logs verweisen oft auf eine spezifische Nutzer‑ID. Wenn das neue Auth andere IDs nutzt, brauchst du einen klaren Übersetzungsplan.

Ein einfacher Ansatz ist, ein stabiles Mapping‑Feld (wie legacy_user_id) in der behaltenen Nutzer‑Tabelle hinzuzufügen, Nutzer zu migrieren und Referenzen in kleinen Batches zu aktualisieren. Dasselbe gilt für Sessions: wenn du sessions und user_sessions hattest, wähle eine Quelle der Wahrheit und passe den Code an.

Eine Rollout‑Abfolge, die Überraschungen reduziert:

• Backfill neuer Tabellen und Mapping‑Spalten ohne Verhaltensänderung
• App so umstellen, dass sie aus der neuen Quelle liest, während ggf. kurz doppelt geschrieben wird
• Verifiziere Rollen/Orgs/Berechtigungen für reale Accounts (einschließlich Admins)
• Schreibzugriffe nur noch auf die behaltenen Tabellen umstellen
• Legacy‑Daten archivieren und nach einer Abkühlungszeit droppen

Stelle auch sicher, dass nichts mehr die alten Tabellen anfasst: Background‑Jobs, Admin‑Dashboards, Analytics‑Skripte, Support‑Tools und Cron‑Tasks. Dort versteckt sich oft ein zweiter Auth‑Pfad.

Häufige Fehler, die Nutzer ausloggen oder Sicherheitslücken öffnen

Der schnellste Weg, eine Welle von Support‑Tickets zu erzeugen, ist, alte Komponenten zu entfernen, bevor der neue Pfad wirklich alle realen Nutzer‑Flows abdeckt. In deinem Browser sieht die App vielleicht gut aus, aber Produktionsnutzer haben ältere Cookies, halb‑abgelaufene Sessions und gespeicherte Links.

Fehler, die Massen‑Logouts oder neue Lücken verursachen:

• Alte Auth‑Middleware zu früh deaktivieren, sodass bestehende Sessions nicht mehr erkannt werden.
• Reset‑ oder Verifizierungsrouten während der Migration ändern, was zuvor verschickte Emails bricht oder das falsche Konto verifiziert.
• Token‑Checks zu permissiv lassen (Tokens ohne richtige Verifikation akzeptieren, Issuer/Audience‑Checks überspringen oder Sessions nicht ablaufen lassen).
• Andere Clients vergessen (Mobile Apps, Admin‑Tools, Background‑Jobs, eingehende Webhooks), die noch das alte Cookie/Token senden.
• Cookie‑Verhalten über Subdomains und Umgebungen nicht testen (localhost vs staging vs prod), sodass Cookies wegen Domain, SameSite oder Secure‑Flags verworfen werden.

Ein konkretes Beispiel: Du entfernst das alte Session‑Cookie, weil das neue System JWTs nutzt, aber ein eingebettetes Admin‑Tool auf admin.yoursite.com kennt nur das Session‑Cookie. Es bricht, und jemand „repariert" das, indem er Auth‑Checks dort deaktiviert. So entstehen Sicherheitslücken bei Migrationen.

Zwei Sicherheitsmaßnahmen reduzieren Risiko:

• Halte beide Validatoren kurz aktiv und logge, welcher pro Anfrage verwendet wurde.
• Friere URL‑Pfade für Reset/Verify‑Links ein, bis alte Emails abgelaufen sind und Redirects bestätigt wurden.

Kurze Checks vor und nach dem Rollout

Die sicherste Bereinigung ist die, die du schnell rückgängig machen kannst. Code‑Änderungen sind nur die halbe Gefahr. Die andere Hälfte ist, was in echten Browsern mit alten Cookies und halb‑abgelaufenen Sessions passiert.

Vor dem Release bestätige:

• Das Inventar ist komplett: jeder Cookie‑Name, Header‑Token, Session‑Store und jede auth‑Tabelle ist dokumentiert.
• Ein System ist die Quelle der Wahrheit für Identity und Roles, und jeder Route liest davon.
• Cookie‑Namen und Scopes sind bestätigt (Domain, Path, SameSite, Secure) mit einem Plan, alte Cookies zu ignorieren oder zu ersetzen.
• Ein Rollback‑Plan existiert, der einen Deploy entfernt (z. B. ein Feature‑Flag, das den alten Session‑Check wieder aktiviert).
• Deine Test‑Matrix ist geschrieben und durchlaufen für Signup, Login, Logout, Passwort‑Reset und Rollen/Berechtigungsprüfungen.

Verlasse dich nicht auf ein Happy‑Path‑Konto. Teste mindestens einen Nutzer, der unter jedem alten System erstellt wurde, plus einen „verworrenen" Nutzer, der beide Cookies gesetzt hat. Dort verstecken sich Bugs.

Nach dem Release überwache mehr das Verhalten als den Code:

• Monitor Login‑Fehler nach Grund (invalid token, missing session, CSRF mismatch, role denied), nicht nur die Gesamtzahl.
• Verfolge die Rate neu erstellter Sessions und vergleiche sie mit normalem Traffic.
• Bestätige, dass die Legacy‑Session‑Tabelle und alte Auth‑Tabellen nach dem Cutover keine Writes mehr erhalten.
• Stichprobenprüfungen in einem Inkognito‑Fenster und in einem „dreckigen" Browser mit alten Cookies.
• Wenn stabil, entferne alte Secrets und Keys, lösche alte Sessions und droppe erst dann restliche Tabellen.

Ein realistisches Beispiel: Framework‑Auth mit Custom‑Login zusammenführen

Eine übliche AI‑entstehene Situation: Die UI nutzt NextAuth (Cookies, Callbacks, eine sessions‑Tabelle), später fügt jemand einen Custom‑JWT‑Login „nur für die API" hinzu. Jetzt gibt es zwei Wahrheiten dafür, wer ein Nutzer ist.

Die Symptome sind verwirrend. Ein Nutzer kann sich anmelden und die UI nutzen, aber API‑Calls geben 401 zurück, weil sie ein Bearer‑Token erwarten. Oder die API funktioniert in Postman mit einem JWT, während die UI immer wieder zum Login bounced, weil die Cookie‑Session fehlt. Schlimmer noch: dieselbe E‑Mail kann je nach Pfad zwei verschiedene Nutzer‑IDs haben.

Die sicherste Lösung ist, einen Gewinner zu wählen und zu migrieren, ohne alle zur Neuregistrierung zu zwingen. Wenn du zu NextAuth konsolidierst, lass den Custom‑JWT‑Pfad kurz als Kompatibilitätsschicht bestehen.

Eine praktikable Migration:

• Wähle die einzelne reale Nutzer‑ID (oft die NextAuth‑User‑Tabelle) und mappe JWT‑only‑Nutzer darauf.
• Akzeptiere temporär beide: erlaube API‑Requests via Session‑Cookie oder altem JWT, löse aber beides in Servercode auf die reale Nutzer‑ID auf.
• Wenn Nutzer sich das nächste Mal anmelden (oder Tokens refreshen), gib nur noch die behaltene Session‑Methode aus und mint keine neuen JWTs mehr.
• Nach einem kurzen Fenster entferne die JWT‑Verifikation, lösche das extra Cookie und retire ungenutzte Session/Token‑Tabellen.

Eine sichere Bereinigung endet mit einem Cookie, einem Session‑Store und einer Nutzer‑ID überall.

Nächste Schritte: Wann du Hilfe holen solltest

Wenn du nicht in einem Satz erklären kannst, wie eine Anfrage in deiner App zu einem authentifizierten Nutzer wird, halte an. Diese Änderungen sehen klein aus, können aber still und leise Nutzer aussperren oder die Sicherheit schwächen.

Anzeichen, dass du stoppen und eine zweite Meinung holen solltest

Du bist wahrscheinlich schon über „einfaches Aufräumen" hinaus und in einem Migrationsprojekt, wenn:

• Du nicht jeden Nutzer einer Identität zuordnen kannst (zwei Nutzertabellen, nicht übereinstimmende E‑Mails, doppelte IDs).
• Du nicht weißt, wie Passwörter gehasht werden (oder du mehr als eine Hash‑Methode siehst).
• Rollenprüfungen sind gemischt (einige Routen Middleware, andere prüfen ein Custom‑Cookie, wieder andere queryen die DB).
• Sessions und Cookies überlappen (Nutzer erscheinen eingeloggt, API‑Calls schlagen fehl oder die Identität wechselt).

Was du für ein Review vorbereiten solltest

Du erhältst bessere Antworten, wenn du ein kleines Paket an Fakten sammelst:

• Repo‑Zugang (oder sauberen Export) plus aktuelle Deployment‑Konfiguration
• Eine Liste auth‑bezogener Env‑Vars (Cookie‑Namen, JWT‑Secrets, OAuth‑Client‑IDs, Callback‑URLs)
• Ein DB‑Schema‑Dump und Zeilenzahlen für users, sessions und andere auth‑Tabellen
• Aktuelle Logs rund um Login, Token‑Refresh und Unauthorized‑Errors
• Eine kurze Notiz, was Nutzer berichten (Zwangs‑Logouts, falsche Accounts, kaputter Admin‑Zugang)

Wenn dieses Chaos durch AI‑Tools entstanden ist und du einen sicheren, produktionsorientierten Cleanup‑Plan brauchst, kann FixMyMess (fixmymess.ai) Teams helfen, verzwickte Authentifizierung zu diagnostizieren, doppelte Cookies und Session‑Pfadde zu entfernen und den Code zu härten, bevor in Produktion etwas kaputtgeht.