Integrazione Single Sign-On: come funziona e come realizzarla

Il single sign-on (SSO) non è un prodotto da installare. È un'integrazione fra un fornitore di identità centrale e ogni applicazione che il tuo team usa. Il fornitore di identità verifica chi è l'utente e tutte le applicazioni collegate si fidano di quella decisione. Per farlo bene servono quattro cose: scegliere il protocollo giusto (SAML o OpenID Connect), mettersi d'accordo sui dati di identità che ogni applicazione riceve, gestire la creazione e la cancellazione degli account e fare i test prima di rendere l'SSO obbligatorio. Noi costruiamo e colleghiamo sistemi aziendali tutti i giorni, e questa guida percorre l'intero cammino.

In breve

• L'SSO è un'integrazione: un fornitore di identità verifica l'utente e ogni applicazione (il fornitore di servizi) si affida a quel verdetto.
• Usa SAML 2.0 per le applicazioni web aziendali tradizionali e OpenID Connect (OIDC) per applicazioni web moderne, app mobili e API.
• L'SSO gestisce solo l'accesso. Aggiungi SCIM se vuoi che gli account vengano creati e disattivati automaticamente quando qualcuno entra o lascia l'azienda.
• Pianifica in quest'ordine: inventario delle applicazioni, definizione di attributi e ruoli, pilota con applicazioni a basso rischio, test, poi obbligo e monitoraggio.
• In Svizzera resti responsabile della base legale, dei responsabili del trattamento, delle comunicazioni all'estero, dei log e della cancellazione, anche quando è un fornitore cloud a gestire l'accesso.

Il single sign-on è un'integrazione?

Sì. Microsoft defines SSO come un unico accesso con una sola serie di credenziali, che poi dà modo di raggiungere le applicazioni assegnate senza doversi autenticare di nuovo. Dietro a questa esperienza, un fornitore di identità centrale verifica l'utente e conferma l'identità a ciascuna applicazione.

Ecco perché la formula più cercata è «integrazione single sign-on». Attivare l'SSO significa collegare fra loro due lati:

• Il fornitore di identità (IdP): l'autorità centrale, per esempio Microsoft Entra ID o Okta.
• Il fornitore di servizi (SP): il tuo CRM, il tuo ERP, il portale clienti, gli strumenti interni. Okta describes l'IdP come autorità centrale di autenticazione e le applicazioni come fornitori di servizi che si affidano alla sua decisione di identità federata.

La domanda collegata, «che differenza c'è fra API e SSO?», ha una risposta breve. Un'API permette a un sistema di chiamarne un altro per scambiare dati o avviare azioni. L'SSO permette a una persona di dimostrare una volta sola chi è. Spesso si incontrano: OIDC, per esempio, serve anche le API che hanno bisogno sia di autenticazione sia di autorizzazione.

Come funziona il flusso di accesso

Nel flusso più comune, avviato dal fornitore di servizi, la sequenza è semplice:

1. L'utente apre un'applicazione.
2. L'applicazione lo reindirizza al fornitore di identità.
3. L'IdP verifica le credenziali aziendali dell'utente e ne conferma l'identità.
4. L'applicazione concede l'accesso.

Microsoft defines SSO. Supporta anche i identity-provider-initiated flows per le applicazioni SAML, dove l'utente parte da un portale (Microsoft lo chiama My Apps) e clicca sulla scheda di un'applicazione. I flussi avviati dal fornitore di servizi funzionano sia con SAML sia con OIDC.

Una volta capito il flusso, si capisce anche dove le integrazioni si rompono: indirizzi di reindirizzamento che non corrispondono, certificati scaduti e attributi che arrivano vuoti o con un nome diverso da quello che l'applicazione si aspetta.

SAML, OpenID Connect e OAuth: quale scegliere

Il protocollo decide come le informazioni di identità vengono confezionate e consegnate alla tua applicazione. Microsoft defines SSO, SAML 2.0 è uno standard basato su XML, molto diffuso nelle aziende, adatto alle applicazioni web tradizionali e agli attributi utente dettagliati. OIDC si appoggia a OAuth 2.0, usa token in formato JSON ed è adatto ad applicazioni web moderne, app mobili e API che hanno bisogno sia di autenticazione sia di autorizzazione.

	SAML 2.0	OpenID Connect
