KI-generierte Login-Probleme in Produktion: ein Troubleshooting‑Ablauf

Wie sich "funktioniert lokal"-Login-Fehler zeigen

Ein Login kann in Produktion auf den ersten Blick korrekt aussehen und trotzdem kaputt sein. Das Formular wird abgeschickt, du siehst eine „Erfolg“-Antwort und landest dann wieder auf der Login-Seite.

Typische Symptome sind:

• Eine Redirect-Schleife zwischen Login-Seite und App
• Du wirkst für eine Seite angemeldet, und bist dann plötzlich ausgeloggt
• Nach einem Refresh bekommst du 401 oder 403, obwohl es kurz vorher funktioniert hat
• OAuth wird abgeschlossen, aber die App verhält sich weiterhin wie abgemeldet
• Es funktioniert in einem Browser oder auf einem Gerät, und auf einem anderen nicht

Der Grund ist normalerweise langweilig: Authentifizierung hängt von kleinen Umgebungsdetails ab, die sich zwischen lokal und Produktion ändern. Lokale Entwicklung ist oft ein Host, kein Proxy, einfache Cookies und plain HTTP. Produktion bringt HTTPS, echte Domains, Reverse-Proxies und manchmal eine getrennte API-Domain. Diese Unterschiede beeinflussen, wie Cookies gespeichert werden, welche Header der Server sieht und wohin Redirects führen.

Ein typisches Beispiel: Lokal meldest du dich an und ein Session-Cookie wird gesetzt und gespeichert. In Produktion sendet der Server das Cookie vielleicht weiterhin, aber der Browser weigert sich, es zu speichern, weil die Cookie-Flags nicht zur echten Umgebung passen (häufig SameSite und Secure). Das Backend denkt, du bist angemeldet, aber der Browser schickt dieses Cookie nie zurück. Außenstehend sieht das nach zufälligen Logouts oder einer endlosen Weiterleitung aus.

Rate nicht und baue nicht gleich das ganze Auth-System neu. Finde den genauen Schritt, an dem der Flow nicht mehr stimmt:

• Hat der Server ein Cookie oder Token gesendet?
• Hat der Browser es gespeichert?
• Enthielt die nächste Anfrage das Cookie/Token?
• Führte der Redirect zur richtigen Domain?
• Akzeptierte die API die Session oder das Token?

Die meisten Produktions-Auth-Fehler sind Konfigurations- und Cookie-Verhalten, nicht das Login-Formular.

Teams wie FixMyMess sehen das oft in KI-erstellten Prototypen: Die UI sieht fertig aus, aber Regeln für Domains, HTTPS und Sessions wurden nie sorgfältig gehandhabt.

Bevor du Code anfasst: Sammle ein sauberes Repro-Case

Die schnellsten Erfolge kommen meist von einem sauberen, reproduzierbaren Repro, nicht vom Raten. Wenn du den Bug gezielt auslösen kannst, lässt sich die Lösung schnell nachweisen.

Schreibe das genaue Szenario auf, damit jemand anderes es ohne Rückfragen nachstellen kann. Füge Gerät (Desktop oder Mobil), Browser-Name und -Version, die exakte Startseite und welches Benutzerkonto du verwendet hast, hinzu. Tritt es nur im Inkognito-Modus, über Mobilfunk oder nach langer Tab-Öffnungszeit auf? Halte das fest.

Gib außerdem genau an, wo es scheitert. Viele „Login-Bugs“ treten nicht auf dem Login-Screen auf, sondern direkt danach:

• Du sendest das Formular und landest wieder auf der Login-Seite
• OAuth wirkt erfolgreich, aber der Callback wird nie abgeschlossen
• Du landest in der App, aber der erste API-Call liefert 401 und du wirst rausgeschmissen
• Es funktioniert einmal, dann nach einem Refresh oder nach 10–30 Minuten nicht mehr

Definiere Erfolg konkret. Nimm ein oder zwei Prüfungen, die du jedes Mal benutzt, z. B.: ein Session-Cookie existiert, ein Token ist gespeichert oder dein "current user"-Endpoint gibt 200 zurück. Ohne das „fixen“ Teams nur den UI-Zustand, während der Server den Nutzer noch als anonym betrachtet.

