Il Single Sign-On (SSO) è un meccanismo di autenticazione federata che permette a un utente di autenticarsi una sola volta presso un Identity Provider (IdP) e accedere poi a molteplici applicazioni e servizi — i Service Provider (SP) — senza reinserire le credenziali per ognuno. Il controllo dell’identità è centralizzato nell’IdP; le applicazioni si fidano delle asserzioni che l’IdP rilascia sull’identità dell’utente, senza gestire direttamente le credenziali.
Modello di fiducia
Il triangolo di fiducia SSO coinvolge tre attori:
- Utente (principal): si autentica una volta sola all’IdP
- Identity Provider (IdP): verifica l’identità, gestisce le credenziali, emette token/asserzioni (es. Okta, Azure AD, Google Workspace, ADFS)
- Service Provider (SP): l’applicazione che riceve l’asserzione dall’IdP e concede l’accesso senza verificare direttamente le credenziali (es. Salesforce, Slack, GitHub Enterprise, qualsiasi app SaaS)
La fiducia tra SP e IdP è stabilita preventivamente tramite scambio di metadati (certificati, endpoint) in fase di configurazione. L’SP non ha mai accesso alla password dell’utente — riceve solo un’asserzione firmata dall’IdP.
Protocolli principali
I due standard dominanti per SSO sono SAML 2.0 e OpenID Connect (OIDC). Hanno origini diverse e casi d’uso leggermente distinti, ma entrambi implementano il modello SSO:
SAML 2.0: basato su XML, progettato per ambienti enterprise. Asserzioni XML firmate con firma digitale. Standard per federazione tra organizzazioni diverse e integrazione con applicazioni enterprise legacy.
OIDC: basato su JSON/JWT, layer di identità sopra OAuth 2.0. Più moderno, adatto per applicazioni web e mobile. Dominante nel mondo consumer (Google, Apple, Facebook Login) e nelle nuove integrazioni SaaS.
Kerberos: il protocollo SSO nativo per reti Windows Active Directory. Usato internamente alla rete aziendale, non su Internet aperto.
Vantaggi di sicurezza
Riduzione della superficie d’attacco delle credenziali: l’utente ha una sola credenziale master (presso l’IdP) invece di decine di password diverse per ogni applicazione. Elimina il problema delle password deboli e riusate sulle singole applicazioni.
MFA centralizzato: l’autenticazione multi-fattore è configurata una volta sull’IdP e si applica automaticamente a tutte le applicazioni federate — senza dover abilitare MFA separatamente su ogni SP.
Revoca centralizzata: disabilitare un account sull’IdP revoca immediatamente l’accesso a tutte le applicazioni federate. Critico per i processi di offboarding — senza SSO, un ex dipendente potrebbe mantenere accesso ad applicazioni SaaS dimenticate.
Visibilità: l’IdP è il punto di osservazione centrale di tutti gli accessi — chi si è autenticato, da dove, a quali applicazioni, con quale dispositivo. Feed ideale per il SIEM.
Rischi specifici dell’SSO
Il rovescio della medaglia è che l’IdP diventa un single point of failure e un high-value target: compromettere l’IdP significa compromettere l’accesso a tutte le applicazioni federate simultaneamente. Attacchi documentati:
Golden SAML: analogia con il Golden Ticket Kerberos. Se l’attaccante ottiene la chiave privata usata dall’IdP per firmare le asserzioni SAML, può forgiare asserzioni arbitrarie per qualsiasi utente verso qualsiasi SP. Documentato nell’attacco SolarWinds (2020): dopo aver compromesso i server on-premise, gli attaccanti hanno estratto le chiavi ADFS per creare asserzioni SAML fraudolente verso Microsoft 365.
Session hijacking post-SSO: dopo l’autenticazione SSO, ogni SP mantiene la propria sessione. Un cookie di sessione rubato su un SP non espone gli altri — ma il token SSO dell’IdP (se rubato) permette di creare sessioni su tutti gli SP.
IdP misconfiguration: SP configurati per accettare asserzioni senza validare la firma, o con audience restriction troppo permissiva, permettono attacchi di replay di asserzioni destinate ad altri SP.