Authentication und authorization 🔐

1. „Den Endpoint schließen"

Wenn das Team sagt „dieser Endpoint muss geschlossen werden", meint es fast immer eigentlich zwei verschiedene Aufgaben.

Die erste Aufgabe: verstehen, wer den Request stellt. Das ist die Frage nach der Identität des Callers. Das System muss zwischen einem anonymen Client und einem bekannten Nutzer unterscheiden – und einen Nutzer vom anderen. Genau diese Arbeit erledigt authentication.

Die zweite Aufgabe: verstehen, was diesem Caller erlaubt ist. Selbst wenn das System bereits weiß, wer gekommen ist, bedeutet das noch nicht, dass die Aktion zulässig ist. Ein gewöhnlicher Nutzer kann sich erfolgreich anmelden und dennoch kein Recht haben, Inhalte zu veröffentlichen oder anderen Nutzern Rollen zu ändern. Diese Arbeit erledigt authorization.

Es ist sehr wichtig zu spüren, dass das keine zwei Namen für dieselbe Prüfung sind. Das sind zwei verschiedene Entscheidungen. Das öffentliche Lesen eines veröffentlichten Artikels ist ein gutes Beispiel, wo authorization „erlaubt" sagt, obwohl authentication überhaupt nicht stattfinden muss. Und der Versuch eines gewöhnlichen Nutzers, eine Editor-Operation aufzurufen, ist ein gutes Beispiel, wo authentication bereits erfolgreich ist, aber authorization trotzdem „Nein" sagt.

2. Authentication: Wer stellt den Request?

Authentication beantwortet die Frage „Wer steht vor mir?". Im klassischen Szenario geschieht das über Login und Passwort, aber auf der Ideenebene ist wichtiger: Das System muss einen vertrauenswürdigen Weg erhalten, um einen Request einem konkreten Caller zuzuordnen.

record LoginRequest(String username, String password) {}

In diesem Modell sind password keine „Profildaten". Das ist das Mittel, mit dem der Caller seine Identität bestätigt. Hier taucht also schon ein wichtiges Wort auf: credentials. Credentials sind Bestätigungsdaten. Im Username/Password-Szenario ist das das Passwort. Später im Kurs siehst du andere Bestätigungsformen, aber jetzt reicht es, das Prinzip selbst zu verinnerlichen.

Nach erfolgreicher Bestätigung muss das System nicht das gesamte Domain-Profil des Nutzers mit sich schleppen. Für Security-Entscheidungen wird meist ein kompakteres Objekt benötigt – ein principal. Principal ist die Security-Repräsentation des Callers, nicht die ganze Biografie des Nutzers aus der DB. Manchmal ist das der Username, manchmal die id, manchmal eine Kombination mehrerer Felder. Das Ziel: Der Security-Layer braucht keinen unnötigen Domain-Ballast.

Es ist sehr nützlich, den Unterschied zwischen zwei Formulierungen zu spüren. „Wir haben einen Nutzer in der DB" – das ist noch keine authentication. „Das System betrachtet den aktuellen Request als Request eines konkreten Callers" – das kommt der Sache schon näher. Ohne diese Verknüpfung hängt das gesamte Gespräch über Zugriff in der Luft.

3. Authorization: Nicht alles ist erlaubt 🚦

Sobald der Caller dem System bekannt ist, beginnt die nächste Frage: „Und was ist ihm jetzt erlaubt?" Hier lebt authorization.

Stell dir typische Szenarien unseres Projekts vor. GET /api/public/articles kann ohne bestätigten Nutzer erlaubt sein. GET /api/me erfordert bereits einen bekannten Caller. POST /api/editor/drafts/{id}/publish erfordert nicht nur einen bekannten Caller, sondern auch einen bestimmten Rechtesatz. Und GET /api/drafts/{id} bringt noch eine weitere Komplexitätsstufe: Es reicht nicht zu wissen, wer das ist; man muss verstehen, ob er eine Beziehung zu dem konkreten Objekt hat.

Hier lohnt es sich, einen einfachen Gedanken zu verinnerlichen: Ein Nutzer kann authentifiziert und gleichzeitig nicht autorisiert sein. Das ist kein „kaputtes System", sondern im Gegenteil ein Zeichen, dass das System Zustände unterscheiden kann. Es weiß, wer gekommen ist, und kann trotzdem sagen: „Diese Person darf diese Aktion nicht ausführen."

Das gilt auch umgekehrt: Eine Aktion kann ohne Authentifizierung autorisiert sein. Ein öffentlicher Artikel ist ein erlaubtes Szenario für anonyme Clients. Das heißt, authentication und authorization sind nicht nur inhaltlich verschieden, sie müssen auch nicht immer als Paket „entweder beide oder keiner" auftreten.

4. Principal, credentials, role und authority: wie man sie auseinanderhält 🧩

Jetzt lässt sich das grundlegende Vokabular in einem kompakten Bild zusammenfassen. Die folgenden Begriffe werden nicht für eine Glossar-Prüfung benötigt, sondern damit das System im Code, der Konfiguration und im Team einheitlich besprochen werden kann.

Role in unserem Projekt ist zum Beispiel USER, EDITOR, ADMIN. Das ist eine praktische grobe Zugriffsschicht. Authority ist ein genaueres Recht, etwa draft:publish oder user:manage. Nicht jeder Kurs muss tief in ein detailliertes Rechtemodell einsteigen, aber grobe Rollen und genaue Rechte von Anfang an zu unterscheiden ist sinnvoll.