Füge Timing- und Identitäts-Hinweise hinzu. Notiere ein oder zwei Zeitstempel (auf Minuten genau) beim Reproduzieren. Wenn dein Backend Request-IDs, Session-IDs oder Trace-IDs ausgibt, notiere auch diese. Diese Brotkrumen verbinden oft ein Browser-Symptom mit dem genauen Server-Error.

Ein schnelles Repro-Template

Schreibe es wie einen Mini-Testfall:

• Environment: Produktion, Browser + Version, Gerät
• Steps: Klick-für-Klick-Pfad vom ausgeloggten Zustand
• Erwartet: dein gewähltes Erfolgssignal (Cookie gesetzt, Token gespeichert, "current user" gibt 200)
• Tatsächlich: was du gesehen hast (Redirect-Schleife, Fehlerseite, plötzliches Ausloggen)

Ein realistisches Beispiel

Ein häufiges Muster ist „funktioniert lokal, nur auf der deployten Domain fehlerhaft“. Du meldest dich an, siehst einen kurzen Redirect und landest dann wieder auf der Login-Seite.

Deine Erfolg-Definition könnte sein: „Nach dem Login gibt die current-user-Anfrage 200 zurück und das Session-Cookie ist vorhanden.“ Wenn du das in Produktion reproduzierst und die Anfrage 401 liefert, hast du den Fehler eingegrenzt. Es ist nicht die Passwort-Überprüfung; es ist Session-Persistenz, Cookie-Einstellungen, Callback-Handling oder ein Proxy/Domain-Mismatch.

Wenn du ein chaotisches KI-erstelltes Codebase übernimmst, hilft dieses saubere Repro auch Diensten wie FixMyMess bei der schnelleren Diagnose, weil klar wird, ob der Bruch beim Login, Callback, Refresh oder beim ersten authentifizierten API-Call liegt.

Schritt 1: Verfolge den Login-Flow im Browser

Die schnellste Methode, um aufzuhören zu raten, ist zu beobachten, was der Browser tatsächlich sendet und empfängt. Die meisten Auth-Fehler zeigen sich deutlich im Network-Tab.

Öffne ein Inkognito-Fenster, damit du mit null Cookies und Cache startest. Öffne DevTools und halte das Network-Panel sichtbar, während du dich anmeldest.

Worauf du im Network-Tab achten solltest

Finde die Anfrage, die die Zugangsdaten abschickt (oft ein Login- oder Session-Endpoint). Schau auf den Statuscode, aber hör nicht bei "200" auf. Eine erfolgreiche Antwort kann trotzdem fehlschlagen, weil sie keine Session setzt oder kein nutzbares Token zurückgibt.

Folge dann den nächsten Anfragen. Nutzt dein Flow Redirects (typisch bei OAuth), klicke jede Redirect-Antwort an und prüfe den Location-Header. Viele Produktionsfehler kommen von Redirects zur falschen Domain, zum falschen Pfad oder zu HTTP statt HTTPS.

Eine kurze Anleitung zum Durchlaufen des Flows:

• Identifiziere die erste Auth-Anfrage und notiere den Statuscode.
• Bestätige bei Redirect-Antworten, dass Location dorthin zeigt, wohin du erwartest.
• Untersuche Response-Header auf Set-Cookie.
• Achte auf DevTools-Warnungen über blockierte Cookies.
• Bestätige, dass der nächste API-Call ein Cookie-Header oder ein Authorization-Header enthält.

Bestätige, dass der Browser die Session akzeptiert hat

Wenn du Set-Cookie in der Antwort siehst, kann der Browser es trotzdem ablehnen. Chrome zeigt den Grund oft in den Cookie-Details oder im Issues-Tab (SameSite, Secure, Domain- oder Path-Mismatches sind häufig).

