OAuth2/OIDC zentral oder lokale Sessions?
OIDC zentralisiert Login und Vertrauensregeln. Lokale Sessions können bei kleinen, abgeschlossenen Anwendungen einfacher und risikoärmer sein.
Login und Trust Boundaries
Stell dir den Login wie den Eingang zu einem gesicherten Büro vor. Der Benutzer weist sich zuerst beim Identity Provider aus. Danach erhält er ein Token, das an den API Gateway und später an den zuständigen Service weitergegeben wird. Jeder Übergang ist eine Trust Boundary: An jeder Grenze muss erneut geprüft werden, ob Absender, Ziel, Gültigkeit und Berechtigung stimmen.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- Benutzer öffnet Login
- Identity Provider prüft Identität
- Token wird ausgestellt
- API Gateway validiert Token
- Service prüft fachliche Berechtigung
- Anfrage wird verarbeitet.
Fachlicher Ablauf
Eine Person meldet sich an, damit CommerceOne ihre Identität prüfen und die erlaubten Funktionen freigeben kann. Fachlich geht es nicht nur um ein erfolgreiches Login, sondern darum, wer handeln darf, in welcher Rolle und mit welchem nachvollziehbaren Zweck.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Der Benutzer erhält genau den erlaubten Zugriff, ohne dass Passwortdaten durch alle Services wandern.
Technischer Ablauf
Der Client leitet die Anmeldung zum Identity Provider weiter. Nach erfolgreicher Authentication werden Tokens ausgestellt. Gateway und Resource Server prüfen Signatur, Issuer, Audience, Ablaufzeit und Scopes; die Anwendung entscheidet anschließend über die fachliche Authorization.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Tokenvalidierung, Authorization-Entscheidung, Audit-Log und Fehlerantworten ohne sensible Details.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
Ausgangslage
Kunden, Mitarbeitende und technische Clients benötigen unterschiedliche Identitäten und Rechte.
Die Entscheidung wird nicht nach Mode, sondern nach Qualitätszielen, Teamfähigkeit, Betriebsmodell und Fault Tolerance getroffen.
Welche Frage wird wirklich entschieden?
Nicht „Welche Technologie ist moderner?“, sondern: Welche Option erfüllt die geschäftlichen Anforderungen mit der geringsten dauerhaft beherrschbaren Komplexität?
- Welche Benutzerwirkung muss geschützt werden?
- Welche Änderungen erfolgen wie häufig?
- Wer betreibt und verantwortet die Lösung?
- Welche Fehler müssen toleriert werden?
Option A: Zentraler Identity Provider
Stärken: Gute Passung für den beschriebenen CommerceOne-Kontext, wenn Voraussetzungen und Betriebsfähigkeit vorhanden sind.
Nachteile: Zusätzliche Technik erzeugt Lern-, Betriebs-, Sicherheits- und Upgrade-Aufwand.
Option B: Lokale Session- und Benutzerverwaltung
Stärken: Häufig einfacher, schneller verständlich und mit weniger Betriebsfläche.
Nachteile: Kann bei Wachstum, mehreren Teams oder höheren Verfügbarkeitszielen Grenzen erreichen.
Bewertungskriterien
CommerceOne-Entscheidung
Empfehlung: Zentraler Identity Provider – aber nur unter den dokumentierten Voraussetzungen. Die Alternative Lokale Session- und Benutzerverwaltung bleibt bevorzugt, wenn Organisation oder Lastbild einfacher sind.
Die Entscheidung wird als ADR festgehalten und nach sechs Monaten anhand realer Betriebsdaten überprüft.
Wann ausdrücklich nicht?
- Wenn das Team die Betriebsfolgen nicht verantworten kann.
- Wenn die Anforderungen auch mit einer wesentlich einfacheren Lösung erfüllt werden.
- Wenn die Entscheidung nur durch Trend, Anbieterfolie oder Lebenslaufoptimierung begründet wird.
Security, Performance und Betrieb
Security: Neue Komponenten erweitern Trust Boundaries (Trust Boundaries), Rechte und Patch-Flächen.
Performance: Latenz und Durchsatz müssen am End-to-End-Ablauf gemessen werden.
Betrieb: Für jede Option braucht CommerceOne Ownership, Telemetrie, Runbook, Backup- und Upgrade-Plan.
Kosten und organisatorische Folgen
Kosten bestehen nicht nur aus Infrastruktur. Entscheidend sind Bereitschaft, Schulung, Störungen, Security Reviews, Versionspflege und verlorene Entwicklungszeit. Die einfachere Option gewinnt, solange der zusätzliche Nutzen der komplexeren Option diese dauerhaften Kosten nicht übersteigt.
Entscheidungsfragen
- Welche Annahme könnte die Empfehlung kippen?
- Welche Kennzahl zeigt nach dem Einsatz, ob die Entscheidung erfolgreich war?
- Welche Exit-Strategie besteht, falls sich Zentraler Identity Provider nicht bewährt?
Merksatz
Die beste Enterprise-Entscheidung ist nicht die technisch mächtigste, sondern die dauerhaft verständliche und betreibbare Lösung für das konkrete Problem.