Formato	Asserzioni XML	Token in formato JSON (ID token)
Uso tipico	Applicazioni web aziendali tradizionali, attributi utente ricchi	Applicazioni web moderne, app mobili, API
Basato su	Uno standard proprio	OAuth 2.0
Elementi di configurazione tipici	Entity ID, reply URL, certificato di firma o metadati	Issuer, client ID, client secret, URI di reindirizzamento

Una distinzione manda in confusione parecchi team. OAuth 2.0 is an authorization framework per l'accesso delegato a risorse protette. OpenID Connect ci aggiunge sopra l'autenticazione dell'utente e dichiarazioni di identità standardizzate. Se hai bisogno di sapere chi è l'utente, ti serve OIDC (o SAML), non OAuth da solo.

Nessuno dei due protocolli cambia chi prende la decisione di autenticazione. Secondo il identity-provider-initiated flows, cambia solo il modo in cui l'identità viene consegnata. Scegli quindi in base a ciò che la tua applicazione supporta e a ciò che ti servirà dopo: se l'applicazione di un fornitore offre solo SAML, usa SAML. Se stai costruendo un prodotto nuovo con un client mobile, OIDC è la scelta naturale.

Pianifica l'integrazione prima di toccare le impostazioni

La maggior parte dei rollout falliti salta la pianificazione. Tre cose vanno messe per iscritto prima di tutto.

Fai l'inventario delle applicazioni

L'Enterprise SSO Playbook statunitense mette l'inventario delle applicazioni come primo passo della pianificazione dell'integrazione. Per ogni applicazione annota i protocolli supportati, i gruppi di utenti, gli attributi necessari, il modo in cui vengono creati gli account e quanto l'applicazione è critica. È quest'ultima colonna a decidere l'ordine del rollout.

Mettiti d'accordo sui dati di identità

Le AGOV guidance della Confederazione elencano i punti di interoperabilità che una configurazione di fiducia dovrebbe definire: dichiarazioni e attributi, identificatori di persona stabili, mappatura di ruoli e gruppi, procedure di firma o cifratura. L'identificatore stabile è la cosa più importante. Se le applicazioni riconoscono gli utenti dall'indirizzo e-mail e qualcuno cambia nome, ti ritrovi con account doppi o orfani. Decidi un solo identificatore immutabile per persona e usalo ovunque.

La mappatura dei ruoli merita la stessa attenzione. Decidi quale gruppo dell'IdP diventa quale ruolo in ciascuna applicazione, e mettilo nero su bianco. Altrimenti «admin» in un sistema finisce per significare in silenzio qualcosa di diverso in un altro.

Decidi l'ordine del rollout

Lo stesso playbook, insieme ad altre indicazioni che riassume, consiglia un approccio a tappe: comincia dalle applicazioni a rischio più basso, usa i riscontri del pilota prima del rilascio completo, poi Enterprise SSO Playbook. Nel pilota metti il wiki interno o uno strumento di progetto, non il sistema di contabilità.

Passo per passo: collegare un'applicazione

I passaggi cambiano leggermente a seconda del protocollo. La struttura è la stessa.

Passo 1: registra l'applicazione nel fornitore di identità

Per una connessione OIDC, la registrazione produce un issuer, un client ID e un client secret. La tua applicazione va configurata con gli URI di reindirizzamento e deve validare l'ID token del fornitore. La Guard.ch’s setup guide descrive questi campi e i passaggi di validazione nella pratica.

Per una connessione SAML, la registrazione richiede di solito l'entity ID, l'URL dell'assertion consumer service (reply URL), un certificato di firma o i metadati di federazione, la mappatura delle dichiarazioni, l'assegnazione degli utenti e un account di prova, come listed in this Entra integration guide.

Dove si sbaglia: una barra di troppo alla fine di un URI di reindirizzamento, un certificato incollato perdendo le interruzioni di riga, oppure un client secret che scade senza che nessuno si occupi del rinnovo. Metti le date di scadenza in un calendario condiviso fin dal primo giorno.

Passo 2: mappa dichiarazioni e ruoli

Invia solo gli attributi di cui l'applicazione ha bisogno: un identificatore stabile, un indirizzo e-mail, il nome e il gruppo o ruolo. Meno attributi significano meno dati personali in circolazione, il che aiuta anche sui punti svizzeri di protezione dei dati di cui parliamo più sotto.