Prüfe zuletzt den ersten authentifizierten API-Call nach dem vermeintlich erfolgreichen Login, z. B. current-user oder profile. Sieh dir die Request-Header an. Fehlt ein Cookie oder ein Authorization-Token, trägt der Client deinen Login-Nachweis nicht weiter. Das grenzt ein: Es ist nicht "das Backend hat mich vergessen", sondern "der Client hat keinen Beweis übermittelt".

Ein Muster, das FixMyMess häufig sieht: Lokal funktioniert alles, aber in Produktion schließt der OAuth-Callback ab und die UI zeigt trotzdem "ausgeloggt". Im Network-Tab erkennt man meist genau den Moment, in dem das Cookie für eine lokale Host-Variante gesetzt oder wegen fehlendem Secure auf einer HTTPS-Seite blockiert wurde.

Schritt 2: Behebe Cookie-Flags, die Sessions zerstören

Cookies sind eine häufige Ursache für "funktioniert lokal"-Auth-Probleme. Lokale Entwicklung ist nachsichtig, Produktion nicht.

Beginne damit, Cookies unmittelbar nach einer erfolgreichen Login-Antwort zu prüfen. Suche das Session-Cookie (oder Refresh-Token-Cookie) und ob es tatsächlich gespeichert und bei der nächsten Anfrage gesendet wird.

Flags, die entscheiden, ob dein Cookie überlebt

Domain und Path bestimmen, wohin das Cookie gesendet wird. Wenn Frontend und API auf verschiedenen Hosts liegen, wird ein zu eng gesetztes Cookie nie dort drin sein, wo du es brauchst. Auch der Path kann stören: Ein Cookie, das nur für einen Auth-Pfad gesetzt ist, wird nicht an andere API-Routen gesendet.

SameSite ist der große Punkt für OAuth und Cross-Site-Redirects. Wenn der Flow beinhaltet, deine Seite zu verlassen und zurückzukehren, kann SameSite das Cookie zwischen den Hops verschwinden lassen. Bei vielen OAuth-Fällen brauchst du SameSite=None, und dafür gilt die harte Regel: es muss außerdem Secure gesetzt sein.

Secure weist den Browser an, das Cookie nur über HTTPS zu senden. Das ist in Produktion korrekt, kann aber auf Staging oder anderen Umgebungen, die noch HTTP nutzen, Probleme machen.

HttpOnly verhindert, dass JavaScript das Cookie liest. Das ist meistens wünschenswert. Ein häufiger Fehler in KI-Code ist, dass Frontend-Code versucht, das Session-Cookie auszulesen und fälschlich annimmt, das Login sei fehlgeschlagen, wenn es nicht zugreifbar ist.

Bevor du Code änderst, prüfe diese üblichen Fallen:

• Cookie-Domain stimmt mit dem echten Produktions-Host überein (keine lokalen Werte)
• Cookie-Path ist breit genug (oft Root /)
• SameSite passt zu deinem Flow (besonders bei OAuth-Redirects)
• Secure ist in HTTPS-Umgebungen aktiviert
• Es existieren keine doppelten Cookies mit gleichem Namen, aber unterschiedlichen Domain/Path-Scopes

Ein kurzes Beispiel: Ein Gründer deployed hinter einem Reverse-Proxy, OAuth "succeeds", aber die App kehrt in den ausgeloggten Zustand zurück. DevTools zeigt zwei Cookies mit dem gleichen Session-Namen, jeweils verschieden gescopt. Der Browser sendet das falsche und der Server lehnt ab. Das sieht oft nach zufälliger Auth aus, bis du die Cookie-Scopes inspizierst.

Schritt 3: Prüfe HTTPS, Domains und Reverse-Proxies

Wenn es lokal funktioniert, in Produktion aber nicht, liegt der Verursacher oft außerhalb deiner Auth-Logik: HTTPS, die öffentliche Domain und wie deine App hinter einem Proxy sitzt.

Sorge dafür, dass die App Protokoll und Host richtig kennt

Viele Produktions-Setups stellen die App hinter einen Load-Balancer oder Reverse-Proxy. Der Browser spricht mit dem Proxy über HTTPS, aber deine App sieht die eingehende Anfrage als plain HTTP, sofern sie Forwarded-Header nicht vertraut.

