OpenID Connect e OAuth 2.0, i protocolli di autenticazione SPID: così proteggono la nostra identità digitale

Il Sistema Pubblico di Identità Digitale (SPID) consente di accedere in maniera semplice e sicura ai servizi online della Pubblica Amministrazione e dei privati aderenti. In particolare, la sicurezza della nostra identità digitale e la procedura di autenticazione sono garantite grazie all’utilizzo dei protocolli OpenID Connect e OAuth 2.0.

Comprenderne il funzionamento consente di aumentare la fiducia verso questo sistema ed evitare comportamenti impropri o pericolosi per la nostra privacy.

Furti d’identità: le tecnologie di tutela ci sono, ma banche e negozi le usano poco

La gestione degli utenti e il riconoscimento dell’identità

Come si può leggere sul sito dell’Agenzia per l’Italia digitale (AgID): “L’identità SPID è rilasciata dai Gestori di Identità Digitale (Identity Provider – IdP), soggetti privati accreditati da AgID che, nel rispetto delle regole emesse dall’Agenzia, forniscono le identità digitali e gestiscono l’autenticazione degli utenti”, ossia, l’autenticazione non è fatta da un unico soggetto ma è possibile selezionare chi garantirà e gestirà la nostra identità digitale.

Possiamo notare subito che, parlando di IdP al plurale, intendiamo un sistema di autenticazione federato anziché centralizzato. È un elemento importante perché consente la giusta resilienza dell’infrastrutture, avendo la possibilità di distribuire il riconoscimento dell’identità su un numero di provider adeguato a contrastare qualunque congestione su picchi elevati di richieste.

Il buon funzionamento del processo di gestione degli utenti e di riconoscimento dell’identità è assicurato da un insieme di protocolli di comunicazione che ne regolamentano ogni passo, che peraltro sono aperti, ossia senza parti proprietarie che un domani potrebbero portare a potenziali condizionamenti da parte dei gestori.

Quest’ultimo aspetto non è secondario per la fiducia che attribuiamo al metodo di autenticazione e la sua conseguente diffusione. Il modello organizzativo si basa sull’interazione di tre tipi di attori, a loro volta con delle componenti significative nell’autenticazione:

• End-User: è l’individuo (utente), ossia il cittadino, che richiede l’accesso a servizi online, gestiti dal pubblico o dal privato, all’interno dell’ecosistema di validazione dell’identità digitale.

1. User Agent: è il browser web usato dall’utente per fare la richiesta di accesso ad una risorsa online.
2. UserInfo Endpoint: è il set di dati personali autorizzati che vengono inviati dal IdP al Service Provider.

• Service Provider: è il fornitore e gestore dei servizi online richiesti dall’utente.

1. Relying Party: è l’applicazione od il sito web del Service Provider che richiede l’autenticazione dell’identità digitale al IdP. Talvolta è detto anche Client.
2. Resource Server: è il server del Service Provider che ospita la risorsa da accedere.

• Identity Provider: è il gestore dell’identità digitale e custode dell’identità fisica. E’ il garante della transazione che avviene tra l’utente ed il service provider.

1. Authorization Server: è il server dell’Identity Provider che procede all’autenticazione ed al rilascio dei dati dell’utente.

Le interazioni tra questi tre attori permettono di gestire in modo disgiunto il processo di autenticazione dell’identità digitale da quello di gestione delle risorse richieste, il primo è assegnato al IdP mentre il secondo al Service Provider. Con questa separazione di ruoli si raggiunge l’obiettivo di ridurre il numero di account dell’utente, evitando di dover creare un account per ogni fornitore di servizi. L’ Identity Provider sarà il solo detentore dell’identità fisica, mentre il Service Provider conoscerà solo l’identità digitale ed i dati personali essenziali all’erogazione del servizio od all’accesso alla risorsa. Principio del need-to-know rispettato, ossia trattare solo i dati personali strettamente necessari alla specifica finalità. Oltre all’aspetto della privacy, c’è l’indubbio vantaggio di poter gestire gli aggiornamenti dei propri dati su di un unico account, senza dover replicare le modifiche per ogni servizio acceso.

La figura dell’Identity Provider è molto importante perché deve fornire adeguate garanzie di conservazione dei nostri dati personali, in particolari i dati della nostra identità fisica. Nelle transazioni Internet non sempre è necessario fornire tutti i nostri dati per identificarci fisicamente, ma è sufficiente fornire garanzie sulla bontà dell’identità digitale.

