Auth-Service mit JWT, Refresh-Token-Rotation und Rollenrechten für mehrere eigene Anwendungen.
Interner Dienst — er hängt hinter den Anwendungen, die ihn nutzen, und hat keine eigene Oberfläche.
Snapshot
Alleinentwickler
category
status
stack
features
Mehrere eigene Anwendungen brauchten dieselbe Authentifizierung und Rollenlogik.
Auth-Service mit JWT- und Refresh-Token-Flow, rollenbasierten Rechten und Prisma-Datenmodell auf PostgreSQL.
Refresh-Token-Rotation und Sitzungsablauf machen bei Auth die eigentliche Arbeit, nicht der Login selbst.
Zentraler Auth-Service für mehrere eigene Anwendungen: JWT mit Refresh-Token-Rotation, rollenbasierte Rechte und definierter Sitzungsablauf. Datenmodell und Migrationen über Prisma auf PostgreSQL, dazu einheitliches Logging und Fehlerbehandlung.
Ein Dienst, mehrere Anwendungen. Statt in jeder Anwendung erneut Login, Rollen und Sitzungslogik zu bauen, gibt es eine Stelle, die Token ausstellt und prüft — die Anwendungen selbst kennen nur noch das Token.
Der Ablauf trennt zwei Token mit unterschiedlicher Lebensdauer: ein kurzlebiges Zugriffstoken, das die Anwendungen ohne Rückfrage prüfen können, und ein langlebiges Erneuerungstoken, das ausschließlich gegen den Auth-Dienst eingetauscht wird. Bei jedem Eintausch wird das alte Erneuerungstoken ungültig und ein neues ausgegeben — Rotation statt Dauergültigkeit.
Datenmodell und Schemaverlauf liegen in Prisma auf PostgreSQL: Konten, Rollen, Sitzungen und ausgegebene Erneuerungstoken. Logging und Fehlerformat sind einheitlich, damit ein Fehlerbild in allen angebundenen Anwendungen gleich aussieht.
Anmeldung und Ausstellung von Zugriffs- und Erneuerungstoken; Zugriffstoken sind kurzlebig und ohne Rückfrage prüfbar.
Jeder Eintausch entwertet das alte Erneuerungstoken und gibt ein neues aus. Ein zweiter Eintausch desselben Tokens ist damit ein erkennbarer Vorfall.
Rollenbasierte Rechte zentral gepflegt, von den angebundenen Anwendungen nur ausgelesen.
Definierter Ablauf und die Möglichkeit, eine Sitzung serverseitig zu beenden — auch bevor das Zugriffstoken abläuft.
Einheitliches Logging und ein gemeinsames Fehlerformat über alle Endpunkte.
Ein Login gegen eine Passwort-Hash-Tabelle ist an einem Nachmittag gebaut. Die Arbeit steckt danach: Wie lange gilt ein Token, wie wird es erneuert, was passiert, wenn ein Erneuerungstoken abhandenkommt, und wie beendet man eine Sitzung, bevor das Zugriffstoken abgelaufen ist.
Zwei Token mit getrennter Lebensdauer, Rotation bei jedem Eintausch und Sitzungen als eigener Datensatz. Erst damit ist ein serverseitiger Rausschmiss überhaupt möglich — ein reines JWT allein lässt sich nicht zurücknehmen.
Solange jede Anwendung ihre eigenen Rollen führt, laufen die Stände auseinander: Eine Rechteänderung wirkt in der einen Anwendung und in der anderen nicht — und niemand merkt es, bis jemand etwas sieht, das er nicht sehen sollte.
Rollen und Rechte liegen im Auth-Dienst und werden den Anwendungen im Token mitgegeben. Geändert wird an einer Stelle; die Anwendungen lesen nur.
Kurzlebige Zugriffstoken sind sicherer, erzwingen aber häufiges Erneuern. Macht man sie lang, bleibt ein gestohlenes Token lange brauchbar.
Kurze Zugriffstoken plus stiller Erneuerung im Hintergrund. Der Nutzer merkt nichts, das Zeitfenster für ein abhandengekommenes Zugriffstoken bleibt klein, und der Missbrauch eines Erneuerungstokens fällt über die Rotation auf.
JavaScript-Runtime auf V8 für serverseitige Anwendungen.
runtimeTypsicheres Superset von JavaScript.
languageObjekt-relationale Open-Source-Datenbank mit JSONB, FTS und reicher Erweiterbarkeit.
databaseProjektabhängigkeit
Projektabhängigkeit
Projektabhängigkeit