Dann treten Symptome auf wie Cookies ohne Secure, Redirects zu HTTP und OAuth-Flows, die fehlschlagen, weil die App die falsche Callback-URL baut.

Schnelle Prüfungen:

• Drucke im Server-Log das Protokoll und den Host, den die App glaubt empfangen zu haben.
• Verifiziere, dass der Proxy Forwarded-Header sendet (Protocol und Host sind üblich).
• Sorge dafür, dass deine App so konfiguriert ist, dem Proxy zu vertrauen, damit sie diese Header sicher nutzt.

Beende Redirect-Schleifen und "am falschen Ort" Redirects

Ein klassisches Produktionsproblem: Du meldest dich an, landest kurz in der App und wirst dann wieder zur Login-Seite gebounced. Oft war das Login erfolgreich, aber die Redirect-Kette wechselt zwischen HTTP/HTTPS oder zwischen zwei Hosts.

Prüfe den Network-Tab auf genaue Redirect-Ziele. Achte auf Muster wie:

• HTTP → HTTPS → HTTP Schleifen
• Redirects zu einer Staging- oder alten Domain
• Redirects zu einem lokalen Port, der in Produktion nicht existiert

Stelle außerdem sicher, dass jede auth-bezogene URL die öffentliche Domain nutzt. OAuth-Provider sind strikt: Wenn deine registrierte Callback-URL eine Adresse ist, das App aber Nutzer woanders hinschickt, schlägt es fehl.

Subdomains, Cookie-Scope und Browser-Blocking

Wenn du mehrere Subdomains verwendest (z. B. eine für die App und eine für die API), entscheide, ob Cookies geteilt oder isoliert sein sollen. Geteilte Cookies brauchen oft einen Parent-Domain-Scope; isolierte Cookies sollten das vermeiden.

Browser-Privacy-Features spielen eine Rolle. Wenn dein Login auf Cookies in einem Drittseiten-Kontext (eingebettete Flows, Cross-Site-Redirects) angewiesen ist, blockieren manche Browser diese, sofern SameSite und Secure nicht korrekt gesetzt sind.

Wenn du eine zweite Meinung zu Proxy- und Domain-Mismatches willst, findet FixMyMess oft während eines kostenlosen Audits die genaue Redirect- oder Header-Ursache.

Schritt 4: Debugge OAuth-Callbacks und Redirects

OAuth-Fehler wirken verwirrend, weil der Browser zwischen Sites springt und der Fehler auf der Provider-Seite, deiner Callback-Route oder gar nicht sichtbar auftreten kann.

Bestimme, wo es scheitert

Reproduziere das Login und achte darauf, wo du landest:

• Wenn du auf einer Provider-Fehlerseite landest, lehnt der Provider deine Anfrage ab (oft Redirect-URI-Mismatch).
• Wenn du zur eigenen Site zurückspringst und einen App-Fehler siehst, scheitert dein Callback-Handler oder der Token-Exchange.
• Wenn du scheinbar erfolgreich zurückkehrst, aber dennoch abgemeldet wirkst, wurde der Callback vielleicht abgeschlossen, aber die Session nicht gespeichert.

Wirkungsvolle Prüfungen:

• Vergleiche die konfigurierte Redirect-URI mit der tatsächlich genutzten Callback-URL Zeichen für Zeichen (Scheme, Domain, Pfad, Trailing-Slash).
• Bestätige, dass die richtigen Environment-Variablen für diese Deployment-Umgebung verwendet werden (Client ID, Client Secret, Issuer, App-Base-URL).
• Stelle sicher, dass State (und nonce für OIDC) erzeugt, gespeichert und nach dem Redirect validiert wird.
• Verifiziere, dass der Callback deine Backend-Route erreicht und der Authorization-Code vorhanden ist.
• Prüfe, dass der Code-Austausch Tokens zurückgibt und dass Fehler nicht verschluckt werden.

Häufige Mismatch-Muster

