OpenID Connect (OIDC) e SAML 2.0 sono i due protocolli dominanti per la federazione delle identità e il Single Sign-On enterprise. Servono scopi simili ma con approcci architetturali distinti, ottimizzati per contesti diversi. La scelta tra i due — o la decisione di supportarli entrambi — ha implicazioni sulla complessità di integrazione, sulla sicurezza e sull’interoperabilità con applicazioni esistenti.
Differenze architetturali fondamentali
SAML 2.0 è un protocollo XML-based nato nel 2005 per la federazione enterprise, progettato per un’era in cui le applicazioni erano web server-side e la comunicazione avveniva tramite browser redirect con form HTML POST. È verboso, potente e ben consolidato nell’ecosistema enterprise.
OpenID Connect è un layer di identità costruito sopra OAuth 2.0, pubblicato nel 2014. Usa JSON e JWT al posto di XML, e sfrutta le API REST di OAuth 2.0. È più compatto, più adatto alle applicazioni SPA e mobile, e nativo per l’ecosistema cloud-native.
Confronto dei token
| Aspetto | SAML 2.0 | OIDC |
|---|---|---|
| Formato | XML verboso, firmato (XMLDSig) | JSON compatto, firmato (JWT) |
| Trasporto | HTTP redirect (Base64) o HTTP POST form | Bearer token in header HTTP |
| Dimensione tipica | 2–10 KB (per attributi moderati) | 0.5–2 KB |
| Verifica | Parsing XML + XMLDSig | Verifica firma JWT (RS256/ES256) |
| Leggibilità | Difficile senza parser XML | Facilmente decodificabile (Base64URL) |
Il SAML Response porta l’asserzione direttamente nel browser (HTTP POST), che la inoltrea all’SP. L’ID Token OIDC è un JWT restituito dal token endpoint dell’IdP direttamente all’applicazione tramite richiesta API — non passa per il browser, riducendo la superficie di attacco.
Flussi di autenticazione OIDC
OIDC eredita i grant type di OAuth 2.0 adattandoli all’autenticazione:
Authorization Code Flow: il client riceve un code di breve durata, lo scambia via chiamata server-to-server con id_token e access_token. Il token non transita mai nel browser. Il flusso più sicuro per applicazioni web con backend.
PKCE (Proof Key for Code Exchange): estensione del Authorization Code Flow per applicazioni pubbliche (SPA, mobile) che non possono custodire un client_secret. Usa un code verifier casuale e il suo hash (code challenge) per legare la richiesta di autorizzazione allo scambio del codice.
Implicit Flow: deprecato in OAuth 2.1 — il token era restituito direttamente nell’URL fragment, con rischi di esposizione nei log del browser e nel Referer header.
Quando scegliere SAML
- Integrazione con applicazioni enterprise legacy: ERP, ITSM, applicazioni on-premise degli anni 2000–2010 supportano quasi sempre SAML e raramente OIDC
- Federazione B2B tra organizzazioni: lo standard consolidato per federare identità tra aziende diverse (es. partner commerciali, fornitori)
- Ambienti con Active Directory Federation Services (ADFS): Microsoft ADFS è l’IdP enterprise Windows, nativo SAML
Quando scegliere OIDC
- Applicazioni web moderne (SPA, React, Vue): le librerie JavaScript per OIDC/OAuth sono più mature e semplici da integrare rispetto a SAML
- Applicazioni mobile: OIDC con PKCE è lo standard per l’autenticazione su mobile (iOS, Android) — AppAuth è la libreria di riferimento
- Nuove integrazioni SaaS: la maggior parte dei provider SaaS moderni preferisce OIDC
- API-first: le API REST si integrano naturalmente con i Bearer token JWT di OIDC
Sicurezza comparata
Entrambi i protocolli, correttamente implementati, offrono sicurezza equivalente. Le vulnerabilità tipiche differiscono:
SAML è storicamente più vulnerabile a attacchi di XML Signature Wrapping (complessità del parsing XML) e a errori di configurazione legati alla verbosità del formato.
OIDC è più vulnerabile a state parameter bypass (CSRF sul flusso OAuth), open redirect negli authorization endpoint, e alla corretta validazione del JWT (algoritmo none, confusione RS256/HS256 — vedi JWT).
In entrambi i casi, la sicurezza dipende dall’implementazione della libreria e dalla correttezza della configurazione più che dalle proprietà intrinseche del protocollo.