Der Browser wird zum Authorization Server umgeleitet. Mit PKCE bindet der Client den späteren Token-Austausch an den ursprünglichen Login-Vorgang.
CommerceOne Architekturgeschichte
Was passiert beim Login?
Vom Browser über OIDC und Keycloak bis zur fachlichen Autorisierung im Service.
0 % geöffnet
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.
1. Anwendung startet Authorization Code Flow
2. Benutzer authentifiziert sich
Keycloak prüft Zugangsdaten und optional einen zweiten Faktor. Die Anwendung sieht das Passwort nicht.
3. Code wird gegen Tokens getauscht
Der Client tauscht den kurzlebigen Code über einen geschützten Kanal gegen Tokens. Das ID Token beschreibt die Anmeldung; das Access Token autorisiert API-Zugriffe.
4. Gateway validiert das Access Token
Signatur, Issuer, Audience und Ablaufzeit werden geprüft. Nur ein formal gültiges Token darf weitergereicht werden.
5. Service prüft fachliche Rechte
Der Order Service prüft Rollen, Scopes und Eigentumsregeln. Technische Rollen ersetzen keine fachliche Entscheidung.
6. Session und Logout werden beherrscht
Kurze Access-Token-Laufzeiten reduzieren das Risiko. Refresh Token Rotation und zentraler Logout begrenzen Missbrauch.
Architekturentscheidung
OIDC liefert Login-Kontext, OAuth2 delegierte Autorisierung. CommerceOne trennt beides und prüft fachliche Berechtigungen im zuständigen Service.
Lernkontrolle
Warum darf ein gültig signiertes JWT trotzdem nicht automatisch akzeptiert werden?
Antwort selbst formulieren
Weiterlernen
Öffne markierte Fachbegriffe direkt im Text oder untersuche ihre Beziehungen im Knowledge Graph.