Als ich das erste Mal in der Keycloak-Dokumentation über die Authorization Services gestolpert bin, habe ich ehrlich gesagt nicht sofort verstanden, was das eigentlich soll.
Ich dachte: „Mit ein paar Claims im Token habe ich doch Autorisierung abgedeckt, oder?“
Doch je länger ich mich mit realen Szenarien beschäftigt habe, desto klarer wurde:
Die eigentliche Autorisierungsentscheidung liegt trotzdem fast immer in der Anwendung selbst.
Versteckte Berechtigungslogik – ein unterschätztes Problem
Viele nutzen Keycloak ausschließlich für die Authentifizierung, also das Login. Und sobald im Access Token ein paar Rollen oder Claims stehen, fühlt es sich so an, als sei auch die Autorisierung „erledigt“.
Aber was passiert danach?
- Der Code prüft z.B. irgendwo:
if role == "admin", oder - nur Benutzer mit bestimmten Rollen dürfen auf bestimmte Endpunkte zugreifen – hartcodiert,
- Die Autorisierungslogik ist tief in der Fachanwendung vergraben.
Diese Logik ist oft nicht sichtbar, nicht zentral steuerbar und kaum auditierbar. Änderungen bedeuten Codeanpassungen, Tests, Deployments – selbst bei einfachen Dingen wie „Rolle X darf nun auch Y“.
Wäre es nicht besser, wenn Keycloak auch diese Entscheidung übernehmen könnte?
Stell dir vor:
- Autorisierungsregeln werden nicht im Code, sondern in Keycloak konfiguriert.
- Über eine grafische Oberfläche.
- Für Entwickler, Architekten und Fachabteilungen verständlich.
- Zentral, nachvollziehbar, transparent.
Genau das ermöglichen die Keycloak Authorization Services.
Was kann man damit abbilden?
Mit den Authorization Services kannst du z. B.:
- Ressourcen definieren (z. B.
/documents/*) - Scopes festlegen (
view,edit,delete) - Policies erstellen (z. B. „nur Admins“, „nur Besitzer“)
- Permissions definieren (Regeln, wann welche Scopes erlaubt sind)
Und das alles über die Keycloak Admin Console, ohne Code – aber über eine REST-API abfragbar.
Beispiel: Entscheidung im Code vs. Entscheidung in Keycloak
Variante A: Entscheidung im Code
import jwt
def is_allowed(token, action):
decoded = jwt.decode(token, "secret", algorithms=["RS256"])
roles = decoded.get("realm_access", {}).get("roles", [])
return "admin" in roles and action == "delete"Die Entscheidung liegt im Code. Niemand sieht diese Regel außerhalb des Entwicklerteams. Änderungen? Müssen getestet und ausgerollt werden.
Variante B: Entscheidung in Keycloak
Die Anwendung fragt Keycloak:
POST /realms/myrealm/authz/entitlement/my-client
Authorization: Bearer <access_token>
Content-Type: application/json
{
"resource": "/documents/123",
"scope": "delete"
}Keycloak prüft, ob der User Zugriff hat – basierend auf den zentral gepflegten Policies.
Beispielantwort:
{
"permissions": [
{
"rsid": "/documents/123",
"scopes": ["delete"]
}
]
}Die App muss keine Entscheidung mehr treffen – sie delegiert an Keycloak.
Wie konfiguriere ich die Autorisierungsentscheidung in Keycloak?
Damit Keycloak darüber entscheiden kann, ob ein Benutzer z. B. das Löschen eines Dokuments (/documents/123) durchführen darf, musst du im Keycloak-Admin-UI drei zentrale Bausteine konfigurieren:
1. Ressource definieren
Zuerst sagst du Keycloak, was eigentlich geschützt werden soll – in unserem Beispiel ein Dokument mit einer bestimmten URI.
Pfad:Clients → [dein Client] → Authorization → Resources → Create
Beispielkonfiguration:
- Name: Delete Documents
- URI:
/documents/* - Scopes:
delete - (optional: Type, Owner, Attributes)
Damit weiß Keycloak: Es gibt eine Ressource unter /documents/*, die bzgl. einer Löschung geschützt wird.
2. Policy erstellen
Jetzt legst du fest, wer überhaupt Zugriff bekommen kann – also die Regeln, nach denen Keycloak später entscheidet.
Pfad:Authorization → Policies → Create
Typ: Role-based
Name: AdminRolePolicy
Konfiguration:
- Realm Roles:
admin - Logic:
POSITIVE - Decision Strategy:
AFFIRMATIVE(Standard)
Das bedeutet: Jeder User, der die Rolle admin besitzt, erfüllt diese Policy.
3. Permission erstellen
Die Permission verbindet nun alles:
Welche Aktion auf welcher Ressource durch welche Policy erlaubt ist.
Pfad:Authorization → Permissions → Create
Typ: Resource-based
Name: Delete Documents
Konfiguration:
- Resource:
delete documents(aus Schritt 1) - Policies: Allow Admins (aus Schritt 2)
Fertig! Du hast jetzt eine vollständige Autorisierungsregel in Keycloak abgebildet.
Wenn deine Anwendung eine Anfrage stellt wie:
{
"resource": "/documents/123",
"scope": "delete"
}…dann prüft Keycloak diese Permission – und erlaubt den Zugriff nur, wenn der Benutzer die Rolle admin hat.
Die echten Vorteile – kurz und klar
- Zentrale Steuerung:
Alle Regeln an einem Ort, statt in jeder App separat. - GUI statt Code
Autorisierung kann über die Keycloak-Oberfläche gepflegt werden – keine Deployments notwendig. - Transparenz & Nachvollziehbarkeit:
Du kannst jederzeit einsehen, wer wann was darf – ideal für Audits. - Feingranulare Regeln:
Nicht nur Rollen, sondern auch Attribute, Zeitfenster, Eigentümerschaften u.v.m. sind möglich. - Weniger Fehler, weniger Aufwand:
Keine doppelte Logik in mehreren Anwendungen. Kein Wildwuchs an Berechtigungen. - Einfachere Wartung:
Rollen oder Policies ändern? Kein Code-Touch. Kein DevOps-Overhead.
Fazit: Von versteckt zu sichtbar – Autorisierung richtig gemacht
Die Keycloak Authorization Services sind mehr als ein Add-on – sie sind ein echter Paradigmenwechsel: Statt dass jede Anwendung selbst entscheidet, was erlaubt ist, wird diese Verantwortung zentralisiert, sichtbar und konfigurierbar. Wenn du also noch Berechtigungen im Code vergraben hast: Es lohnt sich, das Thema neu zu denken.