1 Jede App ihr eigenes Login = Chaos

Stell dir vor, du betreibst drei Dienste: einen Shop, ein Analytics-Tool und ein Support-Portal. Baut jeder sein eigenes Login, hat jeder seine eigene Nutzer-Datenbank, eigene Passwörter, eigene „Passwort vergessen"-Abläufe.

Das Ergebnis: Passwort-Wildwuchs, kein Überblick, wer eigentlich Zugriff hat — und ein mühsames Offboarding, weil du eine ausscheidende Person in jedem System einzeln deaktivieren musst (und garantiert eins vergisst).

2 Keycloak = ein zentraler Identity-Provider

Keycloak ist ein quelloffenes IAM-System: ein Ort für Anmeldung, Nutzer, Rollen und Tokens. Deine Apps verwalten keine Passwörter mehr selbst — sie delegieren die Anmeldung an Keycloak und bekommen zurück, wer sich angemeldet hat und was er darf.

3 Wofür Keycloak nicht da ist

Keycloak ist ein Baustein, kein Alleskönner — und grenzt sich klar von seinen Nachbarn ab:

1 Die vier großen Vorteile

Ein zentraler Identity-Provider zahlt sich sofort aus:

2 Offene Standards statt Eigenbau

Keycloak spricht OIDC / OAuth2 (das Web-Standardpaar für moderne Apps) und SAML (im Enterprise-Umfeld verbreitet). Damit bindet sich fast jedes Tool an. Auth selbst zu bauen klingt einfach, geht aber fast immer schief:

1 Die fünf Kernbegriffe

2 Ein Realm hält alles zusammen

Ein Realm kapselt eine Umgebung komplett: seine Nutzer, seine Clients, seine Rollen. Zwei Realms wissen nichts voneinander — perfekt, um Kunden oder Prod/Dev sauber zu trennen.

3 Wie es zusammenhängt

Die Begriffe greifen bei jeder Anmeldung ineinander:

1. Ein User öffnet einen Client (eine App) innerhalb eines Realms.
2. Er meldet sich bei Keycloak an — Keycloak prüft Passwort und, falls verlangt, den zweiten Faktor.
3. Keycloak stellt ein Token aus, das die Rollen des Users trägt.
4. Die App liest das Token und weiß: wer das ist und was er darf.

1 Per Docker in einer Minute

Für die ersten Schritte reicht der eingebaute Entwicklungsmodus. Ein einziger Befehl holt das Image und startet Keycloak auf Port 8080:

docker run --name keycloak -p 8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=<dein-admin-passwort> \
  quay.io/keycloak/keycloak:26.7 start-dev

2 Admin-Console öffnen

Ist der Container hochgefahren, öffnest du im Browser http://localhost:8080/ → Administration Console und meldest dich mit admin und deinem Passwort an.

3 Ersten Realm anlegen

Den master-Realm lässt du in Ruhe — für deine Apps legst du einen eigenen an. Wir nennen ihn durchgängig nordwerk (ein fiktives Demo-Projekt):

1. Oben links auf den Realm-Umschalter klicken → Create realm.
2. Als Realm name nordwerk eintragen → Create.
3. Fertig — der Umschalter zeigt jetzt nordwerk als aktiven Realm. Alles, was du ab hier anlegst (Clients, Nutzer, Rollen), lebt in diesem Realm.

1 Einen Client anlegen

Jede App, die sich über Keycloak anmelden soll, ist ein Client. Im Realm nordwerk legst du für unsere Demo-App einen an:

1. Clients → Create client. Client type: OpenID Connect. Client-ID: nordwerk-app.
2. Capability config: Standard flow aktiviert (das ist der Authorization-Code-Flow). Für serverseitige Apps zusätzlich Client authentication an → es entsteht ein Client-Secret.
3. Login settings → Valid redirect URIs: https://app.nordwerk.example/oauth2/callback eintragen — nur an diese URL schickt Keycloak den User zurück.
4. Speichern, dann unter Credentials das Client-Secret kopieren (Platzhalter: <client-secret>) — die App braucht es für den Token-Tausch.

2 Der Login-Flow (Authorization Code)

Was beim Klick auf „Anmelden" wirklich passiert — der Nutzer tippt sein Passwort nur bei Keycloak ein, nie bei der App:

3 Apps ohne eigenes OIDC: oauth2-proxy

