Cos'è l'SSO Single Sign-On?

Single Sign-On (SSO) è un metodo di autenticazione che consente agli utenti di accedere a più applicazioni o servizi con un unico set di credenziali di accesso.

Che cos'è il Single Sign-On?

Single Sign-On è un modello di federazione delle identità in cui un utente si autentica una volta con un provider di identità (IdP) attendibile e quindi riceve asserzioni o token firmati crittograficamente che altri applicazioni (chiamati fornitori di servizi) accettano come prova di identità. Dopo l'accesso iniziale, l'IdP rilascia credenziali limitate nel tempo (ad esempio, asserzioni SAML o token ID OpenID Connect) che del browser or cliente viene presentato a ciascuna applicazione, che verifica la firma, il pubblico e la scadenza prima di stabilire la propria sessione.

Poiché la fiducia è ancorata all'IdP e trasmessa tramite protocolli basati su standard, SSO consente ai sistemi indipendenti di condividere una visione coerente di chi è l'utente, quali attributi ha e da quanto tempo autenticazione dovrebbe essere considerato valido.

Tipi di Single Sign-On

Di seguito sono elencati i tipi più comuni che incontrerai e gli obiettivi che ognuno di essi si prefigge.

Federazione SAML 2.0

SAML (Security Assertion Markup Language) è uno standard basato su XML ampiamente utilizzato per l'SSO del browser in azienda SaaSDopo l'autenticazione presso l'Identity Provider (IdP), il browser dell'utente riceve un'asserzione SAML firmata che il Service Provider (SP) convalida per stabilire una sessione.

SAML è maturo, eccelle nel rilascio degli attributi aziendali (ruoli, gruppi) ed è comune per HRIS-to-SaaS e ADFS-to-cloud integrazioni.

OpenID Connect (OIDC)

OIDC si basa su OAuth 2.0 e utilizza i JSON Web Token (JWT) per l'identità. Dopo l'autenticazione con l'IdP, il client ottiene un token ID (chi sei) e spesso un token di accesso (come puoi chiamare).

OIDC è più leggero di SAML, mobile e API-friendly e ideale per i moderni sito web e app mobili, applicazioni a pagina singola (SPA)e microservices che necessitano di token standardizzati e compatti.

Kerberos/Autenticazione integrata di Windows (IWA)

Nell'SSO basato su Kerberos (ad esempio, con Active Directory), il sistema operativo acquisisce un ticket da un centro di distribuzione delle chiavi (KDC) e lo presenta in modo trasparente ai servizi, abilitando l'SSO "silenzioso" sulle reti aziendali. È veloce, supporta l'autenticazione reciproca ed è ideale per app e intranet on-premise, poiché le configurazioni moderne spesso collegano le identità Kerberos a cloud tramite federazione.

SSO supportato da OAuth 2.0 (accesso basato su token)

OAuth è di per sé un framework di autorizzazione, non un protocollo di identità, ma molte distribuzioni SSO lo abbinano a OIDC o endpoint di identità personalizzati per consentire agli utenti di accedere una sola volta e ottenere token di accesso per le API. Il risultato è un SSO tra livelli web e di servizio con token, ambiti e flussi di aggiornamento di breve durata adatti a progetti zero-trust.

Federazione WS (WS-Fed)

Un vecchio protocollo di federazione Microsoft orientato a SOAP, ancora presente negli scenari legacy di ADFS e SharePoint. Abilita l'SSO tramite browser in modo simile a SAML, ma è meno comune nei progetti greenfield. Le organizzazioni spesso migrano le app WS-Fed a OIDC/SAML come parte di cloud modernizzazione.

CAS (Servizio di autenticazione centrale)

Si tratta di un semplice protocollo di concessione di ticket, diffuso nell'istruzione superiore. Gli utenti si autenticano presso un CAS centrale. server, che emette ticket di servizio che le applicazioni convalidano. CAS è semplice da utilizzare ed estendere, ma non dispone degli ecosistemi di claim e token più ricchi di SAML/OIDC.

SSO basato su proxy inverso/intestazione

Un gateway autentica gli utenti (tramite Kerberos, SAML, OIDC o MFA) e inietta intestazioni di identità (ad esempio, X-Remote-User) nelle app backend che non supportano i protocolli di federazione. È utile per il retrofitting di app legacy, ma la sicurezza dipende dalla fiducia assoluta solo ed esclusivamente da delega e rafforzando l'accesso diretto alle app.

Archiviazione password/SSO con compilazione moduli

Come metodo di ultima istanza per le app senza supporto di federazione, un gateway di accesso memorizza in modo sicuro le credenziali per utente e le registra a livello di programmazione. Migliora la praticità ma non fornisce una vera federazione e attività come la rotazione delle credenziali, AMF l'applicazione e la verifica diventano più complesse rispetto all'SSO basato su standard.

Come funziona il Single Sign-On?