Passo 3: assegna gli utenti

Comincia con un piccolo gruppo di persone definite per nome. Nelle configurazioni SAML, l'assegnazione degli utenti all'applicazione nell'IdP fa parte della registrazione, e dimenticarsene produce un «accesso negato» incomprensibile per persone che in realtà sono autorizzate.

Passo 4: prova con un account reale

Ai test è dedicata una sezione a parte più avanti. Non rendere obbligatorio l'SSO finché un accesso completo non funziona da capo a fondo.

Passo 5: rendi obbligatorio, poi monitora

Solo dopo un pilota riuscito imponi l'SSO a tutti e disattivi l'accesso con password. Tieni documentato almeno un percorso amministrativo di emergenza, così un IdP configurato male non chiude fuori l'intera azienda.

Provisioning: l'SSO non elimina gli account

È la parte che molte guide trattano di sfuggita. L'SSO autentica, non gestisce il ciclo di vita dell'account. Come afferma listed in this Entra integration guide, SAML o OIDC autenticano l'utente, mentre SCIM crea e disattiva gli account nelle applicazioni; la guida consiglia entrambi per coprire tutto il ciclo di vita.

La differenza si vede all'uscita di una persona. Il SAML just-in-time provisioning crea un account al primo accesso ma non può eliminarlo. SCIM può creare gli account prima del primo accesso e disattivarli quando qualcuno lascia l'azienda. Se l'account IdP di un ex collaboratore è disattivato ma il suo account nell'applicazione resta lì, un token o una sessione ancora validi possono continuare a funzionare.

Quando integri il supporto SCIM nella tua applicazione, tratta active=false come una revoca immediata dell'accesso. The SCIM guide notes che Okta invia di solito una PATCH che imposta active su false invece di una DELETE: un'applicazione che aspetta una cancellazione non revocherà mai l'accesso.

Testare e mantenere l'integrazione

Un buon flusso di test verifica più del semplice «sono riuscito a entrare». Il Guard.ch’s setup guide esegue un accesso presso il fornitore senza autenticare davvero l'utente, mostra l'indirizzo e le dichiarazioni ricevute e richiede un test riuscito dopo ogni modifica alla connessione prima che l'SSO possa diventare obbligatorio. È uno schema da copiare: vedi esattamente cosa ha inviato l'IdP prima di fidarti.

Per il provisioning, la Bynder’s support guide suggerisce di usare un utente di prova reale, verificare gli attributi e i permessi richiesti e controllare i log di provisioning.

Una breve lista di test:

• Un nuovo utente accede per la prima volta e arriva con il ruolo giusto.
• Un utente nel gruppo sbagliato viene respinto.
• Un utente disattivato non riesce più ad accedere e il suo account nell'applicazione risulta disattivato.
• Un utente che cambia reparto ottiene il nuovo ruolo.
• Dopo ogni modifica alla connessione (nuovo certificato, nuovo secret), il test viene ripetuto con successo prima di rendere l'SSO obbligatorio.

La manutenzione è soprattutto lavoro da calendario: rinnovo di certificati e secret, revisione delle mappature dei gruppi quando i team si riorganizzano e una lettura periodica dei log di accesso.

Sicurezza: cosa concentra l'SSO

L'SSO elimina la proliferazione delle password, ma centralizza il rischio. Auth0 explains che il rischio si concentra nei token e nelle sessioni applicative. Le contromisure indicate sono concrete: validare firma, scadenza, issuer e audience dei token; usare PKCE, archiviazione sicura dei token, token di accesso di breve durata e rotazione dei refresh token; applicare timeout di sessione e autenticazione rafforzata per le azioni ad alto rischio.

Il materiale del NIST sulla sicurezza dei token sottolinea che signing keys are the root of trust e che asserzioni e token andrebbero limitati nell'ambito, validati e vincolati nel tempo. In pratica significa limitare chi può mettere mano alle chiavi di firma e ruotarle secondo un calendario.

Per i servizi critici, aggiungi livelli invece di affidarti al solo accesso. Un'security analysis by Doyensec sostiene che non bisogna dare per scontato che il fornitore di identità resti sempre sicuro, ed elenca MFA aggiuntiva, richieste di accesso con privilegi minimi, certificati di breve durata e monitoraggio continuo. Richiedi un secondo fattore presso il fornitore di identità; una multi-factor authentication setup guide mostra come si configura di solito questo livello per account come la posta elettronica.