Dienste mit nativem OIDC (Grafana, GitLab, …) binden direkt an — Client anlegen, Werte eintragen, fertig. Ein Dienst ohne eigenes OIDC bekommt einen kleinen Türsteher davor: oauth2-proxy übernimmt die Anmeldung und lässt nur eingeloggte Nutzer durch.

oauth2-proxy \
  --provider=oidc \
  --oidc-issuer-url=https://auth.nordwerk.example/realms/nordwerk \
  --client-id=nordwerk-app \
  --client-secret=<client-secret> \
  --upstream=http://localhost:3000 \
  --redirect-url=https://app.nordwerk.example/oauth2/callback

1 Nutzer, Gruppen, Rollen

Im Realm nordwerk baust du deine Rechtestruktur — am besten über Gruppen, damit du Rollen nicht an jede Person einzeln hängen musst:

1. Users → Add user: Person anlegen (E-Mail, Name), dann unter Credentials ein erstes Passwort setzen (gern als „temporär", damit es beim ersten Login gewechselt wird).
2. Realm roles → Create role: Rollen definieren, z. B. admin und mitarbeiter.
3. Groups → Create group: Gruppen wie Team-Nordwerk anlegen und der Gruppe die passenden Rollen zuweisen.
4. Nutzer in Gruppen stecken — die Rollen erben sie automatisch. Neue Person? Einfach in die richtige Gruppe.

2 MFA erzwingen

Die zweite Sicherheitsstufe (Multi-Faktor) richtest du zentral ein — sie gilt dann für alle angebundenen Apps auf einmal:

1. Authentication → Required actions: Configure OTP als Default aktivieren — jeder Nutzer muss beim nächsten Login einen zweiten Faktor einrichten.
2. Die Person scannt beim Login einen QR-Code mit einer Authenticator-App (TOTP) und gibt ab dann zusätzlich den 6-stelligen Code ein.
3. Alternativ per Policy für bestehende Nutzer nachziehen — so wird MFA für alle verpflichtend.

3 Passwort-Policies & Login-Theme

1 AuxData meldet dich über Keycloak an

Die AuxData-Plattform nutzt Keycloak als Identity-Provider: Die Anmeldeseite, die du bei AuxData siehst, wird von Keycloak bereitgestellt. Es kümmert sich um die Authentifizierung, die Passwortregeln, MFA und SSO — genau die Rolle, die du in dieser Schulung kennengelernt hast.

2 MFA-Pflicht & SSO mit Microsoft

3 API per Bearer-Token

Nicht nur die Weboberfläche, auch die REST-API von AuxData wird über Keycloak abgesichert: Anfragen tragen ein JWT-Bearer-Token, das aus dem Login stammt — dasselbe Token-Prinzip aus Stufe 3.

GET /api/v1/... HTTP/1.1
Host: auxdata.example
Authorization: Bearer <token>

Beispiel gemäß AuxData-Benutzer- und Administratorhandbuch.

1 Raus aus dem Dev-Mode

Der Start aus Stufe 4 war start-dev — für die Produktion nimmst du start und gibst Keycloak eine eigene Datenbank (z. B. Postgres), damit deine Realms und Nutzer dauerhaft sicher liegen:

docker run --name keycloak -p 8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=<dein-admin-passwort> \
  -e KC_DB=postgres \
  -e KC_DB_URL=jdbc:postgresql://db:5432/keycloak \
  -e KC_DB_USERNAME=keycloak \
  -e KC_DB_PASSWORD=<db-passwort> \
  quay.io/keycloak/keycloak:26.7 start

2 HTTPS, Backups, Updates

1. HTTPS über einen Reverse Proxy: Keycloak hinter einen Proxy stellen, KC_HOSTNAME auf deine Domain setzen und mit --proxy-headers xforwarded starten. Keycloak nie nur über HTTP öffentlich erreichbar machen — Einrichtung siehe Self-Hosting & VPS.
2. Backups: die Datenbank regelmäßig sichern und die Realms als Datei exportieren (nächster Block).
3. Updates: vor Major-Upgrades die Changelogs lesen — Env-Variablen und Optionen brechen zwischen Major-Versionen gelegentlich.

# Realm „nordwerk" als JSON sichern
docker exec -it keycloak /opt/keycloak/bin/kc.sh export \
  --dir /tmp/export --realm nordwerk

3 Sicherheits-Basics + Ausblick