open-how2 – Entdecke. Verstehe. Nutze.
Veröffentlicht am
• How2-Tipps

Keycloak für Microservices – Authentifizierung in modernen Architekturen

Autor
Keycloak für Microservices – Authentifizierung in modernen Architekturen

Microservices sind das Rückgrat moderner Software-Architekturen: kleine, unabhängige Dienste, die jeweils einen klar abgegrenzten Zweck erfüllen. Doch je mehr Services entstehen, desto schwieriger wird eine einheitliche Authentifizierung und Autorisierung.

Hier kommt Keycloak ins Spiel – eine Open-Source-Lösung, die als zentrales Authentifizierungs- und Identitätsmanagementsystem für Microservices fungiert. In diesem Artikel zeigen wir, wie Keycloak in serviceorientierten Architekturen eingesetzt wird und warum es für DevOps, Entwickler und Unternehmen unverzichtbar ist.

Warum Authentifizierung bei Microservices komplex ist

In klassischen Monolithen übernimmt das Hauptsystem das Benutzer-Login und verwaltet Sitzungen. Bei Microservices dagegen gilt:

  • Jeder Service läuft autonom
  • Jeder Service kommuniziert über APIs
  • Jeder Service muss wissen, wer die Anfrage stellt

Ohne ein zentrales Auth-System müsste jeder Microservice selbst Benutzer prüfen und Rechte validieren – ein Albtraum für Sicherheit, Wartung und Skalierung.

Lösung: Trennung von Authentifizierung (Identität) und Anwendung (Funktion). Genau das macht Keycloak perfekt.

Keycloak als zentrales Auth-Backend

Keycloak agiert als Identity Provider (IdP) und nutzt offene Standards wie:

  • OpenID Connect (OIDC) für Authentifizierung
  • OAuth 2.0 für Autorisierung
  • SAML 2.0 für Legacy-Integration

Anwendungen und Microservices verlassen sich dabei auf Access Tokens, die Keycloak ausstellt. Diese Tokens enthalten alle nötigen Informationen, um zu prüfen, ob eine Anfrage legitim ist – ohne dass jeder Service eigene Benutzerverwaltung betreibt.

Wie es funktioniert – der typische Ablauf

  1. Benutzer meldet sich bei Keycloak an über Login-Seite oder via OIDC-Redirect.

  2. Keycloak erstellt Tokens

  • Access Token: Berechtigung für bestimmte APIs
  • ID Token: Informationen über den Benutzer
  • Refresh Token: für Session-Verlängerung

  1. Client (z. B. API Gateway) sendet Token an Microservice → jeder Microservice validiert das Token über Keycloak.

  2. Microservices vertrauen Keycloak Sie prüfen nur die Signatur und Claims im Token – keine eigene Passwortlogik mehr nötig.

Vorteile der Keycloak-Integration in Microservice-Umgebungen

Vorteil Beschreibung
🔒 Sicherheit Zentrale Authentifizierung über geprüfte Protokolle (OAuth2, OIDC).
⚙️ Skalierbarkeit Keycloak kann horizontal skaliert werden, um viele gleichzeitige Logins zu verarbeiten.
🧩 Entkopplung Microservices bleiben leichtgewichtig und unabhängig von Auth-Logik.
🚀 Single Sign-On (SSO) Benutzer melden sich einmal an und greifen auf alle Services zu.
🧭 Feingranulare Kontrolle Rollen, Scopes und Policies lassen sich pro Service steuern.
🔁 Zentrale Verwaltung Benutzer, Gruppen und Rechte werden zentral gepflegt.

Typische Architektur mit Keycloak

[ Benutzer ] 
     ↓
[ Keycloak ]
     ↓ (Access Token)
[ API Gateway ] → verteilt Tokens an
 ├── [ Service A ]
 ├── [ Service B ]
 └── [ Service C ]

Das API Gateway (z. B. Kong, Traefik oder NGINX) ist meist die erste Verteidigungslinie und prüft Tokens, bevor Anfragen an die Microservices weitergeleitet werden.

Microservices selbst nutzen dann JWT-Verifikation, um Claims auszuwerten (z. B. Benutzerrolle oder Tenant-ID).

Beispiel: Authentifizierung über OpenID Connect

Ein Microservice empfängt eine Anfrage mit einem JWT (Access Token). Das Token wird lokal geprüft, z. B. in Python oder Node.js:

Beispiel (Python / Flask):

from flask import request
import jwt
from jwt import InvalidTokenError

def verify_token():
    token = request.headers.get('Authorization').split()[1]
    try:
        decoded = jwt.decode(token, PUBLIC_KEY, algorithms=['RS256'], audience='account')
        return decoded
    except InvalidTokenError:
        return {"error": "invalid token"}, 401

PUBLIC_KEY stammt aus dem Keycloak Realm: https://keycloak.example.de/realms/organisation/protocol/openid-connect/certs

Keycloak + Kubernetes + Microservices

In Kubernetes-Umgebungen kann Keycloak direkt im Cluster laufen:

  • Bereitstellung via Helm-Chart
  • Service-Kommunikation über Ingress oder Service Mesh (z. B. Istio)
  • Zentrale Authentifizierung auf Cluster-Ebene

Mit Istio lässt sich Auth sogar deklarativ konfigurieren:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: keycloak-jwt
spec:
  jwtRules:
  - issuer: "https://keycloak.example.de/realms/organisation"
    jwksUri: "https://keycloak.example.de/realms/organisation/protocol/openid-connect/certs"

Damit prüft Istio automatisch jedes eingehende JWT-Token – ganz ohne Anpassung am Code der Microservices.

Erweiterungen & Automation

Keycloak kann in Microservice-Umgebungen dynamisch erweitert werden:

  • Automatische Benutzeranlage via REST-API
  • Client-Provisioning für neue Services
  • Rollenbasiertes Routing im API Gateway
  • Zentrales Logging & Auditing

So entsteht ein skalierbares, sicheres und zentral kontrolliertes Authentifizierungs-Ökosystem.

Keycloak ist die Schaltzentrale für Identitäten in Microservice-Architekturen. Es bietet standardisierte Authentifizierung, zentralisierte Verwaltung und volle Flexibilität für Cloud-native Anwendungen.

Wer moderne Systeme aufbauen möchte – ob mit Docker, Kubernetes oder Serverless – bekommt mit Keycloak ein starkes, offenes und souveränes Auth-Backend an die Hand.

Ähnliche Beiträge