Verwende dein DTZ-Konto, um jeden Dienst zu schützen

Down-to-Zero hat stets versucht, dir auf der Plattform eine Identität für alles zu geben. Bearer-Tokens, API-Keys, die Container-Registry, der MCP-Server — sie alle werden gegen denselben DTZ Identity-Service validiert. Aber derselbe Identity-Service ist auch ein vollständig standardkonformer OpenID Connect (OIDC) Anbieter, und das bedeutet, dass du ihn verwenden kannst, um alles zu schützen, das OIDC spricht — nicht nur DTZ-Dienste.

Wenn du bereits ein DTZ-Konto und einen Kontext hast, hältst du bereits die Schlüssel. Kein neuer IdP zum Aufsetzen, kein zusätzliches Abonnement, keine Passwortdatenbank zu pflegen.

Die Erkenntnis: dein Kontext IST der OAuth-Client

Die meisten OIDC-Setups erfordern, dass du beim Identity-Provider eine „Application“ registrierst und ein client_id / client_secret Paar zurückbekommst. DTZ hält das flach: deine Kontext-ID dient als beides. Der Kontext, den du bereits für deine Workloads erstellt hast, ist der OAuth-Client. Setze client_id und client_secret auf dieselbe Kontext-ID und die Registrierung ist erledigt.

Auto-Discovery erledigt den Rest

OIDC definiert ein standardisiertes Discovery-Dokument, das Bibliotheken abrufen können, um alle Endpunkt-URLs, Signierschlüssel und unterstützten Scopes zu ermitteln. DTZ veröffentlicht eines unter:

https://identity.dtz.rocks/.well-known/openid-configuration

Jede vernünftige OIDC-Bibliothek — Pythons authlib, Gos coreos/go-oidc, Nodes openid-client und unzählige andere — parst dieses Dokument und konfiguriert sich selbst. Du musst die Token- oder Userinfo-Endpunkte nie hardcoden.

Ein echtes Beispiel

Hier ist der Umgebungsblock von einem kleinen internen Dashboard, das ich kürzlich eingebunden habe:

export OIDC_ISSUER=https://identity.dtz.rocks
export OIDC_CLIENT_ID={YOUR_CONTENT_ID}
export OIDC_CLIENT_SECRET={YOUR_CONTENT_ID}
export OIDC_REDIRECT_URI=http://localhost:3000/login
export OIDC_ALLOWED_CLAIM=iss
export OIDC_ALLOWED_VALUES="dtz.rocks"

Einige Punkte, die erwähnenswert sind:

• OIDC_CLIENT_ID == OIDC_CLIENT_SECRET — beides ist einfach die Kontext-ID. Kein Tippfehler.
• OIDC_ISSUER zeigt auf die Discovery-Root. Die Bibliothek holt von dort /.well-known/openid-configuration und konfiguriert sich automatisch.
• OIDC_ALLOWED_CLAIM / OIDC_ALLOWED_VALUES — nach dem Token-Austausch prüft die App, dass der iss-Claim im zurückgegebenen ID-Token gleich dtz.rocks ist. Diese einzelne Prüfung stellt sicher, dass nur Benutzer, die sich über DTZ authentifiziert haben, Zugang erhalten. Du könntest das weiter einschränken, indem du contexts- oder roles-Claims prüfst, wenn du auf einen bestimmten DTZ-Kontext begrenzen willst.

Der Dienst holte das Discovery-Dokument beim Start, leitete die Authorize- und Token-Endpunkte ab und funktionierte einfach. Gesamte Integrationszeit: etwa zwanzig Minuten, die meiste Zeit fürs Lesen der Bibliotheksdokumentation.

Wie der Login-Fluss aussieht

1. Ein nicht authentifizierter Benutzer trifft auf eine geschützte Route.
2. Deine App leitet zum DTZ-Authorize-Endpunkt weiter (automatisch entdeckt).
3. DTZ zeigt die Standard-Login-Seite. Wenn der Benutzer bereits eingeloggt ist, geht das sofort.
4. DTZ leitet mit einem Authorization-Code zurück.
5. Deine App tauscht den Code am Token-Endpunkt gegen Tokens ein.
6. Deine App validiert den iss-Claim (oder jeden anderen Claim, der dir wichtig ist) und gewährt Zugriff.

Aus Sicht des Benutzers ist es ein Single-Sign-On-Erlebnis: ihre DTZ-Zugangsdaten entsperren das Dashboard, das interne Tool, die selbstgehostete App — was auch immer du schützen möchtest.

Warum das für kleine Teams wichtig ist

Einen eigenen Identity-Provider zu betreiben ist teuer — an Zeit, an Infrastruktur und im Risiko, Sicherheitsfehler zu machen. DTZ Identity existiert bereits, übernimmt die schweren Aufgaben (Passworthashing, Token-Signierung, Schlüsselrotation) und kostet nichts extra. Dein nächstes Side-Project auf https://identity.dtz.rocks zeigen statt Keycloak oder Auth0 aufzusetzen hält den Footprint klein und die Wartungsaufwand nahe null.

Das ist die ganze DTZ-Philosophie angewandt auf Authentifizierung: weniger tun, das nutzen, was bereits da ist.

Weniger Infrastruktur, gleiche Sicherheit — einfach auf den OIDC-Issuer zeigen und loslegen.