Nello sviluppo di un’app, una delle parti più critiche è sicuramente quella relativa all’autenticazione di un utente e con l’avvento delle architetture informatiche a microservizi ed a microfrontend è aumentata la necessità di centralizzare e unificare questo processo per evitare problemi e facilitare il percorso dell’utente attraverso le varie componenti di un servizio.

Una delle soluzioni più utilizzate per questo tipo di problemi è quella nota come Single Sign-On.

Cos’è il Single Sign-On?

Per Single Sign-On (SSO in breve) si intende un modo per semplificare l’accesso e l’autorizzazione degli utenti sulla base di un insieme di open standard che permettono di delegare la gestione degli utenti (accesso, registrazione e autorizzazione) ad un servizio esterno, noto come servizio di Identity Provider (IdP in breve), che si occuperà del processo di autenticazione degli utenti e restituirà ai nostri servizi un token che potrà essere utilizzato per verificare l’identità dell’utente ed i suoi permessi all’interno del sistema informatico.

Dal Single Sign-On al Social Login

Uno degli scenari più comuni in cui un utente utilizza una forma di Single Sign-On (anche senza esserne pienamente consapevole) è quando interagisce con i servizi di Google.

Quando l’utente si collega a google.com, inizia il seguente flusso: l’utente facendo click sul pulsante “Login“ del sito google.com, viene reindirizzato su accounts.google.com (che è il dominio che ospita l’IdP di Google) dove completerà la procedura di accesso (inserendo username e password e passando la sfida di autenticazione a 2 fattori – se richiesto) venendo poi reindirizzato al sito dove ha iniziato il processo;

Ora durante la navigazione tra i diversi servizi Google (come GMail, YouTube, Google Drive, ecc…) si troverà già autenticato su ognuno di essi grazie al token creato attraverso il precedente procedimento ed ogni servizio potrà verificare l’identità dell’utente e concedergli l’accesso alle sue risorse personali.

Un piccolo passo avanti all’interno del mondo del Single Sign-On ci porta al concetto di Identità Federate e al cosiddetto Social Login.

Nel caso di Identità federate un sistema può identificare un utente “fidandosi” di un Identity Provider esterno con cui è federato, in questo scenario il sistema a cui l’utente accede non ha conoscenza delle credenziali utilizzate per il login ma si fida del token restituito dal IdP e può identificare l’utente sulla base delle informazioni da esso condivise.

Un caso comune di Federated Identity è rappresentato dalle Social Logins, ad esempio quando un utente accede ad un’applicazione utilizzando un pulsante “Login con Google” viene reindirizzato ad accounts.google.com e, dopo aver completato il processo di autenticazione (praticamente identico in questo caso a quello descritto sopra), gli verrà richiesto di consentire all’app esterna di accedere ad alcuni dei suoi dati (le informazioni richieste variano da applicazione ad applicazione) e viene poi reindirizzato all’applicazione di origine che ora potrà creare o recuperare i dati interni dell’utente sulla base delle informazioni e del token restituito dall’ IdP.

Aspetti tecnici

Quando si parla di Single Sign-On ed Identità federate gli open standard più utilizzati sono sicuramente i tre elencati di seguito:

OAuth 2.0

OAuth 2.0 è il protocollo leader del settore per l’Autorizzazione e si concentra sulla descrizione di un modo semplice e sicuro per concedere l’accesso alle risorse di servizio ad un utente definendo i flussi raccomandati per autorizzare l’accesso e come rappresentare le autorizzazioni concesse.

La parte principale del protocollo OAuth 2.0 sono Scopes, che definiscono un modo per limitare la quantità di informazioni di un utente a cui un sistema può accedere, e Grant Types, che sono le tipologie di token software che due sistemi possono scambiare per autorizzare l’utente.

OpenID Connect

OpenID Connect è un protocollo basato su OAuth 2.0 che aggiunge la capacità di Autenticazione specificando un nuovo Grant Type chiamato ID token che contiene un insieme di Scopes e Claims specifiche per gestire l’identità dell’utente.

Questo protocollo è quello più comune e viene utilizzato dai principali fornitori di Social Login (come ad esempio Google, Facebook, Twitter ed Instagram).

SAML

SAML (abbreviazione di Security Assertion Markup Language) ha un approccio più enterprise ed è solitamente mirato all’uso all’interno degli ambienti di lavoro.

SAML è indipendente da OAuth, si basa su uno scambio di messaggi per l’autenticazione in formato XML SAML, per consentire l’interscambio di dati di autenticazione ed autorizzazione tra IdP e Service Provider per verificare l’identità ed i permessi dell’utente e poter quindi concedere o negare il suo accesso ai servizi protetti da tale protocollo.