OAuth o SAML: quale protocollo scegliere?

OAuth e SAML risolvono problemi diversi, ed è proprio per questo che metterli a confronto diretto è un po' fuorviante. SAML fa accedere una persona a un'applicazione tramite un fornitore di identità centrale, soprattutto nel single sign-on aziendale. OAuth 2.0 permette a un'applicazione di ottenere un accesso limitato all'API di un altro servizio per conto di un utente. Il protocollo che quasi tutti intendono davvero quando dicono «login con OAuth» è OpenID Connect (OIDC), un sottile strato di identità costruito sopra OAuth. La scelta reale, per la maggior parte dei team, è quindi fra SAML e OIDC per il login, e OAuth per l'accesso alle API.

Qui sotto vediamo cosa fa ciascuno, in cosa differiscono nella pratica, come decidere e cosa cambia quando i tuoi utenti e i tuoi dati si trovano in Svizzera.

In breve

• OAuth 2.0 riguarda l'autorizzazione: risponde alla domanda «questa applicazione può chiamare quell'API, e con quale ambito?». Non ti dice chi è l'utente.
• SAML 2.0 riguarda il login federato: uno standard basato su XML per l'SSO via browser, tuttora l'opzione predefinita in molti ambienti aziendali e legacy.
• OIDC è OAuth più l'identità: aggiunge un ID token, così ottieni un'autenticazione standardizzata. Di solito è la scelta migliore per nuovi prodotti web, mobile e basati su API.
• Supporta entrambi se i tuoi clienti sono grandi aziende o autorità: i servizi di identità della Confederazione accettano sia OIDC sia SAML 2.0.
• Il protocollo non risolve i tuoi obblighi legali: secondo la legge svizzera sulla protezione dei dati (LPD), quello che fai con i dati personali dopo il login va comunque giustificato.

Cosa fa davvero ciascun protocollo

Il modo più rapido per distinguere i tre nomi è guardare alla domanda a cui ognuno risponde. One practical comparison lo riassume bene: OAuth risponde se un'applicazione può chiamare un'API, OIDC risponde a chi ha effettuato l'accesso e SAML gestisce il login federato fra un fornitore di identità e un'applicazione.

OAuth 2.0: accesso delegato

OAuth 2.0 è definito nell'RFC 6749. Il suo compito è permettere a un'applicazione di ottenere un accesso limitato a una risorsa protetta, per conto di un utente o per conto proprio. Pensa a uno strumento di pianificazione che legge il tuo calendario, o a un servizio di back-end che chiama l'API di un'altra azienda. L'utente non consegna mai la propria password alla terza parte. L'applicazione riceve invece un access token con un ambito e una durata definiti.

Il punto importante: un access token è un permesso, non una carta d'identità. Se consideri «ho un token valido» come «so chi è questa persona», prima o poi finirai per rilasciare una falla di sicurezza. È un errore frequente, ed è esattamente il motivo per cui esiste OIDC.

Lo standard, inoltre, continua a evolvere. La OAuth 2.1 draft dell'IETF viene descritta come sostitutiva dell'RFC 6749 e del documento sull'uso dei bearer token, anche se nella versione che abbiamo consultato era ancora un Internet-Draft. Il consiglio pratico oggi resta lo stesso: usa l'authorization code flow con PKCE e lascia perdere i flussi obsoleti.

OpenID Connect: OAuth con il login

OIDC riutilizza i flussi di OAuth 2.0 e aggiunge un ID token standard, un JSON Web Token firmato che porta con sé le informazioni su chi si è autenticato e come. Usa JSON e normali chiamate in stile REST, il che si adatta bene alle single-page app, alle app mobile native e ai sistemi incentrati sulle API. Quando uno sviluppatore dice «usiamo OAuth per accedere con Google», nella quasi totalità dei casi intende OIDC.

SAML 2.0: il cavallo da tiro dell'SSO aziendale

SAML 2.0 è uno standard basato su XML. Un fornitore di identità (IdP) emette un'asserzione firmata sull'utente e il fornitore di servizi (SP), cioè la tua applicazione, le dà fiducia. Lo scambio avviene tramite redirect del browser e binding POST. È nato prima dell'era mobile, e si vede: SAML è pensato attorno a un browser e a una sessione, non attorno a un'app nativa o a una macchina che chiama un'API.

