Usa tu cuenta DTZ para proteger cualquier servicio

Down-to-Zero siempre ha intentado darte una identidad para todo en la plataforma. Los tokens Bearer, las claves de API, el registro de contenedores, el servidor MCP — todos se validan contra el mismo servicio DTZ Identity. Pero ese mismo servicio de identidad también es un proveedor OpenID Connect (OIDC) totalmente compatible con los estándares, y eso significa que puedes usarlo para proteger cualquier cosa que hable OIDC, no solo los servicios de DTZ.

Si ya tienes una cuenta DTZ y un contexto, ya tienes las llaves. No hay que desplegar un nuevo IdP, no hay suscripción extra, no hay base de datos de contraseñas que mantener.

The insight: your context IS the OAuth client

La mayoría de las configuraciones OIDC requieren que registres una “aplicación” con el proveedor de identidad y obtengas un par client_id / client_secret. DTZ mantiene esto simple: el ID de tu contexto sirve para ambos. El contexto que ya creaste para tus cargas de trabajo es el cliente OAuth. Asigna client_id y client_secret al mismo ID de contexto y habrás terminado el registro.

Auto-discovery does the rest

OIDC define un documento de descubrimiento estándar que las librerías pueden obtener para aprender todas las URLs de endpoints, las claves de firma y los scopes soportados. DTZ publica uno en:

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

Cualquier librería OIDC decente — authlib de Python, coreos/go-oidc de Go, openid-client de Node y muchas otras — analizará ese documento y se configurará automáticamente. Nunca tendrás que codificar a mano los endpoints de token o userinfo.

A real example

Aquí está el bloque de entorno de un pequeño panel interno que conecté recientemente:

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"

Algunas cosas que vale la pena destacar:

• OIDC_CLIENT_ID == OIDC_CLIENT_SECRET — ambos son simplemente el ID del contexto. No es un error tipográfico.
• OIDC_ISSUER apunta a la raíz de descubrimiento. La librería obtiene /.well-known/openid-configuration desde ahí y se configura automáticamente.
• OIDC_ALLOWED_CLAIM / OIDC_ALLOWED_VALUES — después del intercambio de token, la app comprueba que la claim iss en el ID token devuelto sea igual a dtz.rocks. Esa sola comprobación asegura que solo los usuarios que se autentificaron a través de DTZ puedan entrar. Podrías endurecer esto comprobando las claims contexts o roles si quieres restringir a un contexto DTZ específico.

El servicio obtuvo el documento de descubrimiento al iniciar, derivó los endpoints de authorize y token, y simplemente funcionó. Tiempo total de integración: unos veinte minutos, la mayor parte de los cuales fue leer la documentación de la librería.

What the login flow looks like

1. Un usuario no autenticado accede a una ruta protegida.
2. Tu app redirige al endpoint de authorize de DTZ (descubierto automáticamente).
3. DTZ muestra la página de inicio de sesión estándar. Si el usuario ya está logueado, esto es instantáneo.
4. DTZ redirige de vuelta con un código de autorización.
5. Tu app intercambia el código por tokens en el endpoint de token.
6. Tu app valida la claim iss (o cualquier otra claim que te importe) y concede acceso.

Desde la perspectiva del usuario es una experiencia de inicio de sesión único: sus credenciales DTZ desbloquean el panel, la herramienta interna, la app autoalojada — lo que elijas proteger.

Why this matters for small teams

Levantar tu propio proveedor de identidad es caro — en tiempo, en infraestructura y en el riesgo de equivocarse en seguridad. DTZ Identity ya existe, ya maneja las partes difíciles (hashing de contraseñas, firma de tokens, rotación de claves) y no cuesta nada extra. Apuntar tu próximo proyecto lateral a https://identity.dtz.rocks en lugar de montar Keycloak o Auth0 mantiene la huella pequeña y la carga de mantenimiento casi en cero.

Esa es toda la filosofía DTZ aplicada a la autenticación: haz menos, usa lo que ya existe.

Menos infraestructura, misma seguridad — simplemente apunta al emisor OIDC y despliega.