Qui il IdP svolge il suo ruolo di garante (trustee) che a quell’identità digitale corrisponde una ben definita identità fisica.

È evidente la necessità dell’attribuzione dei dati personali all’IdP sarà un processo di registrazione rigoroso e non limitato ad una semplice compilazione di un anonimo form su Internet. Dovrà accertarsi della nostra vera identità fisica e poi custodire queste informazioni in modo adeguato a prevenire usi illeciti.

OpenID Connect e OAuth 2.0: modelli di funzionamento

Per descrivere tecnicamente il modello generale, iniziamo dall’insieme delle specifiche che realizzano l’architettura d’insieme di questo sistema federato. Il protocollo di autenticazione dell’identità digitale, al livello superiore è OpenID Connect^[1], ed è posizionato sopra al protocollo OAuth 2.0^[2] di autorizzazione all’accesso alle risorse.

Il modello di funzionamento è sintetizzato dai seguenti cinque passi:

1. Il Service Provider invia una richiesta di autenticazione all’Identity Provider.
2. L’Identity Provider autentica l’End-User usando un metodo appropriato e conferma come lecita la richiesta del Service Provider.
3. L’Identity Provider risponde con un ID Token per confermare al Service Provider il buon esito del riconoscimento e con un Access Token per autorizzare l’accesso alle risorse.
4. Il Service Provider invia una richiesta all’Identity Provider per accedere alle informazioni dell’End-User.
5. L’Identity Provider risponde con le informazioni personali autorizzate per quella richiesta.

Lo scambio di messaggi di autenticazione è attivato dall’utente che specifica al Service Provider i riferimenti per localizzare l’IdP. Quest’ultimo prepara la richiesta di autenticazione ed invia lo user agent dell’utente all’IdP, che a sua volta procede con l’autenticazione dell’utente e conseguentemente riceve le autorizzazioni su quali informazioni passare al Service Provider.

Lo scambio di messaggi continua tra l’IdP ed il Service Provider in modo che il Service Provider abbia le informazioni di autenticità dell’utente e gli attributi di autorizzazione all’accesso. Questo scambio è sicuro perché si avvale di crittografia per la confidenzialità e codici di validazione dei messaggi per l’integrità.

Il protocollo di autorizzazione OAuth 2.0

Il protocollo di autorizzazione utilizzato è OAuth 2.0, che sta per “Open Authorization”. È progettato principalmente come mezzo per concedere l’accesso all’insieme delle risorse tramite un token di accesso.

Un token di accesso è una stringa che rappresenta l’autorizzazione all’utente finale ad accedere alle risorse sul Resource Server. OAuth 2.0 non definisce un formato specifico per i token di accesso. Tuttavia, in alcuni contesti, viene spesso utilizzato il formato JSON Web Token (JWT).

Ciò consente a chi emette il token di includere dati nel token stesso. Inoltre, per motivi di sicurezza, i token di accesso potrebbero avere una data di scadenza.

La modularità nella scelta dei protocolli per gestire le varie parti che compongono il sistema di identità federata, è un punto di forza, in quanto la capacità di integrazione con componenti di terze parti, lo rende idoneo ad operare anche in ambienti complessi che richiedono soluzioni personalizzate, ma soprattutto riesce a rimanere aggiornato anche all’evolversi delle tecnologia, ovviamente aggiornando i singoli componenti.

Lo standard di autenticazione federata SAML2

Un altro standard industriale di autenticazione federata è SAML2^[3] (Security Assertion Markup Language 2.0), più complesso da implementare ma che comunque presenta forti analogie, anche se con una tassonomia leggermente differente, e può convivere con OpenID Connect. Le similitudini tassonomiche si possono evincere dalla tabella:

Tecnicamente, i meccanismi di gestione dell’identità federata sono sicuri ed in continuo miglioramento. C’è però un aspetto, non tecnico, legato alla necessità dell’utente di poter accedere a svariati servizi, non necessariamente appartenenti all’ecosistema di uno specifico IdP.

Al crescere della diffusione dei servizi di identità federata, sarà necessario supporre di avere più identità digitali. Dal punto di vista dell’utente, le tipologie di identità da gestire sono due, quella fisica e quella digitale.

Quella digitale è gestita dagli standard di autenticazione federata ma solo dopo il preventivo conferimento dei dati della propria identità fisica all’Identity Provider. L’IdP è generalmente un soggetto privato, sicuramente vincolato a verifiche da parte delle autorità, nonché dotato delle relative certificazioni operative.