Besonders wichtig ist es, Ownership nicht mit einer Rolle zu verwechseln. Die Regel „das ist mein Entwurf" lebt nicht innerhalb von USER als solchem. Alle gewöhnlichen Nutzer können dieselbe Rolle haben, aber unterschiedliche Entwürfe. Deshalb ist owner-only keine Variante einer Rolle, sondern ein eigener Prüfungstyp, der an der Beziehung zwischen Caller und konkretem Objekt hängt.

5. Session, token und SecurityContext – vorerst auf Ideenebene

Auf dem ersten Level brauchst du noch keine Details über Filter und interne Mechanik, aber drei Begriffe sind jetzt nützlich einzuführen, damit später kein Gefühl von „wo kommt das überhaupt her?" entsteht.

Session ist ein Stateful-Modell, bei dem sich der Server merkt, dass Requests dieses Clients zu einem bereits bestätigten Nutzer gehören. Token ist ein anderer Weg, einen Request mit einem Caller zu verknüpfen: Der Client bringt ein spezielles Zugangsartefakt mit, und der Server rekonstruiert daraus die Identität und die Rechte. Das sind verschiedene Modelle, und der Kurs wird beide zeigen – aber nicht durcheinanderbringen.

Noch ein feiner Unterschied ist wichtig: Passwort und bearer token sollte man nicht als vollständige Synonyme bezeichnen. Im klassischen Login-Flow ist das Passwort die credentials. Im Stateless-Modell wird der token zu einem eigenen Zugangsartefakt mit eigenen Lebensregeln und eigenen Risiken. Wenn man diese Begriffe zu früh gleichsetzt, wird das spätere Gespräch über Stateful- und Stateless-Modelle verwirrend.

SecurityContext auf Ideenebene ist der Ort, wo die Anwendung das aktuelle Security-Bild des Requests hält. Wer ist gerade der Caller? Gilt er als authentifiziert? Welche Rechte hat er? Für jetzt reicht genau dieser allgemeine Gedanke. Später wirst du sehen, wie dieses Bild technisch zusammengestellt wird. Heute ist nur wichtig zu verstehen, dass das System einen „Ort der Wahrheit" über den aktuellen Caller haben muss.

6. Ohne das Vokabular wirkt Spring Security wie Magie 🪄

Wenn die Begriffe durcheinandergebracht werden, wirkt das Framework immer beängstigender als es ist. Dann scheint SecurityContext ein rätselhafter Container für „irgendetwas über den Nutzer" zu sein, roles und authorities werden unklar, token und credentials klingen wie austauschbare Wörter, und authentication und authorization verschmelzen zu einem einzigen verschwommenen Begriff „na ja, Security eben".

Sobald das Vokabular aber sitzt, vereinfacht sich vieles 💡 Später begegnet dir SecurityContext, AuthenticationManager, SecurityFilterChain, Request-Level-Regeln und Method-Level-Regeln. Und sie werden nicht mehr in der Luft hängen. Du kannst sie durch ganz normale menschliche Fragen lesen: Wer stellt den Request, womit wird das bestätigt, wo wird das aktuelle Security-Bild gespeichert und was darf dieser Caller.

Deshalb darf das Vokabular nicht als trockene „theoretische Insel" betrachtet werden. Es wird nicht um seiner selbst willen gebraucht, sondern damit die nachfolgende Mechanik als ingenieurtechnische Logik lesbar wird – und nicht als Magie. Wenn die Sprache nicht aufgebaut ist, wird jede Security-Konfiguration zum Abschreiben von Zauberformeln. Wenn die Sprache aufgebaut ist, wird die Konfiguration erklärbar.

7. Typische Fehler 🙀

Fehler Nr. 1: authentication und authorization als ein und dasselbe Wort verwenden.
Das ist die grundlegendste Verwechslung, aus der dann fast alle anderen entstehen. Zuerst muss das System verstehen, wer der Caller ist. Und erst dann – was ihm erlaubt ist. Manchmal ist das erste schon vorhanden, das zweite aber noch nicht. Manchmal erlaubt das zweite die Aktion trivialerweise sogar ohne das erste.

Fehler Nr. 2: principal für die vollständige Domain-Entität des Nutzers halten.
Wenn in den Security-Layer das gesamte Profil, überflüssige Felder und Business-Daten hineingezogen werden, wird das System schwerer und weniger transparent. Der Security-Layer braucht normalerweise eine kompakte Antwort auf die Frage „Wer ist das?" – nicht die gesamte Geschichte des Nutzers.

Fehler Nr. 3: Rolle und Ownership verwechseln.
Die Rolle USER weiß nicht, wessen Entwurf das genau ist. Wenn man versucht, die Aufgabe „eigener/fremder" nur über Rollen zu lösen, öffnet man fast sicher entweder zu viel Zugriff oder sperrt einen benötigten Szenario.

Fehler Nr. 4: session und token als gleiche Mechanismen bezeichnen.
Beide helfen, einen Request mit einem Caller zu verknüpfen, tun das aber auf grundlegend verschiedene Weisen. Wenn man diesen Unterschied zu früh glättet, ist es später schwer zu verstehen, warum Stateful- und Stateless-Modelle so unterschiedliche Kompromisse haben.