--- term: 'Single Sign-On (SSO)' seoTitle: 'Single Sign-On (SSO): come funziona, SAML vs. OIDC' headline: 'Che cos''è il Single Sign-On (SSO)?' slug: single-sign-on-sso category: auth-security shortDefinition: 'Il single sign-on è un metodo di autenticazione in cui un solo accesso presso un identity provider apre molte applicazioni indipendenti.' relatedTerms: - identity-access-management-iam - oauth-2-social-login - multi-factor-authentication-mfa - session-management contrastsWith: - oauth-2-social-login aboutTerms: - 'Identity Provider (IdP)' - 'Service Provider (SP)' - 'SAML' - 'Single Logout (SLO)' faq: - question: 'Che cos''è l''SSO, in parole semplici?' answer: 'Un solo accesso sblocca molte app: l''identità viene provata una volta sola a un identity provider centrale, e ogni applicazione collegata si fida di quella prova invece di chiedere una password propria. L''accesso del mattino al portale aziendale che apre in silenzio posta, wiki e CRM è l''SSO al lavoro.' - question: 'Come funziona l''SSO?' answer: 'Con redirect e token firmati. L''app manda un utente non autenticato all''identity provider; là l''utente si autentica – password più MFA – e l''IdP emette un''assertion firmata digitalmente che il browser riporta indietro; l''app valida la firma contro certificati scambiati in anticipo e avvia una sessione. L''app successiva salta l''accesso perché la sessione dell''IdP esiste già.' - question: 'L''SSO è sicuro?' answer: 'Il bilancio è positivo quando l''identity provider impone la MFA: esistono meno password da sottoporre a phishing, e politiche, verificabilità e blocco degli account vivono in un unico posto. Il prezzo onesto è la concentrazione: un solo account IdP compromesso, o l''IdP stesso, apre tutto quello che sta a valle. L''SSO rende la porta d''ingresso eccellente e unica.' - question: 'Qual è la differenza tra SSO e gestore di password?' answer: 'Un gestore di password conserva molti segreti e li compila automaticamente: ogni app continua a far girare il proprio accesso. L''SSO elimina del tutto le password per singola app: le app delegano l''autenticazione all''IdP e non detengono alcuna credenziale. I due si completano a vicenda; i gestori coprono la coda lunga delle app senza supporto SSO.' - question: 'Il login social è la stessa cosa dell''SSO?' answer: 'Stesso macchinario, padrone di casa diverso. Entrambi sono flussi di redirect in stile OIDC verso un identity provider – ma il login social usa l''IdP di una piattaforma consumer per accedere a una singola app, mentre l''SSO aziendale usa un IdP controllato dall''organizzazione, la cui sessione unica abbraccia un''intera suite di applicazioni.' - question: 'SAML o OIDC per l''SSO?' answer: 'OIDC per tutto ciò che è nuovo: JSON e JWT su REST, amichevole verso mobile e SPA, più facile da implementare e da analizzare. SAML per compatibilità: il protocollo dell''era XML radicato negli identity provider aziendali. I prodotti che vendono alle imprese finiscono di solito per parlare entrambi.' - question: 'Con l''SSO serve ancora la MFA?' answer: 'Assolutamente sì – l''SSO rende quel singolo accesso più prezioso, non meno. La virtù compensativa: imporre la MFA presso l''identity provider protegge ogni applicazione collegata con una sola mossa, che è esattamente la centralizzazione per cui l''SSO esiste.' - question: 'Che cosa succede quando l''identity provider è fuori servizio?' answer: 'Nessuno avvia una sessione nuova in alcuna app collegata, mentre le sessioni applicative esistenti sopravvivono fino alla scadenza. È il volto di disponibilità del single point of failure, e la ragione per cui ridondanza dell''IdP, account amministrativi di emergenza e percorsi alternativi appartengono al piano di rollout, non al postmortem.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'SAML 2.0 Technical Overview — OASIS' url: 'https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html' - name: 'OpenID Connect Core 1.0' url: 'https://openid.net/specs/openid-connect-core-1_0.html' - name: 'NIST SP 800-63C — Federation and Assertions' url: 'https://pages.nist.gov/800-63-4/sp800-63c.html' - name: 'RFC 6749 — The OAuth 2.0 Authorization Framework' url: 'https://datatracker.ietf.org/doc/html/rfc6749' cta: title: 'L''accesso aziendale, a un adattatore di distanza' text: 'Punta gli adattatori di autenticazione di Back4app verso l''identity provider del tuo cliente – Keycloak, LDAP o qualunque emittente OIDC – e Back4app verifica i suoi token lato server, mappa le identità sui tuoi utenti ed emette le sessioni della tua app.' linkText: 'Inizia gratis' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-06' translationKey: single-sign-on-sso --- **Il single sign-on è un metodo di autenticazione in cui un solo accesso presso un identity provider apre molte applicazioni indipendenti.** In scena ci sono due ruoli: l'**identity provider (IdP)** autentica gli utenti e garantisce per loro; ogni **service provider (SP)** – le app che si vogliono davvero usare – si fida di quella garanzia invece di far girare un accesso proprio. Vale la pena tenere una distinzione pedante: le app che condividono una directory ma chiedono ciascuna la password fanno *same* sign-on; il vero SSO significa che la domanda arriva una volta sola. ## Punti chiave | Domanda | Risposta | | --- | --- | | Chi è in scena | L'IdP autentica e garantisce · gli SP si fidano della garanzia | | Il meccanismo | Redirect + assertion firmate – la password non lascia mai l'IdP | | I protocolli | SAML (XML, legacy aziendale) · OIDC (JWT su OAuth, lo standard moderno) | | Il prezzo | Una porta d'ingresso eccellente – e una sola porta che vale tutto ciò che custodisce | | Le clausole in piccolo | Il single logout è difficile · le sessioni corrono su più orologi · nel SaaS l'SSO costa extra | ## La danza dei redirect, passo per passo Perché proprio i redirect? Per la same-origin policy del browser: `app.example.com` non può leggere un cookie di accesso di `idp.example.org`, quindi l'identità deve viaggiare *come messaggio firmato attraverso il browser* invece che come cookie condiviso – che è esattamente quello che fa il flusso: ```text 1 L'utente apre app.example.com – nessuna sessione 2 L'SP reindirizza all'IdP con una richiesta di autenticazione 3 L'utente si autentica PRESSO L'IDP (password + MFA) – oppure ha già una sessione IdP, e questo passo viene saltato in silenzio 4 L'IdP emette un'assertion firmata (XML SAML) o un ID token (JWT OIDC) 5 Il browser la consegna all'URL di callback dell'SP 6 L'SP valida: firma · emittente · audience · scadenza · replay 7 L'SP avvia la propria sessione locale – l'utente è dentro 8 App successiva: passi 1–2, poi dritti dal percorso silenzioso di 3 al 7 ``` Ecco che aspetto ha il lato service provider quando un backend lo avvolge: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: const user = await Parse.User.logInWith('keycloak', { authData: { id: subClaim, // the IdP's stable subject ID access_token: accessToken, // verified server-side against the IdP }, }); // One IdP login now serves every app that trusts the same issuer. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: final user = ParseUser.forQuery(); final response = await user.loginWith('keycloak', { 'id': subClaim, // the IdP's stable subject ID 'access_token': accessToken, // verified server-side against the IdP }); // One IdP login now serves every app that trusts the same issuer. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: let user = try await User.loginWith( "keycloak", authData: [ "id": subClaim, // the IdP's stable subject ID "access_token": accessToken // verified server-side against the IdP ] ) // One IdP login now serves every app that trusts the same issuer. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Enterprise SSO: the IdP authenticates; the app trusts its signed token // After the OIDC redirect dance, the client holds the IdP's tokens: val authData = mapOf( "id" to subClaim, // the IdP's stable subject ID "access_token" to accessToken // verified server-side against the IdP ) ParseUser.logInWithInBackground("keycloak", authData).continueWith { task -> val user = task.result // One IdP login now serves every app that trusts the same issuer. } ``` ```mermaid flowchart LR accTitle: Flusso di single sign-on fra i service provider e l'identity provider accDescr: Un utente non autenticato presso un service provider viene reindirizzato all'identity provider, si autentica una volta con la MFA e riceve un'assertion firmata che viene riconsegnata al service provider, il quale la valida e avvia una sessione locale. Una seconda applicazione ripete il redirect, ma la sessione esistente presso l'identity provider rende l'accesso silenzioso. U["Utente"] --> SP1["App A (SP)
nessuna sessione"] SP1 -->|"redirect + richiesta di auth"| IDP["Identity provider
accesso + MFA · sessione globale"] IDP -->|"assertion firmata"| SP1 SP1 -->|"valida → sessione locale"| OK1["App A aperta"] U2["Stesso utente, più tardi"] --> SP2["App B (SP)"] SP2 -->|"redirect"| IDP IDP -.->|"la sessione esiste –
assertion silenziosa"| SP2 --> OK2["App B aperta,
nessun accesso mostrato"] ``` ## SP-initiated vs. IdP-initiated | | SP-initiated | IdP-initiated | | --- | --- | --- | | Parte da | L'app ("Accedi con SSO") | La tessera nella dashboard dell'IdP | | Richiesta | L'SP emette una richiesta di autenticazione | Nessuna – l'assertion arriva non sollecitata | | Legame con la risposta | L'assertion risponde a una richiesta precisa | Nessuna richiesta con cui confrontarla | | Postura di sicurezza | Il caso predefinito – i controlli anti-replay si ancorano alla richiesta | Storicamente più debole; le assertion non sollecitate invitano all'iniezione | | Supportarlo? | Sempre | Solo dove l'IdP lo richiede, con validazione aggiuntiva | La maggior parte delle spiegazioni descrive solo il primo e non nomina mai il secondo – eppure gli IdP aziendali adorano le tessere nella dashboard, quindi gli SP incontrano entrambi. Il [documento tecnico su SAML](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) specifica i due profili; la regola pratica sta nell'ultima riga della tabella. ## SAML vs. OIDC | | SAML 2.0 | OpenID Connect | | --- | --- | --- | | Epoca e formato | 2005 · assertion XML | 2014 · [JWT](/glossary/it/json-web-token-jwt/) su [OAuth 2.0](/glossary/it/oauth-2-login-social/) | | Trasporto | Binding POST/redirect del browser | REST + redirect | | Si adatta a | App web aziendali, IdP legacy | Mobile, SPA, API – tutto ciò che è attuale | | Esperienza di sviluppo | Verboso, fragile, dipendente dalle librerie | Token leggibili, flussi standard | | Verdetto | Supportarlo perché gli IdP dei clienti lo parlano | Sceglierlo per tutto ciò che è nuovo | E il triangolo che districa gli acronimi, una volta per tutte: **SAML e OIDC fanno autenticazione per l'SSO; [OAuth 2.0 da solo è autorizzazione](/glossary/it/autenticazione-vs-autorizzazione/)** – OIDC è lo strato di identità che ha reso sicuro accedere tramite l'impianto di OAuth. Il login social è lo stesso macchinario OIDC con una piattaforma consumer nel ruolo di IdP e una singola app come destinataria; l'SSO aziendale cambia il padrone di casa e allarga la sessione a un'intera suite. ## Le parti di cui nessuno parla **Il single logout (SLO) è la metà difficile.** L'accesso converge *verso* un unico IdP; la disconnessione deve diramarsi *verso* ogni SP che detiene una sessione locale – e la catena si rompe se un'app non risponde, le restrizioni dei browser sui cookie di terze parti rompono le notifiche sul canale frontale, e niente raggiunge gli altri dispositivi. In pratica, "disconnesso da tutto" significa sessioni locali brevi che ricontrollano la sessione IdP (terminata), non una diffusione affidabile. **Le sessioni corrono su tre orologi:** la sessione globale dell'IdP, la [sessione](/glossary/it/gestione-delle-sessioni/) locale di ogni app e la finestra di validità dell'assertion stessa. Disconnettersi da un'app mentre la sessione dell'IdP vive significa rientro silenzioso alla visita successiva – un comportamento che gli utenti segnalano come bug e che chi progetta dovrebbe riconoscere come il disegno previsto. **E poi c'è la tassa SSO:** i fornitori SaaS mettono di routine il supporto SAML/SSO dietro i piani enterprise, a multipli del prezzo base – un fatto di mercato da mettere in bilancio, perché il requisito del team di sicurezza e la voce di spesa arrivano insieme. ## Il raggio d'impatto, onestamente L'SSO concentra il rischio di proposito: è questo che significa "single". Un solo account IdP compromesso apre ogni app collegata; un IdP compromesso *in sé* – incluso il furto delle sue chiavi di firma delle assertion, lo schema d'attacco della "golden assertion" – conia identità valide per chiunque, ovunque. I fornitori ammorbidiscono la cosa; la risposta ingegneristica è spendere bene quella concentrazione: **[MFA](/glossary/it/autenticazione-multifattore-mfa/) resistente al phishing presso l'IdP** (quel singolo accesso vale ormai una protezione di livello passkey), **autenticazione step-up** per le app sensibili invece di una sessione unica e indifferenziata, **sessioni globali brevi** dove la posta in gioco è alta, rotazione e monitoring delle chiavi di firma, e account locali di emergenza per il giorno in cui l'IdP non risponde. Il single point of failure non scompare mai: viene corazzato, perché corazzare un unico punto è esattamente l'economia che l'SSO prometteva. ## Integrarsi come service provider Che cosa richiede davvero a un team applicativo la frase "supportiamo l'SSO", in un unico elenco: registrare presso l'IdP la propria URL di callback o ACS e scambiare i metadati (emittente, certificati); validare tutto su ogni assertion – firma, emittente, audience, scadenza e legame anti-replay; mappare i claim dell'IdP sul proprio modello utente, ancorandosi al subject ID stabile e mai alla sola e-mail; fare provisioning just-in-time (il primo accesso SSO crea l'utente locale); gestire in modo deliberato gli arrivi IdP-initiated; e mettere alla prova le aspettative sulla disconnessione contro la realtà dei tre orologi descritta sopra. È un percorso ben battuto – ed è per questo che esistono IdP open source come Keycloak per l'altro lato dell'handshake – ma ogni voce saltata è un rilievo di sicurezza con una data attaccata. ## Casi d'uso tipici - **Suite di app per il personale** – il caso canonico: un solo accesso al mattino, poi ogni strumento interno e SaaS. - **SaaS B2B che sale di fascia** – "supporta l'SSO" come casella che sblocca la trattativa enterprise. - **Istruzione e sanità** – accesso federato fra istituzioni, dove le radici di SAML sono più profonde. - **MFA e offboarding centralizzati** – un solo posto in cui imporre i fattori; un solo interruttore che chiude ovunque l'accesso di chi ha lasciato l'azienda. - **Prodotti multi-app** – una suite propria che condivide un unico accesso tramite un IdP proprio, in stile consumer. ## Conviene aggiungere l'SSO? Matrice decisionale | Situazione | Orientamento | | --- | --- | | Vendita alle imprese | Sì – OIDC + SAML; sblocca le trattative | | Strumenti interni dietro un solo IdP aziendale | Sì – centralizzare MFA e offboarding | | App consumer | [Login social](/glossary/it/oauth-2-login-social/) – stesso macchinario, IdP consumer | | Una sola app, team piccolo | Sessioni + MFA bastano; da rivedere alla terza app | | App ad alta garanzia dietro l'SSO | Aggiungere l'autenticazione step-up – non cavalcare la sessione indifferenziata | | Scelta del protocollo oggi | Prima OIDC; SAML per i clienti che lo esigono | ## Limiti e trade-off - **La disponibilità si concentra insieme all'identità.** L'indisponibilità dell'IdP è l'interruzione dell'accesso per tutti; ridondanza e percorsi di emergenza fanno parte della feature, non sono aggiunte. - **La disconnessione è più debole dell'accesso.** La diramazione dello SLO fallisce in parte per costruzione; sono le sessioni locali brevi, non la diffusione del logout, a dare la garanzia reale. - **La coda lunga resta con le password.** Le app senza supporto SSO conservano le proprie credenziali – i gestori di password restano lo strato di pulizia. - **La stratificazione delle sessioni confonde gli utenti.** Il rientro silenzioso e i ticket "mi sono disconnesso ma no" sono il conto UX del disegno a tre orologi; documentazione e timeout prevedibili lo ripagano. - **La qualità dell'integrazione varia da SP a SP.** Il tetto di sicurezza dell'SSO lo fissa la validazione delle assertion più sciatta fra le app collegate – la lista di controllo qui sopra vale per ogni app, per sempre. ## L'SSO su Back4app Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Qui un'app entra in un parco SSO come service provider attraverso lo stesso meccanismo di adattatori che alimenta il [login social](/glossary/it/oauth-2-login-social/): Back4app porta adattatori di autenticazione per Keycloak, LDAP ed emittenti OAuth2/OIDC generici, così il flusso delle schede di codice – l'IdP autentica, l'app riceve i token, `logInWith` li verifica lato server presso l'emittente – trasforma l'SSO aziendale in configurazione più un gestore di redirect. Le identità si ancorano al subject stabile dell'IdP dentro `authData` per singolo provider, il primo accesso fa provisioning dell'utente just-in-time, `linkWith` aggancia metodi aggiuntivi per il percorso di emergenza, e la sessione emessa dall'app resta una sessione Parse revocabile – così la stratificazione a tre orologi finisce, su questo lato, con un orologio interamente sotto controllo.