È anche profondamente radicato. Directory aziendali, sistemi HR e molti prodotti SaaS datati parlano ancora SAML, e i reparti IT delle grandi aziende lo chiedono spesso per nome.

OAuth e SAML a colpo d'occhio

	OAuth 2.0	OIDC	SAML 2.0
Scopo principale	Autorizzazione (accesso alle API)	Autenticazione sopra OAuth	Autenticazione e SSO
Formato dei dati	JSON, token opachi o JWT	JSON, ID token JWT	Asserzioni XML
Client tipici	API, mobile, SPA, servizi	Web, mobile, SPA	Applicazioni web nel browser
Dice chi è l'utente?	Non da solo	Sì	Sì
Adatto a mobile e API	Molto	Molto	Poco
Dove lo incontri	Integrazioni di terze parti	Login moderni, consumer e B2B	SSO aziendale, suite legacy
Impegno di realizzazione	Medio	Medio	Più alto, firma XML e metadati

La riga da tenere a mente è la quarta. OAuth da solo non autentica. SAML e OIDC sì.

Come scegliere: un percorso decisionale

Smetti di chiederti «quale è migliore» e chiediti cosa stai costruendo e chi vi si collega.

1. Vuoi che gli utenti accedano al tuo nuovo prodotto. Usa OIDC. Abbinalo a un fornitore di identità o a una libreria di cui ti fidi, invece di scrivere da zero la gestione dei token.
2. La tua applicazione deve chiamare l'API di qualcun altro per conto degli utenti. Usa OAuth 2.0 con authorization code e PKCE, e chiedi gli ambiti più ristretti possibili.
3. Il reparto IT di un cliente dice «noi usiamo SAML». Offri SAML 2.0 come opzione di SSO aziendale. Molti prodotti B2B partono con OIDC e aggiungono SAML quando lo chiede il primo cliente di grandi dimensioni.
4. Colleghi servizi fra loro senza che ci sia un utente. Usa il client credentials di OAuth 2.0, non SAML.
5. Devi integrarti con un servizio di identità pubblico o federale. Verifica prima cosa supporta e leggi le sue specifiche. Ne parliamo più sotto.

OAuth 2.0 è superato?

No. OAuth 2.0 resta la base dell'autorizzazione moderna per le API, e OAuth 2.1 consolida le buone pratiche invece di sostituire l'idea. Ciò che è superato è una serie di schemi più vecchi: l'implicit flow e il password grant. Se un tutorial ti dice di usarli, cerca un tutorial più recente.

SAML sta morendo?

Non presto. È uno standard maturo che funziona, e sostituirlo dentro le grandi organizzazioni costa caro con pochi benefici visibili. Per i nuovi progetti OIDC è la strada più semplice. Per chi vende alle grandi aziende, il supporto a SAML resta un requisito commerciale, non una curiosità storica.

Un errore di architettura frequente: infilare i permessi nel login

Identità e accesso sono due cose distinte. L'autenticazione dice chi sei. La gestione degli accessi decide cosa puoi fare dentro una determinata applicazione. I team si mettono nei guai quando cercano di far passare ogni ruolo e ogni permesso attraverso il protocollo di identità.

I servizi della Confederazione rendono la separazione esplicita. AGOV, il servizio di autenticazione per le autorità svizzere, fornisce identità e autenticazione via OIDC o SAML, ma non gestisce ruoli né permessi. L'applicazione che si collega deve implementare la propria gestione degli accessi. È una buona impostazione per qualsiasi prodotto: ricevi un'identità verificata, poi mappala su ruoli e permessi nel tuo sistema, dove puoi modificarli senza toccare il fornitore di identità.

Uno schema pratico:

• Prendi un identificatore utente stabile e un piccolo insieme di attributi dall'ID token o dall'asserzione SAML.
• Cerca o crea l'utente nel tuo database.
• Assegna i ruoli localmente, e tieni localmente anche la relativa tracciabilità.
• Tratta le informazioni sui gruppi che arrivano dal fornitore di identità come indicazioni, non come il sistema dei permessi.

Svizzera: cosa cambia per la tua integrazione

Entrambi i protocolli hanno pari dignità