Redirect-URI-Mismatches sind selten offensichtlich. Typische Fehler sind HTTP vs HTTPS, unterschiedliche Subdomains, gemischte Callback-Pfade oder ein zusätzlicher Trailing-Slash an einer Stelle.

State- und Nonce-Bugs sind in KI-generiertem Code oft zu sehen. Wenn die App State im Speicher ablegt, gehen serverlose Deployments oder mehrere Instanzen es zwischen den Redirects verlieren. Wenn State per Cookie gespeichert wird, überlebt das Cookie den Cross-Site-Bounce möglicherweise nicht.

Ein realistisches Beispiel: Google-Login funktioniert lokal, in Produktion kommt „Invalid state“. Ursache ist oft, dass die Base-URL der App noch auf lokale Entwicklung zeigt, sodass das State-Cookie für den falschen Host gesetzt wird und beim Callback nicht zurückkommt.

Wenn du eine zweite Meinung brauchst, beginnt FixMyMess meist damit, die genaue Redirect-URI, State-Speicherung und die Response des Token-Exchanges abzubilden, damit der Fehlerpunkt schnell klar wird.

Schritt 5: Validiere JWTs und Token-Refresh

Wenn das Login „funktioniert“, Nutzer aber nach einem Refresh, in einem neuen Tab oder nach 10–30 Minuten ausgeloggt werden, behandle es bis zum Gegenbeweis als Token-Problem. Kleine Unterschiede bei Zeit, Keys und Validierungsregeln können ein lokal gültiges Token in Produktion unbrauchbar machen.

Fang mit dem an, was der Server über das Token denkt

Dekodiere das Token und prüfe dessen Ablaufzeit. Vergleiche das mit der Serverzeit. Ein paar Minuten Clock-Skew können ein brandneues Token als abgelaufen erscheinen lassen, was sich in zufälligen 401s äußert.

Bestätige dann, dass Signing und Validierung in Produktion übereinstimmen:

• Algorithmus: Server und Client müssen beim Signieren übereinstimmen.
• Secret oder Keys: Verifiziere, dass das deployte Signing-Secret oder der Public Key der ist, den der Server tatsächlich verwendet.
• Validierungsregeln: Prüfe Issuer und Audience. Diese unterscheiden sich oft zwischen lokal und Produktion, besonders wenn Beispielwerte aus KI-Snippets kopiert wurden.

Ein verbreiteter „funktioniert lokal“-Fall: Lokal werden Issuer/Audience-Checks zur Bequemlichkeit übersprungen, in Produktion erzwingt Middleware sie. Das Token ist gültig, der Server lehnt es aber wegen falscher Audience ab.

Beweise, dass Refresh nach realem Nutzerverhalten funktioniert

Token-Refresh muss nach einem Reload oder in einem neuen Tab funktionieren. Teste eine realistische Abfolge: Einloggen, Tab schließen, Seite neu öffnen und einen API-Call machen. Wenn die App das Access-Token nur im Speicher hält, ist es nach Reload weg und der Nutzer wirkt ausgeloggt.

Überlege genau, wo Tokens liegen. Persistente Speicherung über Reloads ist praktisch, erhöht aber das Risiko bei XSS. Cookies können sicherer sein, wenn sie richtig gesetzt sind, aber Cookie-Token werden fallen gelassen, wenn Flags oder Domain-Einstellungen nicht passen.

In vielen geerbten KI-Projekten ist der Refresh-Flow halb fertig: Es wird ein Refresh-Token ausgegeben, aber nie genutzt, oder der Client speichert das aktualisierte Token nicht. Der Login-Endpunkt sieht dann sauber aus, aber der „nach Refresh“-Pfad wurde nie getestet.

Eine schnelle Plausibilitätsprüfung: Logge auf dem Server den Ablehnungsgrund für das Token (abgelaufen vs Signature vs Issuer/Audience). Ohne diese Information rätst du nur.

Server-seitige Checks: CORS, CSRF und Session-Storage

Browser-Hinweise sind nur die halbe Geschichte. Der Server kann Anfragen still ablehnen oder Sessions an einem Ort speichern, den deine App nicht zuverlässig ausliest.

