Cyberpediadi Brain
ITDEENESFR

Il SSO: SAML e OpenID Connect spiegati in modo semplice

Un solo account apre più applicazioni grazie a un token. Cosa fanno SAML e OpenID Connect e come comportarsi di fronte alle insidie.

In 30 secondi

Dove succede
Ogni volta che si apre un'applicazione aziendale che rimanda alla pagina di accesso comune.
Cosa vuole l'attaccante
Un token, un cookie di sessione o un'autorizzazione concessa a un'applicazione trappola, che gli aprono l'accesso senza conoscere la password23.
Il riflesso
Verificare l'indirizzo della pagina di accesso, attivare l'autenticazione a due fattori sull'account principale, uscire dalla sessione su un computer condiviso e segnalare ogni richiesta di accesso inattesa.
Se è già successo
Avvisare subito il servizio informatico, indicando la pagina aperta e l'autorizzazione concessa.

Di cosa si tratta

Il SSO (single sign-on, accesso unico) consente di autenticarsi una sola volta presso un identity provider e di ottenere poi l'accesso a più applicazioni, senza creare né ricordare una password per ciascuna1. Il dipendente inserisce le proprie credenziali nella pagina di accesso dell'azienda e le applicazioni ricevono una prova della sua identità, non la sua password.

Per questo scambio si usano soprattutto due protocolli: SAML e OpenID Connect (OIDC). Non si vedono sullo schermo, ma i loro token sono diventati un bersaglio: rubare il token o la sessione equivale a rubare l'accesso.

Domande dirette

Che cos'è il SSO?

Un unico account, gestito da un identity provider, serve più applicazioni. Il documento del NIST sulla federazione delle identità descrive questo caso: l'utente non si autentica direttamente presso l'applicazione, ma è l'identity provider a produrre un'asserzione, spesso su richiesta dell'applicazione1. Il NIST precisa che questo meccanismo evita di dover possedere credenziali separate per ogni servizio1.

Che differenza c'è tra SAML e OpenID Connect?

SAML 2.0 è un protocollo che permette alle applicazioni di offrire il SSO ai propri utenti; scambia asserzioni tra l'identity provider e l'applicazione4. OpenID Connect estende il protocollo di autorizzazione OAuth 2.0 per farne un protocollo di autenticazione, e il SSO passa da un token di sicurezza chiamato token di identità (ID token)5. Il NIST cita entrambi come esempi di protocolli di federazione, con un'asserzione che assume la forma di un ID token OIDC o di un'asserzione SAML1.

Il SSO è meno sicuro di una password per ogni applicazione?

Sposta il rischio più di quanto lo elimini. Il dipendente non deve più gestire una password per ogni applicazione1, ma un solo account apre più servizi: se un attaccante ne prende il controllo, tutti i servizi che lo accettano sono esposti. Le insidie descritte più sotto approfondiscono questo punto.

Che cosa protegge l'autenticazione a due fattori e che cosa no?

Protegge l'accesso iniziale. Non protegge da un token o da un cookie già rubato: l'accesso diretto tramite token annulla l'effetto di un secondo fattore6, e i cookie di sessione possono aggirare alcuni protocolli di autenticazione a più fattori3.

1Come funziona1 min

Due attori si scambiano informazioni: l'identity provider, che autentica la persona, e l'applicazione, che si fida di ciò che esso afferma4. Il NIST chiama l'applicazione «parte affidataria» (relying party) e chiama asserzione il messaggio dell'identity provider che la informa sulla persona1.

Per SAML, Microsoft spiega che l'applicazione registra presso l'identity provider un indirizzo di reindirizzamento e un indirizzo di metadati, che permettono di ottenere la chiave di firma4. Con OIDC, l'applicazione recupera anche un documento di configurazione pubblico che fornisce gli indirizzi utili e le chiavi pubbliche usate per verificare la firma dei token5. L'OWASP descrive, per SAML, una risposta che contiene l'asserzione firmata digitalmente con la chiave privata dell'identity provider7.

Un token non è una password: attesta che un'autenticazione è già avvenuta. Per SAML, MITRE indica una durata di vita predefinita di un'ora, modificabile nel token8.

Nella versione 2017/2020 delle sue linee guida, oggi sostituita, il NIST classifica le asserzioni in tre livelli. Al primo, l'asserzione è firmata dall'identity provider. Al secondo, è anche cifrata per l'applicazione. Al terzo, l'utente dimostra inoltre di possedere una chiave legata all'asserzione1. La versione SP 800-63C-4, datata luglio 2025, sostituisce quella del 2 marzo 20209; questi tre livelli non sono quindi la regola attuale1.

