--- title: "IAM & SSO" description: "Identity provider self-hosted, OIDC e OAuth2, single sign-on tra applicazioni diverse: architettura, deploy e sicurezza dei sistemi che decidono chi sei. - IAM & SSO - Pagina 1 di 2" canonical: "https://www.mauriziofonte.it/blog/cat/iam-sso.html" author: "Maurizio Fonte" --- Categoria # IAM & SSO Pagina 1 di 2 ## Chi sei, e chi lo garantisce Ogni sistema che gestisce utenti risponde, prima o poi, a due domande diverse che quasi tutti confondono: **chi sei** e **cosa puoi fare**. La prima è autenticazione e appartiene all'identity provider. La seconda è autorizzazione e quasi sempre appartiene all'applicazione, che conosce il proprio dominio di business meglio di qualunque IdP. Confonderle è la radice della maggior parte dei buchi che trovo negli impianti SSO delle aziende. In questa categoria raccolgo il lavoro sul campo su identità federata e single sign-on: protocolli come *OIDC*, OAuth2, SAML e LDAP, identity provider self-hosted, integrazione fra applicazioni scritte in linguaggi e framework diversi, e la parte che nessuno racconta mai, cioè cosa succede quando l'IdP va installato, aggiornato e tenuto in alta disponibilità su hardware che paghi tu. Il taglio è ingegneristico e verificato sul campo: codice reale ripulito dai riferimenti al cliente, configurazioni che girano in produzione, decisioni di design motivate e compromessi dichiarati. Mi interessa il punto in cui i protocolli incontrano un gestionale che esiste da dieci anni e non può essere riscritto. > Un token è un'istantanea, un permesso è uno stato: se il secondo viaggia dentro il primo, la revoca smette di funzionare. È il principio che attraversa tutti gli articoli di questa categoria. Se stai valutando di centralizzare le identità della tua azienda o di federare due applicazioni che oggi hanno login separati, nel [mio profilo professionale](https://www.mauriziofonte.it/pages/about) trovi la mia esperienza su integrazioni IAM end-to-end, dall'installazione dell'IdP fino all'autorizzazione applicativa. 1[2](https://www.mauriziofonte.it/blog/cat/iam-sso.md?page=2) [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Database](https://www.mauriziofonte.it/blog/cat/database.html) ## [Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database](https://www.mauriziofonte.it/blog/post/zitadel-sincronizzazione-identita-cross-ambiente.html) 12/08/2026 ![Sincronizzare le identità Zitadel tra più ambienti senza trascinare il database](https://www.mauriziofonte.it/image/005570200-zitadel-sincronizzazione-identita-cross-ambiente.jpg) Quando colleghi un'applicazione a un identity provider, ogni utente locale guadagna una colonna con l'identificativo esterno. Quella colonna è preziosa e fragile: costa migliaia di chiamate API per essere ricostruita, e applicarla alla riga sbagliata assegna l'identità di una persona a un'altra. Come l'ho portata fra ambienti diversi con un file di poche decine di kilobyte, una guardia che aborta invece di indovinare, e un'operazione ripetibile senza conseguenze. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-sincronizzazione-identita-cross-ambiente.html) Ultima modifica: Mercoledì 12 Agosto 2026, alle 16:14 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [NIS2](https://www.mauriziofonte.it/blog/cat/nis2.html) ## [2FA e NIS2 con Zitadel su un sistema di posta legacy](https://www.mauriziofonte.it/blog/post/zitadel-2fa-nis2-posta-legacy-postmaster.html) 11/08/2026 ![2FA e NIS2 con Zitadel su un sistema di posta legacy](https://www.mauriziofonte.it/image/005560200-zitadel-2fa-nis2-posta-legacy-postmaster.jpg) Attivare l'autenticazione a due fattori su un pannello di posta sembra una spunta da mettere, finché non ti accorgi che il codice via email finirebbe su una casella tecnica che per standard è recapitata all'operatore e non al cliente. Il difetto non è il secondo fattore: è che l'identità di accesso è una casella e non una persona. Il percorso di rimedio in tre passi, come si convive con i due sistemi durante la transizione, e le scadenze NIS2 reali che lo rendono urgente. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-2fa-nis2-posta-legacy-postmaster.html) Ultima modifica: Martedì 11 Agosto 2026, alle 15:41 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) ## [SSO opzionale con Zitadel: OIDC su un prodotto che gira anche standalone](https://www.mauriziofonte.it/blog/post/zitadel-sso-opt-out-capability-discovery-dual-mode.html) 10/08/2026 ![SSO opzionale con Zitadel: OIDC su un prodotto che gira anche standalone](https://www.mauriziofonte.it/image/005550200-zitadel-sso-opt-out-capability-discovery-dual-mode.jpg) Aggiungere il single sign-on a un prodotto che gira anche presso clienti senza identity provider non è mettere un flag: è progettare due forme del prodotto che convivono nello stesso codice. E siccome il flusso coinvolge due applicazioni, la modalità effettiva non è una configurazione ma un'intersezione, che va scoperta invece che assunta. Il pattern della negoziazione, il degrado direzionale, la macchina a cinque stati e come si collauda un prodotto che le ha tutte. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-sso-opt-out-capability-discovery-dual-mode.html) Ultima modifica: Lunedì 10 Agosto 2026, alle 16:31 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) ## [Deep-link SSO tra applicazioni con Zitadel senza aprire buchi](https://www.mauriziofonte.it/blog/post/zitadel-deep-link-sso-parametri-non-autorevoli.html) 07/08/2026 ![Deep-link SSO tra applicazioni con Zitadel senza aprire buchi](https://www.mauriziofonte.it/image/005540200-zitadel-deep-link-sso-parametri-non-autorevoli.jpg) Il collegamento che porta l'utente da un'applicazione all'altra già autenticato e sulla risorsa giusta è la funzionalità che tutti vogliono e che quasi nessuno implementa senza aprire un buco. Il problema non è l'autenticazione, che il protocollo risolve: è che un URL è un dato che l'utente controlla, e ogni parametro che ci metti diventa qualcosa su cui qualcuno proverà a barare. L'invariante che ho adottato, i vettori che ho provato e i compromessi che ho accettato. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-deep-link-sso-parametri-non-autorevoli.html) Ultima modifica: Venerdì 7 Agosto 2026, alle 15:26 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) ## [Revoca immediata con Zitadel: perché un permesso non va dentro il token](https://www.mauriziofonte.it/blog/post/zitadel-revoca-permessi-token-toctou.html) 06/08/2026 ![Revoca immediata con Zitadel: perché un permesso non va dentro il token](https://www.mauriziofonte.it/image/005530200-zitadel-revoca-permessi-token-toctou.jpg) Mettere i permessi dentro il token è la prima ottimizzazione che viene in mente e la più difficile da disfare: risparmia una query e, in cambio, rende la revoca inefficace fino alla scadenza. Ma rileggerli non basta, perché fra il controllo e l'uso resta una finestra in cui lo stato può cambiare. Il pattern che chiude entrambe le falle, il codice che lo implementa e la disciplina che impedisce a un'operazione nuova di sfuggire alla classificazione. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-revoca-permessi-token-toctou.html) Ultima modifica: Giovedì 6 Agosto 2026, alle 16:44 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Architettura Software](https://www.mauriziofonte.it/blog/cat/architettura_software.html) ## [Da ACL di directory a filtraggio applicativo: SSO con Zitadel senza perdere il recinto](https://www.mauriziofonte.it/blog/post/zitadel-sso-ldap-filtraggio-applicativo-fail-closed.html) 05/08/2026 ![Da ACL di directory a filtraggio applicativo: SSO con Zitadel senza perdere il recinto](https://www.mauriziofonte.it/image/005520200-zitadel-sso-ldap-filtraggio-applicativo-fail-closed.jpg) C'è un momento, in ogni migrazione verso il single sign-on, in cui l'applicazione smette di avere la password dell'utente. Sembra un progresso e lo è, ma se quella password serviva anche ad accedere ai dati, in quell'istante hai silenziosamente rimosso il controllo di accesso e nessun test se ne accorge. Come ho ricostruito il recinto a livello applicativo, perché un solo livello non basta, come si enumera davvero la superficie da proteggere, e il buco cross-tenant che l'audit ha trovato. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-sso-ldap-filtraggio-applicativo-fail-closed.html) Ultima modifica: Mercoledì 5 Agosto 2026, alle 15:58 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) ## [Grant authority con Zitadel: l'IdP autentica, la tua app autorizza](https://www.mauriziofonte.it/blog/post/zitadel-grant-authority-laravel-resource-server.html) 04/08/2026 ![Grant authority con Zitadel: l'IdP autentica, la tua app autorizza](https://www.mauriziofonte.it/image/005510200-zitadel-grant-authority-laravel-resource-server.jpg) Un identity provider sa chi sei e non sa niente di cosa puoi fare, perché i permessi veri dipendono da contratti, anagrafiche e stati che vivono nel tuo gestionale. Il pattern che ne esce è un monolite Laravel che diventa resource server e autorità di autorizzazione per le altre applicazioni, senza account di servizio e senza duplicare una riga di logica. Il middleware, la risoluzione deterministica dell'identità e il punto in cui quasi tutti sbagliano. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-grant-authority-laravel-resource-server.html) Ultima modifica: Martedì 4 Agosto 2026, alle 16:09 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [API Design](https://www.mauriziofonte.it/blog/cat/api-design.html) ## [OAuth2 con Zitadel: il token è la credenziale, il progetto è il confine di fiducia](https://www.mauriziofonte.it/blog/post/zitadel-oauth2-token-credenziale-project-audience.html) 03/08/2026 ![OAuth2 con Zitadel: il token è la credenziale, il progetto è il confine di fiducia](https://www.mauriziofonte.it/image/005500200-zitadel-oauth2-token-credenziale-project-audience.jpg) Quando due applicazioni devono fidarsi l'una dell'altra, la tentazione è aggiungere un segreto condiviso in un header. Non serve: se entrambe parlano con lo stesso identity provider, il token dell'utente è già una prova crittografica di chi sta chiamando. Il codice reale che valida quella prova, con la firma verificata in locale, il projectId nell'audience, l'autenticazione del client tramite chiave privata e i test che dimostrano che i casi sbagliati vengono respinti. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-oauth2-token-credenziale-project-audience.html) Ultima modifica: Lunedì 3 Agosto 2026, alle 15:33 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Business Continuity](https://www.mauriziofonte.it/blog/cat/business_continuity.html) ## [Zitadel in alta disponibilità: due nodi e upgrade a zero downtime](https://www.mauriziofonte.it/blog/post/zitadel-alta-disponibilita-upgrade-zero-downtime.html) 31/07/2026 ![Zitadel in alta disponibilità: due nodi e upgrade a zero downtime](https://www.mauriziofonte.it/image/005490200-zitadel-alta-disponibilita-upgrade-zero-downtime.jpg) Due istanze di un binario stateless dietro un bilanciatore sembrano il caso più semplice di alta disponibilità, e lo sarebbero se non ci fosse una fase che tocca lo schema del database. È quella fase a imporre un ordine fra i nodi, a rendere l'aggiornamento asimmetrico e a decidere se il rollback funziona ancora. La sequenza completa, lo script che la esegue, i codici di uscita per la pipeline, cosa monitorare davvero e le due cose che con la versione 4 sono cambiate. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-alta-disponibilita-upgrade-zero-downtime.html) Ultima modifica: Venerdì 31 Luglio 2026, alle 16:55 [IAM & SSO](https://www.mauriziofonte.it/blog/cat/iam-sso.html) [Linux & Server](https://www.mauriziofonte.it/blog/cat/linux.html) ## [Installare Zitadel 4 in produzione su Debian senza Docker](https://www.mauriziofonte.it/blog/post/zitadel-produzione-debian-senza-docker.html) 30/07/2026 ![Installare Zitadel 4 in produzione su Debian senza Docker](https://www.mauriziofonte.it/image/005480200-zitadel-produzione-debian-senza-docker.jpg) La guida ufficiale all'installazione di Zitadel su Linux si apre dichiarando che non vale per la versione 4 e ti manda su Docker. Il deploy nativo però funziona ancora, e i binari sono lì fra gli artefatti di rilascio: quello che cambia è che i componenti da installare sono due e non più uno. Questa è la procedura completa su Debian, con i tre file di configurazione, l'unità systemd che regge un audit, lo split di routing, cosa salvare davvero e i tre modi in cui si rompe. [Continua a leggere](https://www.mauriziofonte.it/blog/post/zitadel-produzione-debian-senza-docker.html) Ultima modifica: Giovedì 30 Luglio 2026, alle 15:12 1[2](https://www.mauriziofonte.it/blog/cat/iam-sso.md?page=2) ## Strumenti utili per lavorare su identità e SSO Un impianto SSO si verifica anche dall'esterno: il [decodificatore di certificati SSL](https://www.mauriziofonte.it/strumenti/decodifica-certificato-ssl) ti dice cosa presenta davvero il dominio dell'identity provider, e l'[analizzatore di header di sicurezza](https://www.mauriziofonte.it/strumenti/analizzatore-header-sicurezza) controlla le intestazioni della pagina di login, che è la superficie più esposta dell'intera federazione. --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about