Security Deep Dive: OAuth2, OIDC, JWT & Policies
Identity Provider, Claims, Rollen, Objektberechtigung, Service-to-Service, Secrets und Audit.
Version 3SecurityCodeDiagramm
In dieser Datei
Security beginnt bei Identität
Authentifizierung klärt, wer aufruft. Autorisierung klärt, was dieser Aufrufer im konkreten Kontext darf. Enterprise-Systeme brauchen häufig Objekt-, Mandanten- und Prozessberechtigungen.
JWT ist kein Sicherheitszauber
Token müssen auf Signatur, Ablaufzeit, Audience, Issuer und Scopes geprüft werden. Claims sollten stabil, minimal und fachlich sinnvoll sein.
Service-to-Service getrennt betrachten
Maschinenidentität ist nicht Nutzeridentität. Interne Kommunikation braucht Client Credentials, mTLS, Netzwerkregeln oder Plattformmechanismen.
Entscheidungen
| Entscheidung | Gute Praxis | Prüffrage |
|---|---|---|
| Fachliche Grenze | Zuerst Use Case, Invariante und Verantwortlichkeit klären. | Welche Geschäftsentscheidung wird geschützt? |
| Technische Grenze | Framework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln. | Kann die Domain ohne Framework getestet werden? |
| Betrieb | Timeouts, Logs, Metriken, Traces, Security und Rollback definieren. | Wie erkennt der Betrieb Fehler rechtzeitig? |
Ausführliche Beispiele
Method Security mit Objektprüfung
@PreAuthorize("hasAuthority('ORDER_APPROVE') and @orderSecurity.canAccess(#id)")
public void approve(OrderId id) {
approveOrderUseCase.approve(id);
}
JWT Claims bewusst lesen
public CurrentUser currentUser(Jwt jwt) {
return new CurrentUser(
jwt.getSubject(),
jwt.getClaimAsStringList("groups"),
jwt.getAudience()
);
}
Typische Stolperfallen
| Stolperfalle | Warum gefährlich |
|---|---|
| Rolle ersetzt Fachrecht | Ein Nutzer mit Rolle darf nicht jedes Objekt sehen. |
| Secrets im Image | Rotation wird schwierig und Sicherheitsrisiko steigt. |
| Token zu groß | Jede Anfrage transportiert unnötige Daten. |