Il tema della sicurezza è il vero motore che spinge alla continua innovazione dei sistemi di identità federata (come lo SPID), ma contestualmente deve assicurare un’elevata semplicità implementativa per garantirne l’efficacia. Il mondo dell’identità federata è essenzialmente diviso tra due standard, che però interagiscono tra loro: in ordine di tempo è arrivato prima lo standard SAML2 (Security Assertion Markup Language 2.0) con una versione iniziale nel 2002, seguito dopo qualche anno nel 2014, da OpenID Connect 1.0 (OIDC), derivato dai precedenti protocolli OpenID 1.0 (2006) e 2.0 (2007) ma oramai ritenuti obsoleti.
L’utilizzo di questi protocolli nasce dalla constatazione che, per ridurre il rischio della sicurezza, non possiamo agire sull’impatto potenziale poiché dipende dall’estensione dell’ecosistema, mentre possiamo agire sulla probabilità poiché dipende dalle vulnerabilità introdotte dalla tecnologia di autenticazione che si adotta. Questo è possibile ricorrendo, appunto, a soluzioni standard, dal momento che hanno il beneficio della maggior esperienza accumulata nel tempo.
Concentriamo, dunque, la nostra attenzione su OpenID Connect per analizzare le sue capacità di estensione del framework e per l’interoperabilità con altri metodi di autenticazione.
SPID, AgID blinda l’identità digitale con OpenID Connect: resta una criticità
Indice degli argomenti
Cos’è e a cosa serve OpenID Connect
OpenID Connect 1.0 può essere visto come un semplice livello di identità in cima al protocollo OAuth 2.0 e consente ai client di verificare l’identità dell’utente finale in base all’autenticazione eseguita da un server di autorizzazione, ma anche di ottenere informazioni di base sul profilo dell’utente finale in modo interoperabile.
Trattandosi di un protocollo standard, OpenID Connect consente ai client di tutti i tipi, compresi quelli basati su Web, dispositivi mobili e JavaScript, di richiedere e ricevere informazioni sulle sessioni autenticate e sugli utenti finali.
Il mondo dell’identità federata rappresenta, infatti, un evoluzione del concetto del single sign-on (in acronimo SSO) centralizzato dell’azienda. L’ utente ha un’unica identità digitale per accedere alle risorse dell’intero ecosistema digitale e, nel caso di risorse differenti ma in trust tra loro, effettuando un’unica autenticazione, e gli sarà consentito l’accesso al pool di queste risorse senza autenticarsi nuovamente. Questo è uno dei risultati del protocollo di autenticazione decentrata definito nello standard OpenID Connect.
La tassonomia di OpenID Connect
Il modello di riferimento, che descrive il funzionamento e le interrelazioni tra le parti costitutive del protocollo OIDC, ha una sua specifica tassonomia, purtroppo con termini a volte differenti da framework similari a parità di concetto:
- End-User: è l’individuo (utente), che richiede l’accesso a servizi online.
- User Agent: è il browser web usato dall’utente per accedere alle risorse online.
- Claims: è un insieme di informazioni sull’utente di tipo nome-valore.
- Authorization Server: è un server che possiede l’identità e le credenziali dell’utente.
- OpenID Provider: è l’Authorization Server capace di autenticare l’utente e rilasciare i Claims.
- Relying Party: è l’applicazione Client che richiede l’autenticazione dell’utente ed i Claims.
- Resource Server: è il server che ospita le risorse che saranno accedute.
- ID Token: è la stringa che contiene i Claims di autenticazione nel formato JWT (JSON Web Token), coppie del tipo nome:valore.
- Subject Identifier: è l’identificativo univoco dell’utente, rilasciato al Client.
- UserInfo Endpoint: è l’interfaccia che rilascia le informazioni autorizzate dell’utente.
Come funziona l’autenticazione OIDC
Il protocollo di autenticazione dell’identità digitale OpenID Connect, si basa sul protocollo OAuth 2.0 per assegnare l’autorizzazione all’accesso alle risorse, ma anche ne emula alcuni costrutti implementativi. Il modello astratto di riconoscimento dell’identità è sintetizzato nei seguenti otto passi:
- Il Client prepara una richiesta di autenticazione contenente i parametri di richiesta desiderati tramite lo User Agent.
- Il Client invia la richiesta all’Authorization Server.
- L’Authorization Server autentica l’End-User.
- L’Authorization Server ottiene il consenso/autorizzazione dell’utente.
- L’Authorization Server ritorna al Client un Access Token e, se richiesto, un ID Token.
- Il Client richiede una risposta utilizzando l’Access Token al Token Endpoint.
- L’Authorization Server valida l’Access Token e restituisce l’ID e l’Access Token.
- Il Client convalida l’ID Token e recupera il Subject Identifier dell’utente.
La tassonomia tra OAuth e OpenID Connect è leggermente diversa ma i termini si sovrappongono perfettamente. Lo standard OpenID Connect consente parametri aggiuntivi nella richiesta e introduce i concetti di Claims e ID Token.
Ad esempio, il Client può stabilire la lingua da utilizzare nel form di autenticazione oppure il livello di autenticazione.
I Claims sono coppie “nome-valore” che forniscono dati di attributo sull’utente che è stato autenticato. Vengono già forniti dei nomi standard per i Claims ma è previsto si possano aggiungere dei nuovi nomi per adattarsi a delle specifiche esigenze.
Come funziona l’ID token
L’ID Token è costruito dall’OpenID Provider e restituito al Client come passo finale dell’autenticazione e contiene i Claims di autenticazione e quelli utente. Il token è nella forma di un JSON Web Token (JWT) ed è firmato in modo sicuro.
Le caratteristiche standard dell’ID Token sono:
- Dichiara l’identificativo univoco dell’utente, chiamato Subject (sub).
- Specifica l’identificatore dell’autorità emittente la risposta (iss).
- È generato per un particolare insieme di destinatari (Clients) (aud).
- Può contenere una specifica idonea per una sola occasione (nonce).
- Può specificare quando (auth_time) e come, in termini di robustezza del metodo (acr), l’utente è stato autenticato.
- Stabilisce un tempo di emissione (iat) ed uno di scadenza (exp).
- Può includere ulteriori dettagli sull’utente, come nome e indirizzo email.
- È firmato digitalmente, quindi può essere verificato solo dai destinatari previsti.
- Può essere opzionalmente crittografato per la riservatezza.
Inoltre, essendo basato su OAuth 2.0, OpenID Connect è “API Friendly”, ossia, opera tramite l’Application Programming Interface ed in questo modo può essere utilizzato da applicazioni web, applicazioni desktop, applicazioni mobile o dal software operativo dei dispositivi. Questo è un indubbio vantaggio perché copre tutti gli ambiti di identificazione e controllo accesso.
OpenID Connect gestisce il processo di autenticazione per far connettere l’utente o per determinare se l’utente è già collegato. OIDC restituisce al Client il risultato dell’autenticazione, eseguita dall’Authorization Server in modalità sicura, cosicché il Client possa fare affidamento sul server per questa funzionalità. Per questo motivo, il Client è anche chiamato Relying Party (RP).
Flussi di autenticazione di OpenID Connect
L’iniziale Authentication Request è strutturalmente simile ad una OAuth 2.0 Authorization Request il cui compito è semplicemente di richiedere che l’End-User sia autenticato dall’ Authorization Server. Il processo di autenticazione può seguire uno dei tre flussi autorizzativi che si distinguono per delle peculiari caratteristiche, riassunte in tabella.
Property | Authorization Code Flow | Implicit Flow | Hybrid Flow |
Tutti i token sono ritornati dal Authorization Endpoint | no | yes | no |
Tutti i token sono ritornati dal Token Endpoint | yes | no | no |
I token non sono rivelati al User Agent | yes | no | no |
Il Client può essere autenticato | yes | no | yes |
Il Refresh token è possibile | yes | no | yes |
La comunicazione è in un solo viaggio andata/ritorno | no | yes | no |
Principalmente le comunicazioni sono di tipo server-to-server | yes | no | varies |
Inoltre, i meccanismi di sicurezza variano a scapito della velocità di esecuzione del flusso prescelto, fornendo un’ulteriore elemento di scelta di quale sia più idoneo per le proprie esigenze.
Il processo di autorizzazione, come già detto, è gestito da OAuth 2.0 ed è perfettamente integrato in OpenID Connect.
Anche il processo di autorizzazione possiede svariate possibilità di configurazione. L’importanza dell’informazione protetta, determina quale sarà la corretta configurazione del sistema di autenticazione e di autorizzazione che potrà essere adottato per il riconoscimento dell’identità digitale.
Conclusioni
Un ecosistema di identità digitale federata rappresenta il metodo più semplice per l’utente per l’accesso agli innumerevoli servizi online poiché utilizza un unico insieme di credenziali.
Con l’uso dei Claims, generalmente trattati come cookie di sessione, OpenID Connect permette all’utente di controllare quali parti sono inviate al Client, garantendo che solo quelle necessarie vengano condivise. Il vantaggio per la privacy si accompagna però alla necessità di un uso più consapevole delle credenziali stesse, poiché l’eventuale compromissione coinvolgerebbe un insieme ampio di risorse accessibili.
Nello stesso tempo, il meccanismo descritto dallo standard OpenID Connect è adeguatamente flessibile per adattarsi a tutte le esigenze di sicurezza ed interoperabilità, in quanto è un progetto aperto a continui contributi degli aderenti alla comunità di OpenID Foundation, l’organizzazione internazionale di standardizzazione senza scopo di lucro che coordina il progetto di sviluppo.
