--- id: CP-193 slug: sso-saml-openid-connect lang: it title: "Il SSO: SAML e OpenID Connect spiegati in modo semplice" description: Un solo account apre più applicazioni grazie a un token. Cosa fanno SAML e OpenID Connect e come comportarsi di fronte alle insidie. canonical_url: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ markdown_url: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, «Il SSO: SAML e OpenID Connect spiegati in modo semplice», Cyberpedia, 2026. https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ (CC BY 4.0)" wing: 3 theme: control_access reflex: cr-025 schema: G3 updated: "2026-11-03" translations: it: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ fr: https://startbrain.io/cyberpedia/fr/articles/sso-saml-openid-connect/ en: https://startbrain.io/cyberpedia/en/articles/sso-saml-openid-connect-explained/ de: https://startbrain.io/cyberpedia/de/articles/sso-saml-openid-connect/ es: https://startbrain.io/cyberpedia/es/articles/sso-saml-openid-connect/ nl: https://startbrain.io/cyberpedia/nl/articles/sso-saml-openid-connect/ sources: - "n": 1 title: NIST Special Publication 800-63C publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63c.html accessed: "2026-11-03" - "n": 2 title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 3 title: Steal Web Session Cookie, Technique T1539 - Enterprise | MITRE ATT&CK® publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 4 title: How the Microsoft identity platform uses the SAML protocol - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/saml-protocol-reference accessed: "2026-11-03" - "n": 5 title: OpenID Connect (OIDC) on the Microsoft identity platform - Microsoft identity platform publisher: Microsoft url: https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc accessed: "2026-11-03" - "n": 6 title: "Use Alternate Authentication Material: Application Access Token, Sub-technique T1550.001 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/001/ accessed: "2026-11-03" - "n": 7 title: SAML Security - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: "Forge Web Credentials: SAML Tokens, Sub-technique T1606.002 - Enterprise | MITRE ATT&CK®" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1606/002/ accessed: "2026-11-03" - "n": 9 title: "SP 800-63C-4, Digital Identity Guidelines: Federation and Assertions | CSRC" publisher: NIST url: https://csrc.nist.gov/pubs/sp/800/63/c/4/final accessed: "2026-11-03" --- # Il SSO: SAML e OpenID Connect spiegati in modo semplice 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 ciascuna [1]. 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. ## 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 password [2][3]. - 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. ## 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'applicazione [1]. Il NIST precisa che questo meccanismo evita di dover possedere credenziali separate per ogni servizio [1]. ### 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'applicazione [4]. 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 SAML [1]. ### 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 applicazione [1], 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 fattore [6], e i cookie di sessione possono aggirare alcuni protocolli di autenticazione a più fattori [3]. ## Come funziona Due attori si scambiano informazioni: l'identity provider, che autentica la persona, e l'applicazione, che si fida di ciò che esso afferma [4]. Il NIST chiama l'applicazione «parte affidataria» (relying party) e chiama asserzione il messaggio dell'identity provider che la informa sulla persona [1]. 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 firma [4]. 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 token [5]. L'OWASP descrive, per SAML, una risposta che contiene l'asserzione firmata digitalmente con la chiave privata dell'identity provider [7]. 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 token [8]. 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'asserzione [1]. La versione SP 800-63C-4, datata luglio 2025, sostituisce quella del 2 marzo 2020 [9]; questi tre livelli non sono quindi la regola attuale [1]. ## Cosa fate - 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 phishing [3]. - 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 dimenticata [6]. - Uscite dalla sessione su un computer condiviso. I cookie di sessione restano spesso validi a lungo, anche quando l'applicazione non è più in uso [3]. In Microsoft, la disconnessione pone fine alla sessione dell'utente [5]. - Leggete la finestra di richiesta di autorizzazione prima di fare clic. Chiede all'utente di concedere permessi a un'applicazione [5]. - 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 applicazione [2]. ## Le insidie ### 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 vero [3]. 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 proxy [2]. ### Il furto di token o di sessione I token di accesso servono a fare richieste autorizzate per conto di un utente [6]. Una volta rubati, sostituiscono la password: il gruppo APT29 usa token rubati per accedere ad account senza password [2]. Questi accessi tramite API sono difficili da individuare, anche da parte del fornitore, perché somigliano a un uso normale [6]. Cambiare la propria password può inoltre non bastare a interromperli [6]. I token di aggiornamento permettono di ottenerne di nuovi senza interpellare l'utente [2]. ### 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'accesso [2]. 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 contatti [2][6]. Il gruppo APT28 ha usato applicazioni camuffate da «Google Defender», «Google Email Protection» e «Google Scanner» per colpire utenti di Gmail [2]. ### 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 SSO [8]. MITRE cita la compromissione di SolarWinds, in cui il gruppo APT29 ha creato token con certificati di firma SAML compromessi [8]. ## Casi reali ### 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 digitale [7]. Questo lavoro spetta ai team informatici, non al dipendente. ## 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) --- Fonte originale: Cyberpedia, l'enciclopedia pubblica di cybersicurezza e IA pubblicata da Brain. Versione canonica: https://startbrain.io/cyberpedia/it/articles/sso-saml-openid-connect/ Puoi riutilizzare liberamente questo testo con licenza CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), a condizione di citare «Brain, Cyberpedia» con un link all'indirizzo qui sopra.