Se sviluppi per il settore pubblico o gli vendi qualcosa, incontrerai i servizi di identità della Confederazione. La documentazione AGOV sulle cloud, SaaS and hyperscaler architectures indica che le applicazioni di destinazione possono collegarsi ad AGOV via OIDC o SAML 2.0, direttamente oppure attraverso un livello di identity and access management già esistente. La stessa pagina descrive il supporto a OIDC con authorization code flow e PKCE. In questo contesto, quindi, la risposta a «OAuth o SAML» è spesso «sono accettati entrambi, scegli quello che il tuo stack e il team IAM del cliente gestiscono meglio».

Non trattarla come una configurazione OIDC o SAML qualsiasi

Supportare uno standard non significa accettarne qualsiasi implementazione. I servizi di identità federali pubblicano i propri requisiti di profilo, le procedure di redirect e le mappature degli attributi. Leggi le specifiche ufficiali di integrazione prima di progettare qualsiasi cosa, e mettici del tempo in preventivo. I team che saltano questo passaggio tendono a scoprire le incompatibilità tardi, quando correggerle significa rifare il lavoro.

La scelta del protocollo non è la questione giuridica

L'Incaricato federale della protezione dei dati e della trasparenza (IFPDT) è chiaro: il trattamento nel cloud è un tema a sé. Nella sua cloud computing guidance, l'IFPDT spiega che un fornitore cloud agisce di norma come responsabile del trattamento per conto del cliente secondo l'art. 9 della legge sulla protezione dei dati, e che la responsabilità resta in capo al cliente. Un handshake SSO sicuro non cambia nulla di tutto questo.

In pratica, se colleghi un prodotto SaaS alle identità dei tuoi utenti, chiediti:

• Quali dati personali arrivano al fornitore una volta che l'utente ha fatto il login, e dove vengono conservati?
• Serve una valutazione d'impatto sulla protezione dei dati? La LPD la prevede quando il trattamento comporta probabilmente un rischio elevato per la persona interessata; il text of the Act on Fedlex è il posto giusto per verificare le condizioni.
• Hai un contratto di trattamento dei dati con il fornitore, e sai se ci sono trasferimenti all'estero?

Queste domande valgono allo stesso modo per SAML e per OIDC. Parla con il tuo responsabile della protezione dei dati o con un avvocato prima di andare in produzione con dati sensibili, in particolare quando il fornitore ha sede negli Stati Uniti.

Meglio standard aperti che login proprietari

Il settore pubblico e quello della formazione in Svizzera si appoggiano sempre più a identità condivise come AGOV o SWITCH edu-ID. Per un prodotto privato la lezione sensata è la stessa: punta su SAML e OIDC invece che su un meccanismo di login proprietario. Gli standard aperti ti lasciano la possibilità di cambiare fornitore di identità in seguito, e tengono contenti i reparti IT dei tuoi clienti.

Trappole pratiche che vediamo nei progetti reali

• Usare gli access token OAuth come prova del login. Se ti serve l'identità, valida un ID token OIDC e controlla emittente, destinatario, firma e scadenza.
• Saltare PKCE. È una protezione a basso costo per i client pubblici come SPA e app mobile, e l'authorization code flow con PKCE è oggi l'indicazione di base.
• Ambiti troppo ampi. Chiedi quello che serve alla funzionalità adesso. Se ne accorgono sia gli utenti sia chi fa le verifiche di sicurezza.
• Validazione SAML debole. Verifica le firme sull'asserzione, controlla le restrizioni sul destinatario e le finestre temporali, e non fidarti mai di asserzioni non firmate. Usa una libreria mantenuta, non un parser XML fatto in casa.
• Metadati che si disallineano. I certificati SAML scadono. Segna la data di rinnovo in agenda o, meglio ancora, monitorala.
• Nessun percorso di uscita. Decidi cosa succede ai dati e alle sessioni di un utente quando il fornitore di identità comunica che non c'è più.
• Mescolare autenticazione e ruoli. Ne abbiamo già parlato sopra, e vale la pena ripeterlo perché è l'errore più costoso da correggere.

Quando il tuo prodotto dialoga con altri sistemi

