Usa il tuo account DTZ per proteggere qualsiasi servizio

Down-to-Zero ha sempre cercato di darti un’unica identità per tutto sulla piattaforma. Bearer token, API key, il registro dei container, il server MCP — tutti si autenticano contro lo stesso servizio DTZ Identity. Ma quello stesso servizio di identità è anche un provider OpenID Connect (OIDC) pienamente conforme agli standard, e questo significa che puoi usarlo per proteggere qualsiasi cosa parli OIDC, non solo i servizi DTZ.

Se hai già un account DTZ e un contesto, hai già le chiavi in mano. Nessun nuovo IdP da avviare, nessun abbonamento aggiuntivo, nessun database di password da mantenere.

L’intuizione: il tuo contesto È il client OAuth

La maggior parte delle configurazioni OIDC richiede di registrare un’“applicazione” presso il provider di identità e ricevere una coppia client_id / client_secret. DTZ mantiene le cose semplici: l’ID del tuo contesto funge da entrambi. Il contesto che hai già creato per i tuoi workload è il client OAuth. Imposta client_id e client_secret sullo stesso ID del contesto e hai finito la registrazione.

La scoperta automatica fa il resto

OIDC definisce un documento di discovery standard che le librerie possono ottenere per conoscere tutti gli URL degli endpoint, le chiavi di firma e gli scope supportati. DTZ ne pubblica uno a:

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

Qualsiasi libreria OIDC decente — authlib per Python, coreos/go-oidc per Go, openid-client per Node e innumerevoli altre — analizzerà quel documento e si configurerà automaticamente. Non devi mai hardcodare gli endpoint token o userinfo.

Un esempio reale

Ecco il blocco di ambiente di una piccola dashboard interna che ho configurato di recente:

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"

Alcune cose da evidenziare:

• OIDC_CLIENT_ID == OIDC_CLIENT_SECRET — entrambi sono semplicemente l’ID del contesto. Non è un errore di battitura.
• OIDC_ISSUER punta alla radice di discovery. La libreria recupera /.well-known/openid-configuration da lì e si configura automaticamente.
• OIDC_ALLOWED_CLAIM / OIDC_ALLOWED_VALUES — dopo lo scambio del token, l’app verifica che la claim iss nel token ID restituito sia uguale a dtz.rocks. Questa singola verifica garantisce che solo gli utenti autenticati tramite DTZ possano accedere. Puoi stringere ulteriormente i controlli verificando le claim contexts o roles se vuoi limitare l’accesso a uno specifico contesto DTZ.

Il servizio ha scaricato il documento di discovery all’avvio, ha derivato gli endpoint di authorize e token e ha funzionato subito. Tempo totale di integrazione: circa venti minuti, la maggior parte dei quali è stata dedicata alla lettura della documentazione delle librerie.

Com’è il flusso di login

1. Un utente non autenticato raggiunge una rotta protetta.
2. La tua app reindirizza all’endpoint authorize di DTZ (scoperto automaticamente).
3. DTZ mostra la pagina di login standard. Se l’utente è già loggato, è istantaneo.
4. DTZ reindirizza indietro con un codice di autorizzazione.
5. La tua app scambia il codice con i token presso l’endpoint token.
6. La tua app valida la claim iss (o qualsiasi altra claim che ti interessa) e concede l’accesso.

Dal punto di vista dell’utente è un’esperienza di single sign-on: le loro credenziali DTZ sbloccano il cruscotto, lo strumento interno, l’app self-hosted — qualunque cosa tu scelga di proteggere.

Perché questo conta per i piccoli team

Gestire il proprio provider di identità è costoso — in termini di tempo, infrastruttura e rischio di commettere errori di sicurezza. DTZ Identity esiste già, gestisce già le parti difficili (hashing delle password, firma dei token, rotazione delle chiavi) e non costa nulla di extra. Puntare il tuo prossimo side project su https://identity.dtz.rocks invece di mettere su Keycloak o Auth0 mantiene l’ingombro ridotto e il carico di manutenzione vicino allo zero.

Questa è tutta la filosofia DTZ applicata all’autenticazione: fare meno, usare ciò che già esiste.

Meno infrastruttura, stessa sicurezza — punta semplicemente all’issuer OIDC e vai in produzione.