CORS: Erlaube die echte Origin (und Credentials)

CORS-Probleme sehen oft so aus: "Es hat eingeloggt, aber die nächste Anfrage ist anonym." In Produktion hast du meist unterschiedliche Frontend- und API-Origins.

Stelle sicher, dass deine API explizit die Produktions-Origin erlaubt (nicht "*") und dass sie Credentials akzeptiert, wenn du Cookies nutzt. Wenn das Frontend mit credentials sendet, die API aber die nötigen CORS-Header nicht zurückgibt, ignoriert der Browser die Antwort oder verwirft Cookies.

Eine kurze Server-Checkliste:

• Erlaube die exakte Produktions-Origin (Scheme + Domain)
• Gib das Credentials-Header zurück, wenn du Cookies nutzt
• Behandle Preflight-Requests (OPTIONS) und returniere die erwarteten Header
• Vermeide mehrere widersprüchliche CORS-Middlewares
• Bestätige, dass erlaubte Header jene enthalten, die du tatsächlich sendest (z. B. Authorization)

CSRF: POST funktioniert lokal, aber nicht in Prod

Wenn Login POST verwendet (oder du Logout, Refresh, Profil-Updates hast), können CSRF-Regeln nur in Produktion brechen. Zwei häufige Ursachen sind fehlende CSRF-Tokens und strengere Cookie-Regeln.

Bei Cookie-basierten Sessions kann ein strenges SameSite verhindern, dass der Browser das Session-Cookie bei Cross-Site-POSTs sendet. Der Server lehnt dann die Anfrage ab, weil das CSRF-Token fehlt oder ungültig ist.

Zum schnellen Debuggen logge für die fehlerhafte Anfrage: Request-Origin, empfangene Cookies, CSRF-Token/Header und die Ablehnungsursache des Frameworks.

Session-Storage, Load-Balancing und Secrets

Ein klassischer Produktionsfehler: Du loggst dich ein, bekommst eine Session, und jede weitere Anfrage sieht aus wie ein neuer Nutzer. Das heißt oft: Sessions werden nicht über Instanzen geteilt.

Wenn du mehr als einen Serverprozess hast (oder dein Host auto-scaled), brauchst du entweder Sticky Sessions oder einen gemeinsamen Session-Store. Bestätige auch, dass Session-Cookie-Name und Key-Prefixes über Instanzen hinweg konsistent sind.

Prüfe Environment-Variablen: Ein fehlendes Auth-Secret, Signing-Key oder Session-Encryption-Key führt nach Deploys zu "zufälligen" Logouts, weil die App auf Defaults zurückfällt. Wenn dieser Default sich nach Neustarts ändert, werden bestehende Sessions unlesbar.

Wenn du ein KI-erzeugtes Projekt geerbt hast und serverseitiges Auth-Verhalten zwischen Umgebungen inkonsistent ist, kann FixMyMess mit einer kostenlosen Code-Analyse die spezifischen CORS-, CSRF-, Session-Store- und Secret-Probleme identifizieren, bevor du einen kompletten Rebuild planst.

Häufige Fallen in KI-generiertem Auth-Code

KI-generierte Auth funktioniert lokal oft, weil dort alles einfach ist: eine Domain, ein Port, kein Proxy und meist plain HTTP. Produktion bringt HTTPS, echte Domains und Reverse-Proxies. Kleine Annahmen werden zu großen Fehlern und der Browser liefert nur eine vage Redirect-Schleife.

Ein Muster, das viel Schmerz verursacht, ist das Vermischen von Auth-Stilen ohne klare Regeln. Z. B. setzt die App nach Login ein Session-Cookie, die API erwartet aber einen Bearer-Token. Lokal sendest du vielleicht versehentlich beides und es "funktioniert einfach". In Produktion prüft ein Pfad das Cookie, ein anderer das Token, und du bist halb angemeldet.

Fallen, die immer wieder auftauchen

Achte bei Code- und Konfig-Reviews auf:

