Drei Fehler, die gleich aussehen

„Der Login funktioniert nicht“ ist eine der unbefriedigendsten Fehlermeldungen überhaupt, weil zwischen Browser, Reverse-Proxy und Identity-Provider viele Schichten liegen. Innerhalb weniger Tage traten an derselben Anmeldeseite drei völlig verschiedene Probleme auf – die sich äußerlich verblüffend ähnelten. Genau das macht sie zu einem guten Lehrstück: Das Symptom sagt fast nichts über die Ursache.

Alle drei Fälle betrafen eine moderne SSO-Lösung hinter einem Reverse-Proxy. Die Muster sind aber allgemein: Sie treten bei jeder JavaScript-lastigen Anmeldeoberfläche auf, die über einen Proxy mit Ratelimit ausgeliefert wird.

Falle 1: Das Ratelimit blockt die Login-Oberfläche

Das erste Symptom: Die Anmeldeseite zeigte nur den Hintergrund – kein Eingabeformular. Ein Neuladen half meistens, aber nicht immer. Ein Fehler, der „manchmal“ auftritt und sich durch Neuladen bessert, riecht nach einem Timing- oder Mengenproblem.

Die Ursache steckte im Reverse-Proxy. Eine Ratelimit-Regel begrenzte die Anmeldedomain auf wenige Anfragen pro Minute – gedacht als Brute-Force-Schutz. Doch eine moderne Login-Oberfläche ist eine JavaScript-Anwendung: Beim Kaltstart lädt sie Dutzende Ressourcen parallel – Code-Bündel, Schriften, mehrere Konfigurations-Abfragen. Ein einziger Seitenaufruf sprengt so ein knappes Limit mühelos.

Die Messung bestätigte es: Ein echter Nutzer erzeugte im Kaltstart bis zu über hundert Anfragen pro Minute, das Limit lag bei wenigen Dutzend. In jedem zwölften Zeitfenster lief er darüber – und genau dann brach die Seite. Nebenbei zeigte sich, dass dieselbe Regel auch andere Dienste betraf: Bei der automatischen Mail-Client-Konfiguration wurde fast jede zweite Anfrage abgewiesen.

Der erste, schnelle Schritt war, das Limit auf einen realistischen Wert anzuheben – deutlich über den gemessenen Spitzen echter Nutzer, aber immer noch weit unter dem, was aggressive Scanner erzeugen. Denn die liefen mit dem Mehrfachen und sollen weiterhin gebremst werden.

Der saubere Fix: statische Dateien ausnehmen

Das Limit hochzusetzen behandelt das Symptom. Sauberer ist, das Ratelimit dort gar nicht erst greifen zu lassen, wo es nichts zu suchen hat: bei den statischen Dateien. Ein Brute-Force-Angriff findet an den Anmelde- und Token-Endpunkten statt, nicht beim Laden eines JavaScript-Bündels.

Die Lösung ist ein eigener Proxy-Router für den Pfad der statischen Ressourcen, der die Ratelimit-Regel nicht durchläuft. Das Limit bleibt scharf auf den Endpunkten, die zählen, und stört das Laden der Oberfläche nicht mehr.

Verifiziert wurde in beide Richtungen: Die statischen Dateien liefen jetzt auch unter Hunderten Anfragen ohne Limit durch – die Anmelde-Endpunkte wurden weiterhin sauber gedrosselt, und die Sicherheits-Header waren auf den statischen Dateien noch vorhanden. Ein Fix ist erst dann gut, wenn man auch beweist, dass er das Gewünschte nicht kaputtgemacht hat.

Falle 2: Selbst ausgesperrt, getarnt als „Not Found“

Der zweite Fall sah zunächst nach einem defekten System aus: Die Anmeldeseite lieferte schlicht „Not Found“. Kein Formular, keine Fehlermeldung – als wäre der Anmelde-Ablauf verschwunden.

Die Ursache war ein Reputations-basierter Brute-Force-Schutz. Solche Systeme senken bei jedem Fehlversuch einen Punktestand für die IP-Adresse; fällt er unter eine Schwelle, wird der Zugang zum Anmelde-Ablauf verweigert. Und hier kommt das entscheidende Detail:

Ausgelöst hatte es ein simpler Tippfehler: Die Anmeldung war mehrfach mit einer minimal falsch geschriebenen Adresse versucht worden. Jeder Fehlversuch senkte den Punktestand, bis die eigene IP gesperrt war. Man hatte sich mit dem eigenen Brute-Force-Schutz ausgesperrt.

Die Sofortmaßnahme ist, den Reputationseintrag der IP zurückzusetzen. Die dauerhafte Verbesserung: die Schwelle etwas großzügiger setzen. Drei Tippfehler und eine 24-Stunden-Sperre mit einer irreführenden Meldung ist für einen Administrator eine unnötig scharfe Falle – zumal eine zweite Schutzschicht (Abbruch des Ablaufs nach einigen Fehlversuchen) ohnehin greift. Der Schutz bleibt bestehen, er schnappt nur nicht mehr bei der kleinsten Unachtsamkeit zu.

Falle 3: Ein Syntaxfehler im Attribut-Mapping

Der dritte Fall war kein Login-Fehler im engeren Sinn, tauchte aber im selben Umfeld auf: Der Identity-Provider meldete bei jeder Anmeldung eines bestimmten Dienstes einen Konfigurationsfehler. Sichtbar war das nur intern – in keinem Alarmkanal (ein eigenes Kapitel, das an anderer Stelle beschrieben ist).

Solche Provider erlauben es, per kleiner Ausdrücke zusätzliche Attribute (Claims) an die angebundene Anwendung mitzugeben – hier etwa eine Vorlagenzuordnung für neue Nutzer. Der hinterlegte Ausdruck sollte ein einfaches Schlüssel-Wert-Paar zurückgeben. Er tat es nicht, denn er enthielt einen klassischen Anfängerfehler: fehlende Anführungszeichen.

Die Korrektur war ein Zeichenpaar – Anführungszeichen um Schlüssel und Wert. Doch bevor man so etwas „einfach repariert“, lohnt die Gegenprobe, dass Name und Wert überhaupt stimmen: Erwartet die angebundene Anwendung genau diesen Attributnamen? Existiert die referenzierte Vorlage auf der Gegenseite? Beides passte hier – nur die Syntax war kaputt. Ein korrekt geschriebener Ausdruck, der ins Leere zeigt, wäre die nächste Fehlersuche gewesen.

Verifiziert wurde durch direkte Auswertung des Ausdrucks: Statt einer Ausnahme lieferte er jetzt das erwartete Schlüssel-Wert-Paar, und es entstanden keine neuen Konfigurationsfehler mehr.

Lessons Learned

Zwischen Browser und Identity-Provider liegen viele Schichten, und jede kann eine Anmeldung auf ihre eigene Weise scheitern lassen. Die verlässlichste Diagnose beginnt nicht mit einer Vermutung, sondern mit der Frage, welche Anfrage genau welchen Fehlercode bekommt – und wo auf dem Weg das passiert.