Il login è solo una parte del quadro. Le integrazioni come caselle di posta, CRM e shop richiedono di solito OAuth per l'accesso delegato oppure token API per gli account di servizio. Per un esempio concreto di come i client automatici ottengono i token e si registrano, guarda questa guida su API tokens and self-registration for automated mailboxes. Qualunque sia il sistema, mantieni la stessa disciplina: token di breve durata, ambiti ristretti e un responsabile chiaro per ogni credenziale.

Cosa significa per una startup o una PMI in Svizzera

Un riassunto breve e senza giri di parole:

• Stai costruendo un nuovo prodotto web o mobile? Parti con OIDC tramite un livello di identità affidabile.
• Vendi ad aziende più grandi o alle autorità? Metti in conto anche SAML 2.0, e progetta il modello utente in modo che fornitore di identità, utente e ruolo restino concetti separati.
• Ti colleghi ad API di terze parti? Usa OAuth 2.0 con PKCE e ambiti ridotti al minimo necessario.
• Tratti dati personali di persone residenti in Svizzera? Documenta quali dati vanno dove, e rispondi alle domande sulla LPD in parallelo al lavoro tecnico, non dopo.

Il costo di sbagliare raramente è una violazione clamorosa. Più spesso è una riscrittura, quando il primo cliente enterprise chiede l'SSO e il tuo modello utente non lo regge.

Come possiamo aiutarti

Siamo un piccolo studio di Zurigo e i nostri ingegneri senior seguono il progetto dalla prima conversazione fino alla consegna. Per il lavoro sull'autenticazione conta parecchio, perché le decisioni iniziali sul modello utente e sulle integrazioni sono costose da ribaltare. Realizziamo siti web, applicazioni web e piattaforme, ci occupiamo di integrazioni di sistema e collegamenti via API e offriamo consulenza tecnica guidata da senior, audit e supporto come CTO a tempo parziale. Se stai decidendo fra SAML, OIDC e OAuth per un prodotto, o vuoi far rivedere un sistema di login esistente, dai un'occhiata ai nostri servizi e piani. Il piano Guidance è indicato a CHF 799 al mese e Run & monitor a CHF 750 al mese; le altre offerte vengono definite per progetto. Puoi anche vedere i nostri lavori per farti un'idea del tipo di sistemi che consegniamo.

Domande frequenti

Qual è la differenza principale fra OAuth e SAML?

OAuth 2.0 è un framework di autorizzazione: permette a un'applicazione di accedere a un'API con permessi limitati. SAML 2.0 è uno standard di autenticazione che fa accedere gli utenti alle applicazioni tramite un fornitore di identità. Si sovrappongono solo in parte, ed è per questo che OIDC, costruito su OAuth, è il vero corrispettivo di SAML per il login.

Per una nuova applicazione meglio SAML o OIDC?

Per la maggior parte dei nuovi prodotti OIDC è la scelta più semplice, perché funziona bene su web, mobile e API e usa JSON. Aggiungi SAML quando l'ambiente IT di un cliente lo richiede. Se vendi soprattutto a grandi organizzazioni, metti SAML in conto fin dall'inizio.

OAuth si occupa dell'autenticazione?

Non da solo. Un access token OAuth dice che un'applicazione può fare qualcosa, non chi è l'utente. Per l'autenticazione usa OpenID Connect, che aggiunge un ID token firmato.

I servizi pubblici svizzeri supportano entrambi i protocolli?

Sì. AGOV documenta OIDC e SAML 2.0 come modalità supportate per collegare le applicazioni. Fornisce l'autenticazione, ma non ruoli né permessi: la gestione degli accessi resta a carico della tua applicazione. Leggi le specifiche ufficiali di integrazione prima di iniziare a sviluppare.

Con l'SSO la mia configurazione cloud è conforme alla LPD?

No. Il protocollo di login è una scelta tecnica, mentre la LPD riguarda come vengono trattati i dati personali e chi ne è responsabile. Le indicazioni sul cloud dell'Incaricato della protezione dei dati dicono che la responsabilità resta al cliente quando un fornitore tratta dati per suo conto: valuta quindi il rischio e metti in piedi i contratti giusti.

Fonti

• One practical comparison
• OAuth 2.1 draft
• cloud, SaaS and hyperscaler architectures
• AGOV
• cloud computing guidance
• text of the Act on Fedlex