16 nov 2025·8 min
OAuth vs SAML per SSO: cosa si aspettano le aziende
OAuth vs SAML per SSO spiegati in termini semplici, cosa chiedono le aziende, cosa sviluppare e come mantenere funzionante il login attuale.
OAuth vs SAML per SSO spiegati in termini semplici, cosa chiedono le aziende, cosa sviluppare e come mantenere funzionante il login attuale.
L'SSO diventa urgente nel momento in cui un accordo passa da una "prova di team" a un rollout aziendale. Un acquirente può amare il tuo prodotto, ma sicurezza e IT rallenteranno l'acquisto se i dipendenti devono creare nuove password, gestire MFA in un altro posto o perdere account quando le persone cambiano ruolo.
Per molte aziende, l'SSO è meno una questione di comodità e più di controllo. Vogliono un punto unico per applicare regole di accesso, revocare rapidamente i permessi e mostrare agli auditor che l'identità è gestita centralmente. Ecco perché la domanda "OAuth vs SAML per SSO" arriva spesso in fase avanzata della vendita: è un modo rapido per verificare se ti integri nel loro setup di identity.
Aggiungere l'SSO in ritardo può rompere ipotesi su cui già fai affidamento. Se il tuo modello attuale è "one email = one user", l'SSO introduce casi limite come alias condivisi, più identity provider o utenti che devono mantenere sia il login con password sia l'SSO durante una migrazione. Se il linking degli account è sbagliato, le persone possono perdere l'accesso o, peggio, ottenere accesso al tenant sbagliato.
L'SSO cambia anche onboarding e supporto. Se fatto bene, riduce reset di password e ticket "chi è il proprietario di questo account?". Se fatto male, i rollout si bloccano, gli admin si arrabbiano e i rinnovi diventano rischiosi perché il prodotto "funzionava in prova" ma fallisce al primo giorno di deployment aziendale.
La decisione raramente spetta a una sola persona. L'acquirente vuole momentum, il team sicurezza e audit chiede garanzie, gli admin IT vogliono passi chiari per la configurazione, gli utenti finali desiderano un login fluido e il supporto si ritrova a gestire lockout, migrazioni ed eccezioni.
Se costruisci app su piattaforme come Koder.ai, conviene pianificare l'SSO presto per evitare di dover riprogettare l'identità dopo che i clienti sono già attivi.
SSO (single sign-on) significa che il cliente effettua l'accesso alla tua app usando il login aziendale, non una password separata che tu memorizzi. Accedono con l'account di lavoro e l'accesso è controllato dalle policy aziendali.
Questi sono i termini che sentirai nelle call enterprise:
Quando si parla di "OAuth login" spesso si intende OpenID Connect (OIDC). OAuth riguarda principalmente l'autorizzazione (permettere a qualcosa di accedere), mentre OIDC aggiunge l'autenticazione (chi è l'utente), quindi può essere usato per il login.
SAML è uno standard SSO più vecchio, basato su XML. Le aziende lo usano ancora molto perché è collaudato, ampiamente supportato dagli IdP e presente in molte checklist di compliance.
SCIM non è SSO. SCIM serve per il provisioning: creare, aggiornare e disattivare utenti (a volte gruppi) automaticamente. Una configurazione comune è usare SAML o OIDC per il sign-in e SCIM per aggiungere/rimuovere accessi senza intervento manuale.
Gli acquirenti aziendali di solito non partono dai dettagli del protocollo. Partono da rischio e controllo: "Possiamo gestire gli accessi dal nostro identity provider e dimostrare chi ha fatto cosa?"
La maggior parte dei team enterprise vuole almeno un'opzione enterprise-friendly, e molti ne vogliono entrambe:
Chiederanno anche come funziona la configurazione: metadata o discovery URL, rotazione dei certificati e se l'IT può auto-servirsi senza aspettare i tuoi ingegneri.
Il modo più rapido per perdere un deal enterprise è essere vaghi sull'offboarding. Chiederanno cosa succede quando un dipendente va via, cambia reparto o perde un laptop.
Aspettati domande come:
Uno scenario semplice che li interessa: un admin disabilita un utente alle 9:02, e entro le 9:03 quell'utente non dovrebbe più poter aprire l'app, anche se ha ancora una scheda del browser aperta. Se non riesci a spiegare chiaramente quel flusso, prepara cicli di revisione extra.
OAuth è stato creato per accesso delegato: permettere a un sistema di chiamare le API di un altro senza condividere la password. Molti team lo usano ancora per questo (per esempio, un'integrazione che legge calendari). Per il login dei dipendenti, la maggior parte dei prodotti usa OpenID Connect (OIDC), che si appoggia a OAuth e aggiunge un modo standard per provare l'identità dell'utente.
Con OIDC, lo schema comune è l'authorization code flow. La tua app manda l'utente all'IdP dell'azienda per il login. Dopo l'accesso riuscito, l'IdP restituisce alla tua app un codice di autorizzazione a breve durata. Il tuo backend scambia quel codice con i token.
La separazione di token che conta:
Un modo pratico di pensare a OAuth vs SAML per SSO: OIDC è ottimo quando vuoi un login moderno che funzioni su web, mobile e API. SAML è più comune quando l'azienda vuole l'handshake classico "sign in to the app" e si preoccupa meno dell'accesso API.
Quello che dovresti memorizzare resta semplice: l'identificatore stabile dell'utente (subject), la loro email (se fornita) e la connessione tenant usata. Non memorizzare la password dell'utente. Evita anche refresh token a lunga durata a meno che non servano davvero per accesso offline.
Per far funzionare questo per tenant:
Se fatto bene, gli utenti ritornano nella tua app, convalidi i token e crei la sessione normale senza riscrivere tutto il modello di auth.
SAML permette all'IdP aziendale di dire alla tua app: "questa persona ha già effettuato l'accesso, ecco i suoi dati." L'IdP invia una SAML assertion, che è una nota firmata che include chi è l'utente (e talvolta gruppi o ruoli) più una finestra di validità breve.
Per rendere quella nota affidabile, SAML si basa su metadata e certificati. I metadata sono un pacchetto di configurazione che descrive endpoint e chiavi. I certificati sono usati principalmente per la firma, così la tua app può confermare che l'asserzione proviene dall'IdP del cliente e non è stata modificata.
Due identificatori compaiono quasi sempre:
Se uno dei due è sbagliato, il login fallisce anche se tutto il resto sembra corretto.
Il SAML reale è tanto operazioni quanto codice. Pianifica impostazioni a livello di tenant, rotazione dei certificati senza downtime, clock skew (anche pochi minuti possono rompere le asserzioni) ed errori chiari per gli admin (non solo "invalid response").
Un pattern comune: l'admin del cliente abilita SAML per tenant, la tua app verifica la firma, controlla che l'asserzione non sia scaduta e mappa l'email (o il NameID) a un utente esistente o a una regola sicura di auto-provisioning. In pratica, questo è il cuore della decisione OAuth vs SAML: SAML di solito ti costringe a costruire workflow amministrativi più solidi.
Scegliere tra OIDC e SAML dipende soprattutto da cosa usa già il tuo buyer. Molte app B2B finiscono per supportare entrambi nel tempo, ma puoi comunque prendere una decisione pulita per cliente e mantenere il sistema di auth prevedibile.
OIDC è spesso più fluido per app moderne. Si adatta a web e mobile, funziona bene con le API ed è generalmente più semplice da debuggare ed estendere (scopes, durate dei token, ecc.). Se il cliente enterprise usa già un IdP moderno e il suo IT è a proprio agio con OIDC, inizia da lì.
SAML può essere non negoziabile. Molte grandi aziende hanno programmi SAML esistenti e regole di onboarding vendor come "solo SAML". In quei casi, l'approccio migliore è implementare SAML una volta in modo controllato e tenerlo isolato dal resto del sistema di login.
Domande da porre prima di impegnarti:
Una guida rapida alla decisione:
| Se il cliente dice... | Preferisci | Perché |
|---|---|---|
| "Usiamo Entra ID e vogliamo un'integrazione moderna" | OIDC | Migliore per flussi web e API |
| "La nostra policy è solo SAML per i vendor" | SAML | Necessario per superare l'onboarding di sicurezza |
| "Abbiamo bisogno di entrambi per diverse sussidiarie" | Entrambi | Comune in organizzazioni grandi |
| "Ci servono claim personalizzati per app" | Entrambi | Entrambi supportano mapping di attributi |
Se supporti entrambi, mantieni il resto dell'app coerente: un modello utente interno, un modello di sessione e un set di regole di autorizzazione. Il metodo SSO dovrebbe rispondere a "chi è questo utente e a quale tenant appartiene" senza riscrivere come funziona l'accesso.
Inizia definendo cosa significa "tenant" nel tuo prodotto. Per la maggior parte delle app B2B, l'SSO si configura per organizzazione o workspace, non per singolo utente. Questa scelta determina dove conservi le impostazioni IdP, chi può cambiarle e come gli utenti si spostano tra workspace.
Poi scegli un comportamento di login prevedibile. L'instradamento per dominio (digiti l'email e poi vieni reindirizzato se il dominio è SSO-enabled) riduce la confusione, ma devi gestire casi limite come contractor e aziende multi-dominio. Un semplice pulsante "Continua con SSO" è più facile da capire, ma gli utenti possono scegliere l'opzione sbagliata.
Un ordine di costruzione sicuro per OIDC o SAML:
I test non sono opzionali. Usa un IdP sandbox e un tenant di staging con domini realistici. Esegui casi positivi e negativi: certificato scaduto, audience sbagliata, clock skew, utente rimosso dall'IdP. Tratta il rollout SSO come un feature flag.
Piattaforme come Koder.ai rendono questo tipo di iterazione più semplice supportando snapshot e rollback insieme alla configurazione per tenant, così un cambiamento sbagliato non blocca tutti i clienti contemporaneamente.
L'SSO non è solo un pulsante di login. I team di sicurezza chiederanno della durata delle sessioni, dell'offboarding e di cosa puoi dimostrare se qualcosa va storto. Se tratti l'SSO come parte centrale del sistema di auth (non un bolt-on), eviti la maggior parte delle escalation dolorose.
Inizia con le regole di sessione. Scegli un timeout di inattività e una durata massima assoluta della sessione, e sii esplicito su cosa succede quando qualcuno chiude il laptop e torna il giorno dopo. Con OIDC, i refresh token possono mantenere le sessioni più a lungo del previsto, quindi imposta limiti (rotazione, età massima) se li usi. Con SAML, le sessioni del browser possono durare a lungo a meno che tu non forzi una ri-autenticazione.
Il logout è un altro scoglio. Il "single logout" non è universale. Supporta il logout locale in modo affidabile e documenta che il logout globale dipende dall'IdP.
L'MFA è simile. Le aziende vogliono che l'IdP gestisca l'MFA, quindi la tua app dovrebbe accettare un utente autenticato senza chiedere di nuovo. È comunque utile supportare step-up per azioni rischiose (esportazioni di dati o modifiche di fatturazione), perché non tutte le policy IdP sono perfette.
Il provisioning utente è dove avvengono le fughe di accesso. Il provisioning JIT è comodo, ma può creare account per chiunque si autentichi. Invite-only è più sicuro ma aggiunge lavoro admin. Molte squadre trovano un compromesso: JIT consentito ma limitato da domini autorizzati e (opzionalmente) claim di gruppo.
Mantieni la configurazione SSO dietro ruoli con privilegio minimo. Nessuno dovrebbe aver bisogno di diritti super-admin solo per ruotare un certificato o aggiornare un URL IdP.
Per il supporto, registra abbastanza informazioni per tracciare un singolo login senza memorizzare segreti:
Questa è la differenza tra "non riusciamo a riprodurlo" e risolvere un outage SSO enterprise in pochi minuti.
Una società mid-market arriva a procurement e dice: "Ci serve l'SSO prima di firmare." Questo raramente è filosofico. È un controllo necessario per onboarding, offboarding e audit.
La parte interessante: stai vendendo a due team. Il Team A è soddisfatto di OIDC perché usa Okta con app moderne. Il Team B insiste su SAML perché i loro strumenti legacy lo richiedono. Qui la domanda OAuth vs SAML smette di essere un dibattito e diventa un piano di rollout.
Mantieni una regola: l'SSO è un'opzione di login per tenant, non una sostituzione globale. Gli utenti esistenti possono continuare a entrare nel modo precedente finché l'admin del tenant non attiva "SSO required."
Al primo login SSO serve un linking account sicuro. Un approccio pulito è: match sull'email verificata, conferma del tenant per dominio (o tramite invito), poi associa l'identità IdP all'account esistente. Se non c'è corrispondenza, crea l'utente just-in-time solo se l'admin lo ha permesso.
L'assegnazione dei ruoli è dove i deal spesso si inceppano. Mantieni semplice: un ruolo di default per i nuovi utenti e mapping opzionale da gruppi/claim IdP ai ruoli della tua app.
Dal lato admin, di solito devono configurare:
Per evitare lockout durante il cambio, mantieni un account admin break-glass fuori dall'SSO, esegui una modalità test per i primi login e applica l'SSO obbligatorio solo dopo almeno una sessione admin di conferma funzionante.
La maggior parte degli incidenti SSO non dipende dall'IdP. Succede perché la tua app tratta l'SSO come un interruttore globale anziché una impostazione per cliente.
Un fallimento classico è dimenticare i confini tenant. Una nuova configurazione IdP viene salvata globalmente e improvvisamente ogni cliente viene reindirizzato all'ultimo IdP configurato. Conserva le impostazioni IdP legate al tenant e risolvi sempre il tenant prima di iniziare la handshake SSO.
Il matching degli account è un'altra trappola. Se ti basi solo sull'email creerai utenti duplicati o bloccherai utenti reali quando l'email nell'IdP differisce da quella usata prima dell'SSO. Definisci la politica di merge: quali identificatori fidarti, come gestire i cambi email e come gli admin possono correggere mismatch senza intervento degli ingegneri.
I team tendono anche a sovra-affidarsi ai claim. Valida sempre ciò che ricevi: issuer, audience, firma e che l'email sia verificata (o usa un identificatore stabile). Accettare un'audience sbagliata o un'email non verificata è un modo semplice per concedere accesso alla persona sbagliata.
Quando qualcosa fallisce, errori vaghi generano chiamate di supporto lunghe. Dai agli utenti un messaggio chiaro e agli admin un suggerimento diagnostico (esempio: "Audience mismatch" o "Certificate expired") senza esporre segreti.
I problemi di tempo meritano test prima della messa in produzione. Clock skew e rotazione dei certificati rompono i login di lunedì mattina.
Cinque controlli che prevengono la maggior parte degli outage:
L'SSO è dove piccole assunzioni diventano grandi ticket di supporto. Prima di dire a un cliente enterprise che lo supporti, assicurati che le basi funzionino nel prodotto, non solo nella demo.
Esegui questi test in un ambiente di staging che rispecchi la produzione:
Esegui una simulazione di "giornata nera": ruota un certificato, cambia un claim o interrompi l'URL IdP e conferma di poter rilevare e risolvere rapidamente il problema.
Poi assicurati di avere monitoring e alert per i fallimenti SSO (per tenant) e un piano di rollback (feature flag, revert di config o deploy rapido) che hai già provato.
Scegli un punto di partenza chiaro. La maggior parte degli acquirenti enterprise chiede "SAML con Okta/Entra ID" o "OIDC con Google/Microsoft", e non vuoi promettere entrambe alla prima release a meno che non abbia il team per farlo. Decidi cosa supporterai per primo (SAML, OIDC o entrambi) e scrivi cosa significa "done" per prodotto e supporto.
Prima di coinvolgere un cliente reale, crea un piccolo tenant demo interno. Usalo per provare il flusso completo: abilita SSO, testa il login, limita al dominio e recupera l'accesso quando qualcosa va storto. Qui si testa anche il playbook di supporto.
Mantieni un documento di requisiti enterprise vivo. Le revisioni cambiano nel tempo e avere un posto dove tracciare cosa supporti evita promesse fatte una tantum che poi rompono l'onboarding.
Un piano semplice e pratico:
Se vuoi muoverti velocemente sul prodotto, puoi prototipare le schermate di impostazioni e la struttura tenant in Koder.ai (koder.ai) e iterare man mano che arrivano i questionari di sicurezza dei clienti.
Prevedi gli addon che normalmente seguono subito dopo l'SSO: provisioning SCIM, esportazioni dei log di audit e ruoli admin con permessi chiari. Anche se non li rilasci subito, i buyer li chiederanno e la tua risposta dovrebbe essere coerente.
La maggior parte dei team aziendali vuole un controllo centralizzato degli accessi. L'SSO consente loro di applicare MFA e regole di accesso nell'Identity Provider, revocare l'accesso rapidamente quando qualcuno lascia l'azienda e soddisfare i requisiti di audit senza affidarsi alla gestione delle password da parte della tua app.
Inizia da ciò che il loro Identity Provider già supporta e da cosa richiede la loro policy di vendor onboarding. OIDC è spesso l'opzione più fluida per flussi moderni web e mobile, mentre SAML è frequentemente obbligatorio in aziende grandi perché è ampiamente standardizzato nelle procedure esistenti.
OIDC è uno strato di autenticazione costruito sopra OAuth progettato per il login. OAuth da solo riguarda soprattutto l'autorizzazione ad accesso a API, non la dimostrazione dell'identità. Se implementi "Sign in with the company IdP" probabilmente intendi OIDC piuttosto che OAuth grezzo.
No. L'SSO riguarda il modo in cui gli utenti effettuano il login, mentre SCIM serve per creare, aggiornare e disabilitare automaticamente gli account utente (e talvolta i gruppi). Una configurazione comune è usare SAML o OIDC per il login e SCIM per automatizzare offboarding e modifiche di ruolo senza intervento manuale.
Tratta l'SSO come una configurazione per singolo tenant, non come un'impostazione globale. Risolvi prima il tenant (tramite instradamento per dominio, invito o selezione esplicita dell'organizzazione) e poi avvia la procedura SSO usando la configurazione IdP di quel tenant. Così eviti che le impostazioni di un cliente influenzino gli altri.
Usa un identificatore stabile fornito dall'IdP (come l'sub di OIDC o un SAML NameID) come collegamento principale, e considera l'email come attributo secondario che può cambiare. Al primo login SSO collega l'account esistente solo quando sei sicuro sia la stessa persona e il tenant sia corretto; altrimenti richiedi un invito o la conferma di un admin.
Mantieni un account amministratore break-glass che possa autenticarsi senza SSO e rendi l'SSO opzionale finché un amministratore non verifica che funzioni. Fornisci inoltre un singolo toggle per disabilitare l'SSO per quel tenant in modo che il supporto possa ripristinare l'accesso rapidamente senza intervenire sul codice.
Supporta il logout locale in modo affidabile nell'app e documenta che il logout globale dipende dalle funzionalità e dalla configurazione dell'IdP del cliente. Pianifica anche la revoca rapida degli accessi: scadenze di sessione o controlli che impediscano a un utente disabilitato di continuare a usare l'app da una vecchia scheda del browser.
Conserva log focalizzati sul tenant che aiutino a identificare il problema senza memorizzare segreti. Registra un correlation ID, il tenant, l'issuer/entity ID, timestamp e un motivo chiaro come signature failure, audience mismatch o certificato scaduto. Evita di memorizzare token grezzi, intere asserzioni SAML, client secret o chiavi private nei log.
Ti servono: archiviazione della configurazione a livello di tenant, un'interfaccia admin per gestire le impostazioni IdP, regole sicure per l'account-linking e una procedura di rollback. Se costruisci su Koder.ai, pianifica il modello tenant fin dall'inizio e usa snapshot e rollback durante il rollout così un cambiamento sbagliato non blocca tutti i clienti.