2Cosa fate1 min
  • Guardate l'indirizzo della pagina di accesso prima di digitare una password. Alcuni attaccanti catturano la sessione al volo, ad esempio con gli strumenti evilginx2 e Muraena, usati in campagne di phishing3.
  • Attivate l'autenticazione a due fattori sul vostro account principale, quello che apre le altre applicazioni. Compromettere l'accesso alla posta principale può permettere di raggiungere gli altri servizi tramite la procedura di password dimenticata6.
  • Uscite dalla sessione su un computer condiviso. I cookie di sessione restano spesso validi a lungo, anche quando l'applicazione non è più in uso3. In Microsoft, la disconnessione pone fine alla sessione dell'utente5.
  • Leggete la finestra di richiesta di autorizzazione prima di fare clic. Chiede all'utente di concedere permessi a un'applicazione5.
  • Segnalate ogni richiesta di accesso o di autorizzazione che non avete avviato voi, soprattutto dopo un messaggio che vi spinge a fare clic su un link: è così che un attaccante fa concedere l'accesso alla propria applicazione2.
3Le insidie2 min

I falsi portali di accesso

I framework open source evilginx2 e Muraena raccolgono cookie di sessione tramite un proxy malevolo posto tra la vittima e il sito vero3. Kali365 ha ottenuto token di accesso e di aggiornamento OAuth spingendo le vittime ad approvare una richiesta di autorizzazione del dispositivo avviata dall'attaccante, e intercettando le sessioni grazie a un'infrastruttura di reverse proxy2.

Il furto di token o di sessione

I token di accesso servono a fare richieste autorizzate per conto di un utente6. Una volta rubati, sostituiscono la password: il gruppo APT29 usa token rubati per accedere ad account senza password2. Questi accessi tramite API sono difficili da individuare, anche da parte del fornitore, perché somigliano a un uso normale6. Cambiare la propria password può inoltre non bastare a interromperli6. I token di aggiornamento permettono di ottenerne di nuovi senza interpellare l'utente2.

I consensi OAuth abusivi

Un attaccante registra una propria applicazione presso il server di autorizzazione, poi invia un link di phishing perché il bersaglio le conceda l'accesso2. Una volta concesso il token, l'applicazione può ottenere un accesso duraturo all'account, ad esempio per cercare nella posta e consultare l'elenco dei contatti26. Il gruppo APT28 ha usato applicazioni camuffate da «Google Defender», «Google Email Protection» e «Google Scanner» per colpire utenti di Gmail2.

L'account unico, punto di cedimento

Chi possiede un certificato di firma SAML valido può falsificare token con i diritti e la durata che sceglie, e autenticarsi così presso tutti i servizi che usano SAML 2.0 per il SSO8. MITRE cita la compromissione di SolarWinds, in cui il gruppo APT29 ha creato token con certificati di firma SAML compromessi8.

4Casi reali1 min

2012: l'incapsulamento della firma XML

L'OWASP ricorda che nel 2012 sono state descritte vulnerabilità di implementazioni SAML legate ad attacchi di incapsulamento della firma XML (XML signature wrapping)7. Tra le sue raccomandazioni c'è una validazione sicura della firma digitale7. Questo lavoro spetta ai team informatici, non al dipendente.

Scheda

Identificativo
CP-193
Ala
3. Protocolli e difesa
Competenza Brain
Controllare gli accessi (control_access)
Riflesso Brain
cr-025
Schema
G3 · Sezione anatomica
Lingue
de, en, es, fr, it
Fonti
9 fonti verificate il 3 novembre 2026
Fonti9 fonti
  1. NIST, «NIST Special Publication 800-63C». https://pages.nist.gov/800-63-3/sp800-63c.html (consultato il 3 novembre 2026)
  2. MITRE ATT&CK, «Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1528/ (consultato il 3 novembre 2026)
  3. MITRE ATT&CK, «Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1539/ (consultato il 3 novembre 2026)
  4. Microsoft, «How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference (consultato il 3 novembre 2026)
  5. Microsoft, «OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform». https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc (consultato il 3 novembre 2026)
  6. MITRE ATT&CK, «Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1550/001/ (consultato il 3 novembre 2026)
  7. OWASP, «SAML Security - OWASP Cheat Sheet Series». https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html (consultato il 3 novembre 2026)
  8. MITRE ATT&CK, «Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®». https://attack.mitre.org/techniques/T1606/002/ (consultato il 3 novembre 2026)
  9. NIST, «SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC». https://csrc.nist.gov/pubs/sp/800/63/c/4/final (consultato il 3 novembre 2026)

Cita questo articolo

Brain, «Il SSO: SAML e OpenID Connect spiegati in modo semplice», Cyberpedia, 2026. https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/

BibTeX 
@misc{brain_cp193_it_2026,
  author = {Brain},
  title = {Il SSO: SAML e OpenID Connect spiegati in modo semplice},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/},
  note = {CC BY 4.0}
}
Licenza CC BY 4.0