Use Your DTZ Account to Protect Any Service

created: jeudi, mars 19, 2026

Down-to-Zero a toujours cherché à vous donner une identité unique pour tout sur la plateforme. Les jetons Bearer, les clés API, le registre de conteneurs, le serveur MCP — ils valident tous auprès du même service DTZ Identity. Mais ce même service d’identité est aussi un fournisseur OpenID Connect (OIDC) entièrement conforme aux standards, ce qui signifie que vous pouvez l’utiliser pour protéger n’importe quoi qui parle OIDC, pas seulement les services DTZ.

Image OIDC générique

Si vous avez déjà un compte DTZ et un contexte, vous détenez déjà les clés. Pas besoin de mettre en place un nouvel IdP, pas d’abonnement supplémentaire, pas de base de mots de passe à maintenir.

L’idée : votre contexte EST le client OAuth

La plupart des configurations OIDC exigent d’enregistrer une « application » auprès du fournisseur d’identité et de récupérer une paire client_id / client_secret. DTZ simplifie cela : l’ID de votre contexte sert pour les deux. Le contexte que vous avez déjà créé pour vos workloads est le client OAuth. Affectez client_id et client_secret au même ID de contexte et vous avez fini l’enregistrement.

L’auto-découverte fait le reste

OIDC définit un document de découverte standard que les bibliothèques peuvent récupérer pour connaître toutes les URLs des endpoints, les clés de signature et les scopes supportés. DTZ en publie un à :

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

Toute bibliothèque OIDC correcte — le authlib de Python, coreos/go-oidc pour Go, openid-client pour Node, et bien d’autres — analysera ce document et se configurera automatiquement. Vous n’aurez jamais à coder en dur les endpoints token ou userinfo.

Un exemple réel

Voici le bloc d’environnement d’un petit tableau de bord interne que j’ai raccordé récemment :

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"

Quelques points à souligner :

OIDC_CLIENT_ID == OIDC_CLIENT_SECRET — les deux correspondent simplement à l’ID du contexte. Ce n’est pas une erreur.
OIDC_ISSUER pointe vers la racine de découverte. La bibliothèque récupère /.well-known/openid-configuration depuis cet emplacement et se configure automatiquement.
OIDC_ALLOWED_CLAIM / OIDC_ALLOWED_VALUES — après l’échange de token, l’application vérifie que la revendication iss dans le token ID retourné est égale à dtz.rocks. Cette seule vérification garantit que seuls les utilisateurs authentifiés via DTZ peuvent accéder. Vous pouvez restreindre encore plus en vérifiant les revendications contexts ou roles si vous voulez limiter à un contexte DTZ spécifique.

Le service a récupéré le document de découverte au démarrage, en a déduit les endpoints authorize et token, et a fonctionné immédiatement. Temps total d’intégration : environ vingt minutes, la majeure partie ayant été consacrée à la lecture de la documentation de la bibliothèque.

À quoi ressemble le flux de connexion

L’utilisateur non authentifié atteint une route protégée.
Votre appli redirige vers l’endpoint authorize de DTZ (découvert automatiquement).
DTZ affiche la page de connexion standard. Si l’utilisateur est déjà connecté, c’est instantané.
DTZ redirige en retour avec un code d’autorisation.
Votre appli échange le code contre des tokens au niveau de l’endpoint token.
Votre appli valide la revendication iss (ou toute autre revendication qui vous importe) et accorde l’accès.

Du point de vue de l’utilisateur, c’est une expérience de single sign-on : leurs identifiants DTZ débloquent le tableau de bord, l’outil interne, l’application auto-hébergée — tout ce que vous choisissez de protéger.

Pourquoi c’est important pour les petites équipes

Gérer son propre fournisseur d’identité coûte cher — en temps, en infrastructure et par le risque d’erreurs de sécurité. DTZ Identity existe déjà, gère déjà les parties difficiles (hachage des mots de passe, signature des tokens, rotation des clés), et ne coûte rien en plus. Pointer votre prochain projet perso vers https://identity.dtz.rocks au lieu de déployer Keycloak ou Auth0 maintient l’empreinte réduite et le besoin de maintenance quasi nul.

Telle est la philosophie DTZ appliquée à l’authentification : faire moins, utiliser ce qui existe déjà.

Moins d’infrastructure, même sécurité — pointez simplement vers l’émetteur OIDC et livrez.