• Environment-Mismatch: lokale Annahmen zu HTTP, Domains und Ports gelangen in Produktion
• Zwei Wahrheitsquellen: Session-Cookies und JWTs existieren gleichzeitig ohne klare Regeln
• Hardcodierte URLs: OAuth-Redirects oder Callback-Werte sind in Code festgebacken
• Überraschungen bei Secret-Rotation: Redeploys ändern Signing-Keys oder Session-Secrets und loggen Nutzer aus
• Fehler werden verschluckt: Ein catch-Block gibt "ok" zurück oder redirected zur Login-Seite und versteckt so den echten 401/403-Fehler

Ein realistisches Beispiel: Eine KI-erzeugte App loggt lokal sauber ein. In Produktion schicken Nutzer das Login-Formular ab und landen wieder auf der Login-Seite. Die Ursache sind drei kleine Probleme zusammen: Cookie hat kein Secure, OAuth-Callback verwendet lokale Settings und Token-Errors werden gefangen und in Redirects verwandelt. Im Browser sieht man nur Redirects, also scheint "Auth kaputt" – in Wahrheit wurde das Cookie verworfen.

Wenn du ein Projekt von Lovable, Bolt, v0, Cursor oder Replit übernommen hast und diese Muster siehst, beginnt FixMyMess normalerweise damit, eine einzige Quelle der Wahrheit für Auth zu definieren und dann Secrets und Environment-Config zu verschlanken, damit Logins echten Traffic und Redeploys überstehen.

Eine kurze Checkliste, ein echtes Beispiel und die nächsten Schritte

Du sparst Stunden, wenn du die Basics in der richtigen Reihenfolge prüfst. Die meisten "funktioniert lokal"-Auth-Bugs sind nicht mysteriös. In der Regel sind es Cookies, die nicht gespeichert werden, Redirects an die falsche Stelle oder dass die App beim ersten API-Call keine Credentials sendet.

Eine schnelle Checkliste, die du in 5–10 Minuten abarbeiten kannst:

• Siehst du nach dem Login ein Set-Cookie-Header (oder eine Token-Antwort) im Network-Panel?
• Speichert der Browser das Cookie mit der erwarteten Domain, dem Path und Ablauf, oder wird es abgelehnt?
• Wird das Cookie bei der nächsten Anfrage gesendet (oder ist ein Authorization-Header auf dem ersten authentifizierten API-Call vorhanden)?
• Wenn du OAuth nutzt: Passt die Callback-URL in den Provider-Einstellungen exakt zu dem, was deine Produktions-App verwendet?
• Gibt der Server beim Code-Exchange 200 zurück, oder siehst du ein stilles 400/401 wegen falschem Secret, Redirect oder Proxy?

Ein reales Muster: OAuth funktioniert lokal, auf der Produktions-Domain jedoch nicht. Lokal klappt alles. In Produktion redirectet der Provider zurück, aber die App wird nicht als "eingeloggt" erkannt. Im Network-Panel sieht man oft: Der Callback trifft deinen Server, der Server versucht ein Session-Cookie zu setzen, aber das Cookie wird blockiert, weil Secure auf einer HTTPS-Seite fehlt oder weil SameSite für den Cross-Site-OAuth-Redirect zu streng ist. Die UI lädt, ruft sofort den current-user-Endpoint auf, diese Anfrage hat kein Cookie, der Server gibt 401, und die App bounce zurück zur Login-Seite.

Wenn der Flow noch unklar ist, geh davon aus, dass der Code verheddert ist, nicht du. KI-generierter Auth-Code mischt oft Client- und Server-Verantwortlichkeiten, dupliziert Session-Logic oder versteckt kritische Konfiguration an mehreren Stellen. Ein fokussiertes Audit ist meist schneller als Raten.

FixMyMess (fixmymess.ai) kann KI-generierte Auth-Flows diagnostizieren und reparieren, inklusive Cookies, JWT-Sessions, OAuth-Callbacks und Deployment-Readiness. Wenn du vor einer Änderung erst eine klare Liste der Fehler willst, bieten sie eine kostenlose Code-Analyse an, und viele Fixes landen innerhalb von 48–72 Stunden mit menschlicher Verifikation.