Protezione dei dati in Svizzera

Se i tuoi utenti o clienti sono in Svizzera, il sistema di accesso non è fuori dalla protezione dei dati. Le indicazioni AGOV sulle AGOV guidance dicono che l'organizzazione resta responsabile della base legale, della finalità e della proporzionalità, della scelta del fornitore cloud o SaaS, dei diritti di accesso e della sicurezza delle informazioni. Nominano inoltre responsabili del trattamento e subfornitori, comunicazioni all'estero, conservazione e cancellazione, log, continuità e uscita, oltre all'informazione alle persone interessate.

Traducilo in compiti di progetto:

• Annota quale fornitore gestisce il servizio di identità e dove vengono trattati i dati.
• Limita le dichiarazioni inviate a ciascuna applicazione a ciò che le serve davvero.
• Stabilisci per quanto tempo conservare i log di accesso e chi può leggerli.
• Pianifica l'uscita: se lasci l'IdP, come si spostano utenti e applicazioni?
• Spiega agli utenti quali dati vengono trattati.

Per domande sulla tua specifica base legale, parla con il tuo consulente per la protezione dei dati o con un legale.

Dove uno studio può aiutarti

Il lavoro sul protocollo è standard. La parte difficile è il sistema attorno: applicazioni legacy che non parlano né SAML né OIDC, un portale su misura che ha bisogno di endpoint SCIM, collegamenti fra shop, CRM ed ERP che devono accordarsi tutti su una sola identità utente. Ampersand è uno studio di Zurigo dove ingegneri senior guidano ogni progetto dal primo contatto alla consegna, e ci occupiamo di integrazioni di sistema e connettività API per shop, CRM ed ERP, oltre che di replatforming e migrazione di sistemi legacy. La nostra pagina dei prezzi elenca le opzioni di integrazione, da una singola connessione a una suite completa, e un piano Run & monitor a 750 CHF al mese per il supporto continuo.

Domande frequenti

SSO e OAuth sono la stessa cosa?

No. OAuth 2.0 è un framework per l'accesso delegato alle risorse. L'SSO è il risultato di un unico accesso, che viene realizzato da SAML o OpenID Connect. OpenID Connect si appoggia a OAuth 2.0 e aggiunge dichiarazioni di identità standardizzate.

Come integro il single sign-on in un'applicazione esistente?

Registra l'applicazione nel tuo fornitore di identità, scegli SAML o OIDC in base a ciò che l'applicazione supporta, mappa le dichiarazioni e i ruoli e assegna un piccolo gruppo di prova. Esegui un test di accesso completo, poi rendi obbligatorio l'SSO e monitora i log. Aggiungi SCIM se vuoi la disattivazione automatica degli account.

L'SSO sostituisce il provisioning degli utenti?

No. L'SSO verifica l'identità al momento dell'accesso. Creare e disattivare gli account è compito del provisioning, di solito SCIM. Senza, gli account possono restare attivi anche dopo che una persona ha lasciato l'azienda.

Il single sign-on è sicuro?

Può esserlo, se i token vengono validati, le sessioni hanno una durata limitata, è richiesto un secondo fattore e l'attività di accesso viene monitorata. L'SSO concentra il rischio nel fornitore di identità e nei token, quindi sono proprio questi a richiedere la protezione maggiore.

Quale protocollo dovrebbe usare una nuova applicazione web?

OpenID Connect è adatto ad applicazioni web moderne, app mobili e API. SAML 2.0 è la scelta quando lo richiedono i sistemi aziendali dei tuoi clienti o l'applicazione di un fornitore. Molti prodotti supportano entrambi.

Fonti

• Microsoft defines SSO
• identity-provider-initiated flows
• Okta describes
• OAuth 2.0 is an authorization framework
• AGOV guidance
• Enterprise SSO Playbook
• Guard.ch’s setup guide
• listed in this Entra integration guide
• SAML just-in-time provisioning
• The SCIM guide notes
• Bynder’s support guide
• Auth0 explains
• security analysis by Doyensec
• signing keys are the root of trust