Security Deep Dive: OAuth2, OIDC, JWT & Policies

Identity Provider, Claims, Rollen, Objektberechtigung, Service-to-Service, Secrets und Audit.

Version 3SecurityCodeDiagramm
Diagramm Security Deep Dive: OAuth2, OIDC, JWT & Policies
Fachlich-technische Darstellung zu Security Deep Dive: OAuth2, OIDC, JWT & Policies.

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

EntscheidungGute PraxisPrüffrage
Fachliche GrenzeZuerst Use Case, Invariante und Verantwortlichkeit klären.Welche Geschäftsentscheidung wird geschützt?
Technische GrenzeFramework-/Library-Code hinter Port, Adapter oder Konfiguration kapseln.Kann die Domain ohne Framework getestet werden?
BetriebTimeouts, 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

StolperfalleWarum gefährlich
Rolle ersetzt FachrechtEin Nutzer mit Rolle darf nicht jedes Objekt sehen.
Secrets im ImageRotation wird schwierig und Sicherheitsrisiko steigt.
Token zu großJede Anfrage transportiert unnötige Daten.
⌂ Cockpit