OAuth 2.0, OIDC e SAML: differenze, casi d'uso e quando usarli

OAuth 2.0, OpenID Connect (OIDC) e SAML sono i tre standard che reggono autenticazione e autorizzazione moderne. Si somigliano nei nomi ma risolvono problemi diversi: sapere quale usare evita integrazioni fragili e scelte di lock-in difficili da correggere.

I tre protocolli in una frase

• OAuth 2.0 è un framework di autorizzazione: delega l'accesso a una risorsa senza condividere le credenziali.
• OpenID Connect (OIDC) è un livello di autenticazione costruito sopra OAuth 2.0: dice chi è l'utente.
• SAML è uno standard di autenticazione e Single Sign-On basato su XML, diffuso in ambito enterprise.

OAuth 2.0: autorizzazione, non autenticazione

OAuth 2.0 risponde alla domanda "questa applicazione può accedere a questa risorsa per conto dell'utente?". Non verifica l'identità: emette un access token che rappresenta un permesso delimitato (uno scope) e con una scadenza. È il protocollo che permette a un'app di leggere il tuo calendario o di chiamare un'API per tuo conto senza mai vedere la tua password.

L'errore classico è usare OAuth 2.0 "da solo" per fare login: il token dice cosa l'app può fare, non chi sei. Per l'autenticazione serve uno strato in più — ed è proprio quello che aggiunge OIDC.

OpenID Connect: l'identità sopra OAuth

OIDC estende OAuth 2.0 introducendo l'ID token, un JWT firmato che contiene le informazioni sull'utente (i claim: identificativo, email, nome). Con OIDC l'applicazione ottiene in un solo flusso sia l'autenticazione (chi sei) sia l'autorizzazione (cosa puoi fare), riutilizzando l'intera infrastruttura di OAuth 2.0.

È lo standard de facto per le applicazioni web e mobile moderne e per il Single Sign-On verso provider come Google Workspace e Microsoft Entra ID. Leggero, basato su JSON e REST, è quasi sempre la scelta giusta per le nuove integrazioni.

SAML: lo standard enterprise basato su XML

SAML (Security Assertion Markup Language) precede OIDC e domina ancora molti contesti enterprise e B2B. Scambia asserzioni XML firmate tra un Identity Provider (IdP) e un Service Provider (SP) per realizzare autenticazione e SSO. È maturo, robusto e supportato da praticamente ogni software aziendale legacy, ma più verboso e meno adatto a mobile e single-page application rispetto a OIDC.

Tabella di confronto

Quando usare quale

Usa OAuth 2.0 quando

Devi delegare l'accesso a un'API o a una risorsa senza gestire un login completo: integrazioni machine-to-machine, accesso a servizi di terze parti, autorizzazione di microservizi.

Usa OIDC quando

Stai costruendo una nuova applicazione web o mobile e ti serve sia il login sia l'accesso alle API. È la scelta predefinita per il login moderno e per l'SSO con i principali provider cloud.

Usa SAML quando

Devi integrarti con sistemi enterprise esistenti o con clienti B2B che impongono SAML come standard di federazione. Spesso convivono OIDC verso le nuove app e SAML verso i sistemi storici.

Integrazione con LoginMaster

LoginMaster supporta gli standard aperti per evitare il lock-in e semplificare l'adozione. Puoi integrare l'autenticazione e l'SSO tramite gli SDK TypeScript e .NET o direttamente via REST API, mantenendo l'architettura Tenant-Cloud in cui i dati personali non lasciano mai il tenant del cliente.

• SSO con Google Workspace e Microsoft Entra ID basato su OIDC.
• Integrazione applicativa tramite SDK TypeScript e .NET o REST API.
• Autenticazione a doppia firma e 2FA/TOTP configurabile sopra il flusso di login.
• Eventi di accesso esportabili verso SIEM (Splunk, QRadar, Sentinel, Elastic).

Per approfondire le fondamenta, vedi cos'è l'IAM e la pagina sicurezza. Per valutare un'integrazione concreta, richiedi una demo.