La questione diviene se veramente è necessario farsi riconoscere con l’identità fisica per attivarsi su un nuovo IdP.

Margini di miglioramento lato privacy

Attualmente, possiamo associare a un’applicazione più metodi di autenticazione oppure più Identity Provider di un unico ecosistema. Il potenziale utente, deve quindi essere registrato su uno di questi IdP per accedere a quell’applicazione.

Per quanto questo ecosistema sia grande, e possa evolversi ampliando la federazione, è sempre un meccanismo non sufficientemente generale.

È lo stesso protocollo di autenticazione che dovrebbe prevedere un meccanismo di selezione del garante dell’identità dell’utente, ma nello stesso tempo che abbia la fiducia dell’applicazione. In altre parole, un meccanismo più generale dovrebbe permettere ad entrambi, utente ed applicazione, di avere un proprio IdP di fiducia.

Un’eventuale estensione del protocollo di identità federata, dovrebbe prevedere di includere nel messaggio di richiesta autenticazione l’indirizzo del proprio IdP. Analogamente, anche il Service Provider dovrebbe inviare all’End-User una propria richiesta di autenticazione, in modo totalmente simmetrico^[4][5].

I due IdP compiranno l’autenticazione dei rispettivi messaggi secondo l’attuale meccanismo, sostituendo applicazione o utente con l’altro IdP, e poi chiuderanno l’autenticazione inviando l’esito ad entrambi. Così, l’applicazione avrà certezza della validità dell’identità digitale e l’utente saprà che si trova esattamente dove voleva essere, e non in un sito fake. Questa estensione renderebbe veramente generale il meccanismo.

Se questa modalità di estendere il protocollo lo rende tecnicamente più flessibile, semplificando anche il processo di registrazione e la necessità di troppe identità digitali, per la privacy rimane ancora un margine di miglioramento.

Potremmo pensare a un meccanismo che adotta due livelli di Identity Provider, uno (trustee) che interfaccia le applicazioni web e l’altro che fa da custode (custodian) dei dati personali. Il principio del need-to-know sarebbe garantito completamente.

Per costituire questo modello, si può pensare a dei IdP di tipo trustee che autenticano tramite OpenID Connect l’accesso alle risorse e degli IdP di tipo custodian che registrano l’identità fisica ed emettono una identità digitale valida per la sola registrazione dell’utente presso i trustee.

Gli IdP, per incrementare la sicurezza, potrebbero lavorare per la verifica dell’identità su una rete parallela (overlay network), e scambiarsi in modo affidabile le credenziali ricevute, dai Service Provider e dagli End-User, per autenticarle. Nella richiesta di autenticazione viaggiano gli url dei propri IdP ed i token di identificazione con le informazioni necessarie a localizzare applicazioni e dispositivo, questa sarebbe una modifica al protocollo, ma visto che è estensibile non è un problema insormontabile.

La nostra identità digitale, sarebbe utile definirla nella forma della casella di posta ossia name@domain.ext, ove il dominio non è quello del server di posta ma quello del server di autenticazione del IdP. che ha emesso quell’identità.

Ci sarebbero diversi vantaggi. I dati personali sono gestiti da un solo IdP, ossia il custodian che dovrebbe essere un autorità per il Paese di residenza dell’utente o della sede legale del Service Provider. Il riconoscimento con dati fisici (es. biometrici) è fatto solo con il custodian, mentre agli eventuali trustee, sarebbe il custodian a garantire l’identità digitale, senza ulteriore trattamento di dati fisici.

Un solo custodian per Paese è sufficiente e potrebbe gestire anche l’autenticazione dei passaporti elettronici. Il rilascio delle informazioni personali è gestito in fase di autenticazione, fatto salvo un quantitativo standard legato alla tipologia di autenticazione o assegnate nel processo di registrazione.

NOTE

1. Specifications | OpenID ↑

2. OAuth 2.0 — OAuth ↑

3. FrontPage – SAML Wiki (oasis-open.org) ↑

4. A Symmetrical Framework for the Exchange of Identity Credentials Based on the Trust Paradigm, Part 1: Identity Trust Abstract Model (isaca.org) ↑

5. A Symmetrical Framework for the Exchange of Identity Credentials Based on the Trust Paradigm, Part 2: Identity Trust Service Implementation (isaca.org) ↑