Che cos'è il 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

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:

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 / 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 — 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.

// 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.

// 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.
}

SP-initiated vs. IdP-initiated

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 specifica i due profili; la regola pratica sta nell’ultima riga della tabella.

SAML vs. OIDC

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 – 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 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 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

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: 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.