Erfahren Sie, wie moderne Frameworks Authentifizierung und Autorisierung implementieren: Sessions, Tokens, OAuth/OIDC, Middleware, Rollen, Policies und wichtige Sicherheitsfallen.
Authentifizierung beantwortet „Wer bist du?“. Autorisierung beantwortet „Was darfst du tun?“. Moderne Frameworks behandeln sie als verwandte, aber getrennte Anliegen — und diese Trennung ist einer der Hauptgründe, warum Sicherheit konsistent bleibt, wenn eine App wächst.
Authentifizierung geht darum, zu beweisen, dass ein Benutzer (oder Dienst) die Identität ist, die er behauptet. Frameworks kodieren normalerweise keine einzige Methode fest; stattdessen bieten sie Erweiterungspunkte für gängige Optionen wie Passwort-Login, Social Login, SSO, API-Keys und Dienstanmeldeinformationen.
Das Ergebnis der Authentifizierung ist eine Identität: eine Benutzer-ID, Kontostatus und manchmal Basisattribute (z. B. ob eine E-Mail verifiziert ist). Wichtig: Authentifizierung sollte nicht entscheiden, ob eine Aktion erlaubt ist — nur wer die Anfrage stellt.
Autorisierung verwendet die etablierte Identität plus Kontext der Anfrage (Route, Ressourcen-Eigentümer, Mandant, Scopes, Umgebung usw.), um zu entscheiden, ob eine Aktion erlaubt ist. Hier leben Rollen, Berechtigungen, Policies und ressourcenbasierte Regeln.
Frameworks trennen Autorisierungsregeln von der Authentifizierung, damit Sie:
Die meisten Frameworks erzwingen Regeln durch zentrale Punkte im Request-Lifecycle:
Auch wenn die Namen variieren, sind die Bausteine vertraut: ein Identitätsspeicher (Benutzer und Zugangsdaten), eine Sitzung oder ein Token, das Identität zwischen Anfragen trägt, und Middleware/Guards, die Authentifizierung und Autorisierung konsistent durchsetzen.
Die Beispiele in diesem Artikel bleiben konzeptionell, damit Sie sie auf Ihr Framework übertragen können.
Bevor ein Framework jemanden „einloggen“ kann, braucht es zwei Dinge: einen Ort, um Identitätsdaten nachzuschlagen (den Identitätsspeicher), und eine konsistente Art, diese Identität im Code darzustellen (das Benutzer-Modell). Viele „Authentifizierungsfeatures“ in modernen Frameworks sind Abstraktionen um diese beiden Teile.
Frameworks unterstützen meist mehrere Backends, entweder eingebaut oder per Plugin:
users-Tabelle bzw. -Collection, verwaltet von Ihrer App.Der Schlüsselunterschied ist, wer die Quelle der Wahrheit ist. Bei Datenbank-Benutzern besitzt Ihre App Anmelde- und Profildaten. Bei einem IdP/Verzeichnis speichert Ihre App oft einen lokalen Shadow-Benutzer, der mit der externen Identität verknüpft ist.
Auch wenn Frameworks ein Standard-Benutzer-Modell generieren, standardisieren Teams meist ein paar Felder:
is_verified, is_active, is_locked, deleted_at.Diese Flags sind wichtig, denn Authentifizierung ist nicht nur „richtiges Passwort?“ — es ist auch „darf dieses Konto sich gerade anmelden?".
Ein praktischer Identitätsspeicher unterstützt Lifecycle-Ereignisse: Registrierung, E-Mail/Telefon-Verifizierung, Passwort-Reset, Session-Invalidierung nach sensiblen Änderungen und Deaktivierung bzw. Soft-Deletion. Frameworks bieten oft Primitive (Tokens, Zeitstempel, Hooks), aber Sie definieren Regeln: Ablaufzeiten, Rate-Limits und was mit bestehenden Sessions passiert, wenn ein Konto deaktiviert wird.
Die meisten modernen Frameworks bieten Erweiterungspunkte wie User Providers, Adapter oder Repositories. Diese Komponenten übersetzen „gegeben einen Login-Bezeichner, lade den Benutzer“ und „gegeben eine Benutzer-ID, lade den aktuellen Benutzer“ in Ihren gewählten Speicher — sei es eine SQL-Abfrage, ein Aufruf an ein IdP oder ein Enterprise-Verzeichnis-Lookup.
Sitzungsbasierte Authentifizierung ist der „klassische“ Ansatz, den viele Web-Frameworks noch standardmäßig für servergerenderte Apps verwenden. Die Idee ist einfach: der Server merkt sich, wer Sie sind, und der Browser hält einen kleinen Zeiger auf dieses Gedächtnis.
Nach einem erfolgreichen Login erstellt das Framework einen serverseitigen Session-Eintrag (oft eine zufällige Session-ID, die auf einen Benutzer zeigt). Der Browser erhält ein Cookie mit dieser Session-ID. Bei jeder Anfrage sendet der Browser das Cookie automatisch zurück, und der Server verwendet es, um den eingeloggten Benutzer nachzuschlagen.
Da das Cookie nur ein Identifikator ist (nicht die Benutzerdaten selbst), bleiben sensible Informationen serverseitig.
Moderne Frameworks versuchen, Session-Cookies schwerer zu stehlen oder missbrauchen, indem sie sichere Defaults setzen:
Diese Einstellungen finden Sie oft unter „Session-Cookie-Einstellungen“ oder „Security Headers“.
Frameworks lassen Sie meist einen Session-Store wählen:
Auf hoher Ebene ist der Trade-off Geschwindigkeit vs. Dauerhaftigkeit vs. Betriebskomplexität.
Logout kann zwei Dinge bedeuten:
Frameworks implementieren „Logout überall“ oft durch Verfolgung einer Benutzer-„Session-Version“, Speicherung mehrerer Session-IDs pro Benutzer und deren Widerruf. Wenn Sie stärkere Kontrolle (z. B. sofortiger Widerruf) benötigen, ist sessionsbasierte Auth oft einfacher als Tokens, da der Server eine Session sofort vergessen kann.
Token-basierte Authentifizierung ersetzt serverseitige Session-Lookups durch einen String, den der Client bei jeder Anfrage präsentiert. Frameworks empfehlen Tokens typischerweise, wenn Ihr Server hauptsächlich ein API ist (von mehreren Clients genutzt), wenn Sie mobile Apps haben, wenn Sie eine SPA haben, die mit einem separaten Backend spricht, oder wenn Dienste sich gegenseitig aufrufen müssen ohne Browser-Sessions.
Ein Token ist ein Zugangsberechtigungsnachweis, der nach Login (oder nach einem OAuth-Flow) ausgegeben wird. Der Client sendet ihn bei späteren Anfragen, damit der Server den Aufrufer authentifizieren und anschließend autorisieren kann. Die meisten Frameworks behandeln dies als First-Class-Pattern: ein „Issue Token“-Endpoint, Authentifizierungs-Middleware, die das Token validiert, und Guards/Policies, die nach der Identitätsfeststellung laufen.
Opaque Tokens sind zufällige Strings ohne Bedeutung für den Client (z. B. tX9...). Der Server validiert sie über einen Datenbank- oder Cache-Lookup. Das macht Widerruf einfach und hält Token-Inhalte privat.
JWTs (JSON Web Tokens) sind strukturiert und signiert. Ein JWT enthält typischerweise Claims wie eine Benutzerkennung (sub), Aussteller (iss), Audience (aud), Ausstell-/Ablaufzeiten (iat, exp) und manchmal Rollen/Scopes. Wichtig: JWTs sind standardmäßig kodiert, nicht verschlüsselt — jeder, der das Token besitzt, kann dessen Claims lesen, auch wenn er kein neues Token fälschen kann.
Framework-Empfehlungen konvergieren oft auf zwei sicherere Defaults:
Authorization: Bearer \u003ctoken\u003e Header für APIs. Das vermeidet CSRF-Risiken, die mit automatisch gesendeten Cookies einhergehen, erhöht aber die Anforderungen an XSS-Defenses, weil JavaScript typischerweise Tokens lesen und anhängen kann.HttpOnly, Secure und mit geeigneter SameSite-Einstellung setzen können und wenn Sie CSRF korrekt handhaben (oft gepaart mit separaten CSRF-Tokens).Access-Tokens sind kurzlebig. Um ständiges Einloggen zu vermeiden, unterstützen viele Frameworks Refresh-Tokens: langlebige Berechtigungsnachweise, die nur zum Ausstellen neuer Access-Tokens verwendet werden.
Eine gängige Struktur ist:
POST /auth/login → gibt Access-Token (und Refresh-Token) zurückPOST /auth/refresh → rotiert das Refresh-Token und gibt ein neues Access-TokenPOST /auth/logout → invalidiert Refresh-Tokens serverseitigRotation (bei jedem Refresh ein neues Refresh-Token ausgeben) begrenzt den Schaden, wenn ein Refresh-Token gestohlen wird. Viele Frameworks bieten Hooks, um Token-IDs zu speichern, Wiederverwendung zu erkennen und Sessions schnell zu widerrufen.
OAuth 2.0 und OpenID Connect (OIDC) werden oft zusammen genannt, aber Frameworks behandeln sie unterschiedlich, weil sie verschiedene Probleme lösen.
Verwenden Sie OAuth 2.0, wenn Sie delegierten Zugriff benötigen: Ihre App erhält die Erlaubnis, eine API im Namen des Nutzers aufzurufen (z. B. Kalender lesen oder in ein Repo posten), ohne das Passwort zu handhaben.
Verwenden Sie OpenID Connect, wenn Sie Login/Identität benötigen: Ihre App möchte wissen, wer der Benutzer ist, und ein ID-Token mit Identitätsclaims erhalten. In der Praxis ist „Login mit X“ meist OIDC auf OAuth 2.0.
Die meisten modernen Frameworks und Auth-Bibliotheken konzentrieren sich auf zwei Flows:
Framework-Integrationen bieten typischerweise eine Callback-Route und Helper-Middleware, aber Sie müssen die Essentials korrekt konfigurieren:
Frameworks normalisieren Anbieter-Daten meist in ein lokales Benutzer-Modell. Die entscheidende Designfrage ist, was die Autorisierung antreibt:
Ein gängiges Muster: Mappen Sie stabile Bezeichner (wie sub) auf einen lokalen Benutzer und übersetzen Sie Anbieter-Rollen/Gruppen/Claims in lokale Rollen oder Policies, die Ihre App kontrolliert.
Passwörter sind weiterhin die Standard-Anmeldemethode in vielen Apps, daher liefern Frameworks in der Regel sichere Speicherstandards und Schutzmaßnahmen. Die Kernregel bleibt: Sie dürfen nie ein Passwort (oder einen einfachen Hash davon) in der Datenbank speichern.
Moderne Frameworks nutzen standardmäßig zweckgebundene Passwort-Hasher wie bcrypt, Argon2 oder scrypt. Diese Algorithmen sind absichtlich langsam und beinhalten Salting, was vor vorgefertigten Tabellenangriffen schützt und das großskalige Knacken teuer macht.
Ein einfacher kryptografischer Hash (z. B. SHA-256) ist für Passwörter unsicher, weil er schnell ist. Wenn eine Datenbank geleakt wird, erlauben schnelle Hashes Angreifern, Milliarden von Passwörtern schnell zu probieren. Passwort-Hasher bieten Work-Faktoren (Cost-Parameter), die Sie an Hardware-Verbesserungen anpassen können.
Frameworks bieten Hooks oder Plugins, um sinnvolle Regeln durchzusetzen, ohne sie in jeden Endpunkt einzubauen:
Die meisten Ökosysteme unterstützen MFA als zweiten Schritt nach Passwortüberprüfung:
Passwort-Reset ist ein gängiger Angriffsvektor, daher empfehlen Frameworks Muster wie:
Eine gute Regel: Recovery für legitime Nutzer einfach machen, für Angreifer kostspielig zu automatisieren.
Die meisten modernen Frameworks behandeln Sicherheit als Teil der Request-Pipeline: eine Reihe von Schritten, die vor (und manchmal nach) Ihrem Controller/Handler ausgeführt werden. Die Namen variieren — Middleware, Filter, Guards, Interceptors — aber die Idee ist gleich: jeder Schritt kann die Anfrage lesen, Kontext hinzufügen oder die Verarbeitung stoppen.
Ein typischer Ablauf sieht so aus:
/account/settings).Frameworks empfehlen, Sicherheitsprüfungen außerhalb der Geschäftslogik zu halten, damit Controller sich auf „was zu tun ist" konzentrieren, statt auf „wer es tun darf".
Authentifizierung ist der Schritt, in dem das Framework den User Context aus Cookies, Session-IDs, API-Keys oder Bearer-Tokens herstellt. Wenn erfolgreich, erzeugt es eine an die Anfrage gebundene Identität — oft zugänglich als user, principal oder context.auth Objekt.
Diese Anbindung ist wichtig, weil spätere Schritte (und Ihr App-Code) Header nicht erneut parsen oder Tokens neu validieren sollten. Sie sollten das bereits befüllte Benutzerobjekt lesen, das typischerweise enthält:
Autorisierung wird oft umgesetzt als:
Der zweite Typ erklärt, warum Autorisierungs-Hooks oft nahe an Controllern und Services sitzen: sie benötigen ggf. Route-Parameter oder datenbankgeladene Objekte, um richtig zu entscheiden.
Frameworks unterscheiden zwei gängige Fehlerfälle:
Gut gestaltete Systeme vermeiden, in 403-Antworten Details zu verraten; sie verweigern den Zugriff, ohne zu erklären, welche Regel fehlgeschlagen ist.
Autorisierung beantwortet die engere Frage: „Darf dieser angemeldete Benutzer gerade dieses Ding tun?“ Moderne Frameworks unterstützen mehrere Modelle, und viele Teams kombinieren sie.
RBAC weist Benutzern eine oder mehrere Rollen zu (z. B. admin, support, member) und sperrt Features anhand dieser Rollen.
Es ist leicht verständlich und schnell implementiert, besonders wenn Frameworks Helfer wie requireRole('admin') bieten. Rollenhierarchien („admin impliziert manager impliziert member") können Duplikation reduzieren, aber auch Privilegien verschleiern: eine kleine Änderung an einer Elternrolle kann stillschweigend im gesamten System Zugriff gewähren.
RBAC eignet sich am besten für grobe, stabile Unterscheidungen.
Berechtigungsbasierte Autorisierung prüft eine Aktion gegen eine Ressource, oft ausgedrückt als:
read, create, update, delete, inviteinvoice, project, user, manchmal mit einer ID oder OwnershipDieses Modell ist präziser als RBAC. Beispielsweise ist „kann Projekte aktualisieren" anders als „kann nur Projekte aktualisieren, die er besitzt", was sowohl Berechtigungen als auch Datenbedingungen prüfen muss.
Frameworks implementieren das oft via einer zentralen can?-Funktion (oder Service), die aus Controllern, Resolvern, Worker oder Templates aufgerufen wird.
Policies bündeln Autorisierungslogik in wiederverwendbare Evaluatoren: „Ein Benutzer darf einen Kommentar löschen, wenn er ihn verfasst hat oder Moderator ist." Policies akzeptieren Kontext (Benutzer, Ressource, Anfrage) und sind ideal für:
Wenn Frameworks Policies in Routing und Middleware integrieren, können Sie Regeln konsistent über Endpunkte hinweg durchsetzen.
Annotationen (z. B. @RequireRole('admin')) halten die Absicht nahe am Handler, können aber fragmentiert werden, wenn Regeln komplexer werden.
Code-basierte Checks (explizite Aufrufe an einen Authorizer) sind ausführlicher, aber in der Regel einfacher zu testen und zu refaktorisieren. Ein häufiger Kompromiss: Annotationen für grobe Tore und Policies für detaillierte Logik.
Moderne Frameworks helfen nicht nur beim Einloggen — sie liefern auch Verteidigungen gegen die häufigsten Web-Angriffe rund um Authentifizierung.
Wenn Ihre App Session-Cookies verwendet, hängt der Browser diese automatisch an Anfragen an — manchmal sogar wenn die Anfrage von einer anderen Site ausgelöst wird. Framework-CSRF-Schutz fügt typischerweise einen per-Session (oder pro-Anfrage) CSRF-Token hinzu, der bei zustandsändernden Anfragen mitgesendet werden muss.
Gängige Muster:
Koppeln Sie CSRF-Tokens mit SameSite-Cookies (häufig Lax als Default), und stellen Sie sicher, dass Ihr Session-Cookie HttpOnly und Secure dort ist, wo es sinnvoll ist.
CORS ist kein Auth-Mechanismus; es ist ein Browser-Rechtsystem. Frameworks bieten in der Regel Middleware/Konfig, um vertrauenswürdige Origins Ihren API-Aufrufen zu erlauben.
Fehlkonfigurationen, die Sie vermeiden sollten:
Access-Control-Allow-Origin: * zusammen mit Access-Control-Allow-Credentials: true (Browser lehnen das ab und es signalisiert Verwirrung).Origin-Header widerspiegeln ohne striktes Allowlist.Authorization) oder Methoden zu erlauben — führt zu „funktioniert in curl, aber nicht im Browser".Die meisten Frameworks setzen sichere Defaults oder erleichtern das Hinzufügen von Headern wie:
X-Frame-Options oder Content-Security-Policy: frame-ancestors gegen Clickjacking.Content-Security-Policy für breitere Script-/Resource-Kontrolle.Referrer-Policy und X-Content-Type-Options: nosniff für sicheres Browser-Verhalten.Validierung stellt sicher, dass Daten wohlgeformt sind; Autorisierung stellt sicher, dass der Benutzer die Aktion ausführen darf. Eine gültige Anfrage kann trotzdem verboten sein — Frameworks funktionieren am besten, wenn Sie beides anwenden: validieren Sie Eingaben früh und erzwingen Sie dann Berechtigungen auf der spezifischen Ressource.
Das „richtige" Auth-Muster hängt stark davon ab, wo Ihr Code läuft und wie Anfragen Ihr Backend erreichen. Frameworks unterstützen oft mehrere Optionen, aber Defaults, die in einem App-Typ natürlich wirken, können in einem anderen unhandlich oder riskant sein.
SSR-Frameworks passen meist gut zu cookie-basierten Sessions. Der Browser sendet das Cookie automatisch, der Server schlägt die Session nach und Seiten können mit Benutzer-Kontext gerendert werden, ohne zusätzlichen Client-Code.
Praktische Regel: halten Sie Session-Cookies HttpOnly, Secure und mit sinnvoller SameSite-Einstellung, und verlassen Sie sich auf serverseitige Autorisierungsprüfungen für jede Anfrage, die private Daten rendert.
SPAs rufen oft APIs aus JavaScript auf, wodurch Token-Entscheidungen sichtbarer werden. Viele Teams bevorzugen einen OAuth/OIDC-Flow, der kurzlebige Access-Tokens liefert.
Vermeiden Sie es, langlebige Tokens in localStorage zu speichern, wenn möglich; das erhöht die Blast-Radius von XSS. Eine gängige Alternative ist das Backend-for-Frontend (BFF)-Muster: Die SPA spricht mit Ihrem Server via Session-Cookie, und der Server tauscht/exponiert Tokens für Upstream-APIs.
Mobile Apps können nicht dieselben Browser-Cookie-Regeln nutzen. Sie verwenden typischerweise OAuth/OIDC mit PKCE und speichern Refresh-Tokens im sicheren Speicher der Plattform (Keychain/Keystore).
Planen Sie für „verlorenes Gerät“-Recovery: widerrufen Sie Refresh-Tokens, rotieren Sie Anmeldeinformationen und machen Sie Re-Authentifizierung flüssig — besonders wenn MFA aktiviert ist.
Bei vielen Services wählen Sie zwischen zentraler Identität und service-spezifischer Durchsetzung:
Für Service-zu-Service-Authentifizierung integrieren Frameworks häufig entweder mTLS (starke Kanalidentität) oder OAuth Client Credentials (Service-Accounts). Der Schlüssel ist, den Aufrufer zu authentifizieren und zu autorisieren, was er tun darf.
Admin-„Impersonate user“-Funktionen sind mächtig und gefährlich. Ziehen Sie explizite Impersonation-Sessions vor, verlangen Sie Re-Authentifizierung/MFA für Admins und schreiben Sie immer Audit-Logs (wer wen wann impersoniert hat und welche Aktionen durchgeführt wurden).
Sicherheitsfeatures helfen nur, wenn sie auch bei Code-Änderungen funktionieren. Moderne Frameworks erleichtern Tests für Authentifizierung und Autorisierung, aber Sie brauchen dennoch Tests, die reales Nutzer- und Angreiferverhalten abbilden.
Beginnen Sie damit, zu trennen, was Sie testen:
Die meisten Frameworks liefern Test-Helper, damit Sie nicht jedes Mal Sessions oder Tokens selbst bauen müssen. Gängige Muster:
Praktische Regel: zu jedem „Happy Path"-Test fügen Sie einen „sollte verweigert werden"-Test hinzu, der beweist, dass die Autorisierungsprüfung wirklich greift.
Wenn Sie schnell an diesen Flows iterieren, helfen Tools für Rapid Prototyping plus sicheres Rollback. Zum Beispiel kann Koder.ai (eine vibe-coding Plattform) ein React-Frontend und ein Go + PostgreSQL-Backend aus einer Chat-basierten Spezifikation generieren, dann Snapshots und Rollbacks unterstützen, während Sie Middleware/Guards und Policy-Checks verfeinern — nützlich, wenn Sie mit Session- vs Token-Ansätzen experimentieren und Änderungen auditierbar halten wollen.
Wenn etwas schiefgeht, wollen Sie schnell und verlässlich Antworten.
Loggen und auditieren Sie Schlüsselereignisse:
Fügen Sie leichte Metriken hinzu: Rate von 401/403-Antworten, Spitzen bei fehlgeschlagenen Logins und ungewöhnliche Token-Refresh-Muster.
Behandeln Sie Auth-Bugs als testbares Verhalten: wenn etwas regressieren kann, verdient es einen Test.
Authentifizierung beweist die Identität (wer die Anfrage stellt). Autorisierung entscheidet den Zugriff (was diese Identität darf) unter Verwendung von Kontext wie Route, Ressourcen-Eigentum, Mandant und Scopes.
Frameworks trennen beides, damit Sie Anmeldemethoden ändern können, ohne die Berechtigungslogik neu schreiben zu müssen.
Die meisten Frameworks erzwingen Auth in einer Request-Pipeline, typischerweise mit:
user/principal anhängenEin Identitätsspeicher ist die Quelle der Wahrheit für Benutzer und Zugangsdaten (oder Verknüpfungen zu externen Identitäten). Ein Benutzer-Modell ist die Art und Weise, wie Ihr Code diese Identität repräsentiert.
In der Praxis benötigen Frameworks beides, um die Frage zu beantworten: „gegebenenfalls diesen Bezeichner/Token, wer ist der aktuelle Benutzer?“
Übliche Quellen sind:
Bei Verwendung eines IdP/Verzeichnisses halten viele Apps einen lokalen „Shadow-Benutzer“, um stabile externe IDs (wie OIDC sub) mit app-spezifischen Rollen und Daten zu verknüpfen.
Sessions speichern Identität serverseitig und nutzen ein Cookie als Zeiger (Session-ID). Sie eignen sich gut für SSR und ermöglichen einfache Widerrufe.
Token (JWT/opaque) werden bei jeder Anfrage gesendet (oft via Authorization: Bearer ...) und passen zu APIs, SPAs, Mobil-Apps und Service-zu-Service-Fällen.
Frameworks härten Session-Cookies typischerweise mit:
HttpOnly (reduziert Cookie-Diebstahl via XSS)Secure (nur über HTTPS)SameSite (begrenzt cross-site Versand; beeinflusst CSRF und Login-Flows)Sie sollten die Werte passend zur App wählen (z. B. vs. für Cross-Site-Flows).
Opaque Tokens sind zufällige Strings, die per Server-Lookup validiert werden (einfache Widerrufbarkeit, Inhalte privat).
JWTs sind signiert und enthalten lesbare Claims (z. B. sub, exp, Rollen/Scopes). Sie sind praktisch für verteilte Systeme, aber Widerruf ist schwieriger, sofern Sie nicht kurze Laufzeiten und serverseitige Kontrollen (Deny-Listen, Token-Versionierung) nutzen.
Halten Sie Access-Tokens kurzlebig und verwenden Sie Refresh-Tokens nur zum Erzeugen neuer Access-Tokens.
Typische Endpunkte:
POST /auth/login → access + refreshPOST /auth/refresh → refresh rotieren + neues accessPOST /auth/logout → refresh tokens invalidierenRotation plus Erkennungslogik für Wiederverwendung begrenzt den Schaden, falls ein Refresh-Token leakt.
OAuth 2.0 dient delegiertem API-Zugriff („lass diese App in meinem Namen eine API aufrufen“).
OpenID Connect (OIDC) dient Login/Identität („wer ist der Benutzer?“) und fügt ID-Tokens sowie standardisierte Identitätsclaims hinzu.
„Login mit X“ ist typischerweise OIDC auf Basis von OAuth 2.0.
RBAC (Rollen) ist einfach für grobe Zugangskontrollen (z. B. admin vs member). Berechtigungen/Policies regeln feingranulare Entscheidungen (z. B. nur eigene Dokumente bearbeiten).
Ein gebräuchliches Muster ist:
LaxNone