L'SSO consente a un utente di autenticarsi una sola volta con un provider di identità attendibile e di riutilizzare tale prova per accedere a numerose applicazioni (fornitori di servizi, SP) in modo sicuro. Ecco come funziona esattamente:

1. Iniziazione e scoperta dell'IdP. L'utente tenta di aprire un'app. L'app (SP) non rileva alcuna sessione locale e reindirizza l'utente (spesso tramite metadati SAML/OIDC) all'IdP corretto, stabilendo dove avverranno la verifica di attendibilità e l'accesso.
2. Autenticazione utente presso l'IdP. L'IdP convalida l'identità utilizzando metodi configurati, come password e MFA, passkey o controlli dello stato del dispositivo, creando un nuovo contesto di autenticazione con un timestamp preciso e un livello di garanzia.
3. Emissione di token/asserzioni. In caso di esito positivo, l'IdP rilascia una credenziale firmata e limitata nel tempo (ad esempio, asserzione SAML, token ID OIDC e token di accesso) contenente l'identificativo e le attestazioni/attributi dell'utente.
4. Consegna sicura all'app. Il browser o il client ritorna all'SP portando con sé le credenziali tramite un binding sicuro (scambio di token POST/redirect front-channel o back-channel), preservando l'integrità e impedendo manomissioni o riproduzioni.
5. Verifica e creazione della sessione. Il SP convalida il firma, pubblico, emittente, nonce e scadenza. Se i controlli vengono superati, viene stabilita una sessione dell'app (cookie o token) e viene applicata l'autorizzazione in base a ruoli o claim.
6. Aggiornamento e incremento del token (se necessario). Con l'aumentare dell'età delle sessioni o della sensibilità dell'accesso, il client utilizza flussi di aggiornamento o di nuova autenticazione per ottenere nuovi token o potenziare l'MFA, mantenendo l'accesso continuo senza ripetuti accessi completi.
7. Disconnessione e revoca. Quando l'utente si disconnette o viene rilevato un rischio, l'SP termina la sessione. Facoltativamente, il Single Logout (SLO) o la revoca del back-channel presso l'IdP propagano la disconnessione ad altre app per chiudere le sessioni rimanenti.

Qual è un esempio di SSO?

Un esempio di SSO è quando un dipendente naviga in Salesforce senza una sessione locale, quindi Salesforce lo reindirizza a Okta (l'Identity Provider dell'organizzazione). L'utente completa l'accesso e l'autenticazione a più fattori (MFA) di Okta, che emette un'asserzione SAML firmata e di breve durata contenente l'ID e i ruoli dell'utente.

Il browser invia questa asserzione a Salesforce, che verifica la firma, il pubblico e la scadenza, quindi crea una propria sessione e applica le autorizzazioni dell'utente, quindi non è necessaria una password Salesforce separata. Gli accessi successivi ad altre app connesse (ad esempio, ServiceNow, Box) riutilizzano la sessione Okta, garantendo un accesso fluido a tutte le app con policy e audit centralizzati.

Quali sono i vantaggi e gli svantaggi del Single Sign-On?

Il Single Sign-On semplifica l'accesso consentendo agli utenti di autenticarsi una sola volta e di accedere a più app, migliorando l'esperienza utente e centralizzando i controlli di sicurezza. Tuttavia, concentrare l'autenticazione aumenta anche il rischio e la complessità: se il livello di identità non funziona o è configurato in modo errato, molte app vengono interessate contemporaneamente. Per questo motivo, è necessaria un'attenta progettazione per bilanciare praticità e solide misure di sicurezza.

Quali sono i vantaggi del Single Sign-On?

L'SSO migliora l'esperienza utente e centralizza il controllo federando l'autenticazione tramite un provider di identità affidabile. Ecco i suoi principali vantaggi:

• Meno password, migliore esperienza utente. Gli utenti effettuano l'accesso una sola volta e hanno accesso a tutte le app, riducendo così gli attriti e la fatica dell'accesso.
• Controlli di sicurezza più rigorosi. L'MFA centralizzata, le chiavi di accesso, i controlli dello stato del dispositivo e l'accesso condizionale si applicano in modo uniforme a tutte le app.
• Onboarding/offboarding più rapidi. La concessione o la revoca dell'accesso avviene tramite un record di identità, pertanto le modifiche si propagano a tutti i servizi connessi.
• Costi di supporto inferiori. Meno reimpostazioni delle password e blocchi degli account significano meno ticket di assistenza.
• Governance coerente. I ruoli, i gruppi e le policy basate sugli attributi vengono applicati allo stesso modo ovunque, supportando privilegio minimo.
• Migliore visibilità e controllo. I registri centrali e i token standardizzati semplificano il monitoraggio, risposta agli incidentie rendicontazione della conformità.
• Ridotto phishing rischio. Gli utenti riconoscono un unico flusso di accesso IdP rafforzato, quindi ci sono meno password specifiche per le app da rubare.
• App moderna e pronta per API. Gli standard (OIDC/SAML/OAuth) consentono l'accesso sicuro per web, dispositivi mobili e microservizi con token di breve durata.
• Gestione più sicura dei cambiamenti. La durata dei token, i criteri di sessione e l'autenticazione step-up consentono di aumentare la garanzia per le azioni sensibili senza nuovi accessi.
• Produttività migliorata. L'accesso multi-app senza interruzioni riduce i cambi di contesto e accelera i flussi di lavoro.

