Ausgangslage
Ein interner Identitäts-Server verwaltet Konten und Sitzungen für mehrere Anwendungen. Er ist gut abgesichert, aber jede Anfrage erreicht ihn direkt. Solange die Anwendung sauber prüft, geht das gut. Sobald ein einziger Endpunkt die Prüfung überspringt, steht er offen im Netz.
Die Schicht davor
Die Zugriffsentscheidung gehört vor den Server, nicht in ihn hinein. Ein vorgelagertes Access-Gate lässt eine Anfrage nur weiter, wenn eine Identität bereits nachgewiesen ist:
- Der Nutzer authentifiziert sich einmal zentral.
- Erst danach wird die Anfrage an den eigentlichen Dienst durchgereicht.
- Der Dienst muss die Herkunft der durchgereichten Anfrage verifizieren, statt jedem Aufrufer zu vertrauen.
Der Fallstrick: der Bearer-Bypass
Viele Dienste akzeptieren zusätzlich zum Cookie einen Authorization: Bearer …-Header — praktisch für Maschinen und CI. Genau dieser Pfad umgeht das Gate, wenn der Server den Token selbst akzeptiert, ohne dass das Gate ihn gesehen hat. Das Ergebnis: die Tür ist zu, aber das Fenster daneben steht offen.
Zwei Regeln halten die Kette dicht:
- Ein Weg hinein, nicht zwei. Läuft der Verkehr über das Gate, darf der Dienst keinen zweiten, ungeprüften Header-Weg offen lassen.
- Signatur statt Vertrauen. Der Dienst akzeptiert durchgereichte Anfragen nur mit einem Nachweis, den ausschließlich das Gate ausstellen kann — nicht allein aufgrund eines mitgeschickten Tokens.
Ergebnis
Die Identitätsprüfung passiert einmal, an einer Stelle, bevor eine Anfrage überhaupt Anwendungscode erreicht. Der bequeme Bearer-Weg bleibt bestehen — aber nur hinter demselben Gate, nicht daran vorbei.