SSO mit OIDC und OAuth2, Kerberos-Ablösung in der Praxis

Kerberos: Bewährt, aber an seinen Grenzen

Kerberos ist ein robustes Authentifizierungsprotokoll, das in vielen Unternehmen seit Jahrzehnten im Einsatz ist, typischerweise über Active Directory. Im klassischen Intranet-Szenario mit Windows-Clients und On-Premise-Servern funktioniert Kerberos einwandfrei. Single Sign-On über den Desktop-Login, Ticket-basierte Authentifizierung, kein Passwort über das Netzwerk.

Die Probleme beginnen, wenn die Architektur die Grenzen des klassischen Intranets verlässt:

• Microservices: Kerberos-Tickets zwischen dutzenden Services weiterzureichen, ist aufwändig und fehleranfällig
• Mobile Clients: Kerberos auf iOS und Android ist möglich, aber nie komfortabel
• Cloud-Dienste: Kerberos setzt ein Vertrauensverhältnis zum KDC voraus, das in Cloud-Umgebungen schwer herzustellen ist
• API-First-Architekturen: REST APIs mit Token-basierter Authentifizierung sind der Standard, Kerberos ist hier ein Fremdkörper

In einem Infrastrukturprojekt für ein großes Eisenbahnunternehmen standen wir genau vor dieser Situation: Eine gewachsene Kerberos-Infrastruktur, die den Anforderungen einer modernen Service-Landschaft nicht mehr gerecht wurde.

OIDC und OAuth2: Die moderne Alternative

OpenID Connect (OIDC) baut auf OAuth 2.0 auf und trennt sauber zwischen Authentifizierung (wer bin ich?) und Autorisierung (was darf ich?). OAuth2 regelt die Autorisierung durch Access Tokens, OIDC ergänzt die Authentifizierung durch ID Tokens.

Die Token-basierte Architektur bietet entscheidende Vorteile gegenüber Kerberos:

Eigenschaft	Kerberos	OIDC/OAuth2
Protokoll	Binär, proprietär	HTTP/JSON, standardisiert
Token-Format	Opaque Tickets	JWT (inspizierbar, verifizierbar)
Service-zu-Service	Delegation komplex	Bearer Token, einfach weiterzureichen
Mobile/Web	Eingeschränkt	Native Unterstützung
Federation	Umständlich (Cross-Realm)	Standard (Federation, Social Login)
Stateless	Nein (KDC-Abhängigkeit)	Ja (Token-Validierung ohne Backchannel)

Keycloak als Identity Provider

Keycloak hat sich als Open-Source Identity Provider etabliert und war die naheliegende Wahl. Die Gründe:

• Protokollunterstützung: OIDC, OAuth2, SAML, alles in einer Lösung
• User Federation: Bestehende LDAP/AD-Verzeichnisse können direkt angebunden werden, ohne Benutzerdaten zu migrieren
• Realm-Konzept: Verschiedene Anwendungsgruppen können in getrennten Realms verwaltet werden
• Anpassbarkeit: Themes, Custom Authenticators und SPIs (Service Provider Interfaces) ermöglichen tiefgreifende Anpassungen

Die Migration von Kerberos zu Keycloak erfolgte nicht als Big Bang, sondern schrittweise. Keycloak wurde zunächst als zusätzlicher Identity Provider neben der bestehenden Kerberos-Infrastruktur aufgesetzt. Neue Services authentifizierten über OIDC, bestehende Services wurden nach und nach migriert.

Kerberos/AD ← User Federation → Keycloak → OIDC Tokens → Services

Das bedeutet: Die Benutzer authentifizieren sich weiterhin mit ihren AD-Credentials. Keycloak delegiert die Authentifizierung an das bestehende AD, stellt aber OIDC-Tokens aus. Für die Benutzer ändert sich nichts, für die Architektur alles.

Token Flows in der Praxis

Die Wahl des richtigen OAuth2 Flow hängt vom Client-Typ ab:

Authorization Code Flow mit PKCE

Für Web-Anwendungen und mobile Clients ist der Authorization Code Flow mit PKCE (Proof Key for Code Exchange) der empfohlene Standard. PKCE verhindert Authorization Code Interception Attacks und macht einen Client Secret überflüssig, was für mobile Apps und Single Page Applications essenziell ist.

Client Credentials Flow

Für Service-zu-Service-Kommunikation ohne Benutzerkontext. Ein Backend-Service authentifiziert sich mit seiner eigenen Identität, nicht im Namen eines Benutzers.

// Service-zu-Service-Authentifizierung
TokenResponse token = keycloakClient
    .tokenEndpoint()
    .grantType("client_credentials")
    .clientId("billing-service")
    .clientSecret(clientSecret)
    .scope("invoice.read invoice.write")
    .execute();

Token Refresh

Access Tokens haben eine kurze Lebensdauer, typischerweise 5 bis 15 Minuten. Refresh Tokens ermöglichen die Erneuerung ohne erneute Authentifizierung. Die Balance zwischen Sicherheit (kurze Token-Lebensdauer) und Benutzerfreundlichkeit (kein ständiges Einloggen) erfordert sorgfältige Konfiguration.

mTLS für Service-zu-Service-Kommunikation

In KRITIS-Umgebungen reichen Bearer Tokens für die Service-zu-Service-Kommunikation oft nicht aus. Mutual TLS (mTLS) ergänzt die Token-basierte Authentifizierung um eine zertifikatsbasierte Transportschicht-Absicherung. Jeder Service verfügt über ein eigenes Client-Zertifikat und validiert das Zertifikat der Gegenseite.

Die Kombination aus OAuth2 Access Tokens und mTLS bietet zwei unabhängige Sicherheitsebenen:

• mTLS: Stellt sicher, dass die Netzwerkverbindung zwischen den richtigen Services besteht
• OAuth2 Token: Stellt sicher, dass der aufrufende Service die Berechtigung für den angeforderten Scope hat

Lessons Learned

Nach Abschluss der Migration lassen sich einige zentrale Erkenntnisse festhalten:

• Schrittweise Migration ist Pflicht. Eine gleichzeitige Umstellung aller Services ist zu riskant. Die Koexistenz von Kerberos und OIDC muss eingeplant werden.
• Token-Sizing beachten. JWTs können groß werden, besonders wenn viele Claims enthalten sind. Bei HTTP-Headern gibt es Größenbeschränkungen, die in der Praxis relevant werden.
• Keycloak ist mächtig, aber komplex. Die Einarbeitungszeit ist nicht zu unterschätzen. Ein dediziertes Team für den Betrieb und die Konfiguration von Keycloak ist empfehlenswert.
• Monitoring der Token-Infrastruktur. Wenn der Identity Provider ausfällt, funktioniert nichts mehr. Keycloak muss als kritische Infrastruktur behandelt werden, mit Clustering, Health Checks und Failover.
• Session Management bewusst gestalten. Die Frage “Was passiert, wenn ein Benutzer sein Passwort ändert?” klingt trivial, hat aber Implikationen für Token-Revocation und Session-Invalidierung, die durchdacht sein müssen.

Fazit

Die Migration von Kerberos zu OIDC/OAuth2 ist kein reines Technologieprojekt, sondern eine architektonische Transformation. Sie ermöglicht den Übergang zu modernen Service-Architekturen, vereinfacht die Integration mobiler Clients und schafft die Grundlage für Federation und externe Identitätsanbieter. Keycloak als Identity Provider bietet die nötige Flexibilität, erfordert aber eine sorgfältige Planung und den Respekt vor der Komplexität, die ein zentraler Identity Provider mit sich bringt.