Quali sono gli svantaggi del Single Sign-On?

La centralizzazione dell'autenticazione offre vantaggi concreti, ma crea anche rischi tecnici e operativi da gestire. Ecco le principali sfide:

• Punto singolo di errore e raggio dell'esplosione. Se l'IdP non funziona o non è configurato correttamente, molte app diventano contemporaneamente inaccessibili.
• Rischio di configurazione errata. Una convalida debole dei token (audience/emittente/nonce), lunghe scadenze o un rilascio permissivo degli attributi possono aprire le porte all'impersonificazione e all'aumento dei privilegi.
• Igiene di sessione e token. Trovare un equilibrio tra praticità e sicurezza (ad esempio, la gestione dei timeout inattivi e assoluti, dei token di aggiornamento, dell'MFA step-up) è complicato, e le sessioni eccessivamente lunghe aumentano il rischio di acquisizione.
• Certificato e gestione delle chiavi. Chiavi di firma rotanti, movimentazione metadati Gli aggiornamenti e lo sfasamento dell'orologio richiedono operazioni disciplinate, altrimenti gli accessi potrebbero fallire silenziosamente.
• Complessità della disconnessione. Il supporto per la disconnessione singola (SLO) non è coerente e le disconnessioni parziali lasciano sessioni residue dell'app.
• Casi storici e casi limite. Le app non federate forzano l'archiviazione delle password o l'iniezione di intestazioni, aggiungendo fragilità e una sicurezza più debole rispetto alla vera federazione.
• Collegamento e ciclo di vita dell'account. La mappatura delle identità tra directory e tenant, il provisioning JIT e il deprovisioning tempestivo sono soggetti a errori senza risorse umane pulite e IAM fonti.
• Dispersione delle politiche di accesso. L'accesso condizionale, la postura del dispositivo e le eccezioni per app possono diventare difficili da gestire, causando interruzioni o lacune.
• Venditore e il blocco degli standard. Le funzionalità proprietarie o le stranezze del protocollo rendono le migrazioni costose e le strategie multi-IdP più difficili.
• Privacy e minimizzazione dei dati. Condividere eccessivamente gli attributi tra le app aumenta l'esposizione, pertanto sono necessari controlli di rilascio e consenso degli attributi minimi.
• Concentrazione di phishing e abusi. Un singolo flusso rafforzato può essere utile, ma se gli aggressori catturano le credenziali/sessioni dell'IdP, ereditano un accesso più ampio.

Domande frequenti sull'accesso singolo

Ecco le risposte alle domande più frequenti sull'accesso singolo.

Qual è la differenza tra SSO e AD?

Esaminiamo più in dettaglio le differenze tra Single Sign-On e Active Directory (AD):

Il Single Sign-On è sicuro?

Sì, se implementato correttamente, il Single Sign-On è molto sicuro perché centralizza controlli rigorosi (MFA/passkey, accesso condizionale, controlli di postura del dispositivo) presso un provider di identità consolidato ed emette token firmati di breve durata che ogni app verifica. I rischi principali derivano dall'architettura piuttosto che dal Single Sign-On stesso. Un'interruzione o una configurazione errata dell'IdP possono influire su molte app, mentre token di lunga durata o scarsamente convalidati aumentano il rischio di acquisizione.

L'SSO dovrebbe anche essere combinato con richieste di privilegi minimi, convalida rigorosa del token (emittente/pubblico/nonce/scadenza), rotazione delle chiavi e sincronizzazione dell'orologio, monitoraggio continuo con rilevamento delle anomalie, autenticazione step-up per azioni sensibili e architettura IdP resiliente (ridondanza, limitazione della velocità, Protezione DDoS). Grazie a queste misure di sicurezza, l'SSO in genere migliora la sicurezza rispetto agli accessi isolati per app.

Il Single Sign-On vale la pena?

Sì, il Single Sign-On è generalmente conveniente per la maggior parte delle organizzazioni perché semplifica l'autenticazione migliorando al contempo sicurezza e produttività. L'accesso centralizzato riduce l'affaticamento da password, il riutilizzo inadeguato delle credenziali e il sovraccarico dell'help desk dovuto alla reimpostazione delle password. Consente inoltre l'applicazione coerente di policy come l'autenticazione a più fattori e l'accesso condizionale su tutte le app connesse.

Lo sforzo iniziale di configurazione e la dipendenza da un fornitore di identità affidabile rappresentano dei veri e propri compromessi, ma i vantaggi a lungo termine: un livello di sicurezza più solido, un onboarding e un offboarding più rapidi, una migliore visibilità sulla conformità e un'esperienza utente più fluida di solito superano la complessità e i costi di implementazione.