Ogni volta che eseguiamo un accesso ad un sistema informatico, ad un portale, oppure ad un app, ci viene richiesto di autenticarci cioè di dichiarare “Chi siamo”. In base ai privilegi che possediamo abbiamo accesso ad informazioni diverse; sono le nostre autorizzazioni cioè “Cosa possiamo fare”. In tutti questi anni, con l’avvento dei servizi sul cloud, i sistemi informatici e le applicazioni, si sono evoluti notevolmente. Prima del cloud, l’autenticazione e l’autorizzazione erano confinate e gestite all’interno dell’applicazione, o del portale che stavamo consultando, rendendo la vita degli sviluppatori e dei sistemisti più semplice e circoscritta, ora non è più così.
L’evoluzione delle abitudini e delle tecnologie hanno richiesto che l’autenticazione venga gestita da Identity Provider (IdP) terzi (es: Microsoft, Google, Facebook) rispetto ai portali o alle applicazioni che vogliamo consultare. Inoltre è necessario che ogni componente in gioco possa impersonificare l’utente autenticato presso altri servizi. Per soddisfare queste necessità Azure Active Directory utilizza il protocollo OAuth 2 .0 e la sua estensione OpenID Connect.
Ci sarà capitato molto spesso negli ultimi anni di autorizzare un’app o un gioco all’uso delle credenziali di Facebook, Google o Microsoft. Quella semplice operazione permette la trust tra l’IdP e la Web Application dove risiedono i veri e propri servizi siano esse applicazioni o blog. In quel momento autorizziamo l’Access Token generato dall’IdP per verificare la nostra identità mentre le nostre informazioni personali (es: nome, cognome, email) viaggiano all’interno dell’Id Token.
Se, all’interno del flusso OpenID Connect (OIDC), viene richiesto ed ottenuto l’Authorization Code sarà possibile impersonificare l’utente verso Web API esterne su piattaforme o componenti aggiuntive e indipendenti.
Il “Time To Live” per l’utilizzo dell’Access Token è breve ma il Refresh Token potrà essere utilizzato per molti giorni a seguire evitando all’utente il noioso reinserimento delle credenziali a garanzia del rapporto tra le varie applicazioni e l’idenitità dell’utente.
Dato che OpenID Connect è un’estensione dell’OAuth 2.0 capita che la parte di delega delle autorizzazioni verso applicazioni terze non includa necessariamente le informazioni dell’utente.
Poniamo per esempio di avere un’applicazione su tablet in dotazione ai meccanici nell’officina. Loro si autenticano con il loro account personale ed entrano nel portale che gestisce il loro lavoro in officina. Vengono identificati con l’indirizzo di posta elettronica. In questo caso sono presenti sia l’Access Token che l’ID Token. In seguito il tecnico deve consultare il catalogo per i pezzi di ricambio che risiede in un’altra applicazione. Questo catalogo è sempre lo stesso a prescindere dagli utenti che lo consultano quindi l’accesso alla lista dei prodotti avverrà, da parte dell’App, semplicemente utilizzando un Access Token senza che il gestore del catalogo sappia (o gestisca) le identità dei meccanici. Il carrello della spesa sarà abbinato all’utente (magari su un servizio esterno) mentre l’acquisto finale dei prodotti avverà a nome dell’officina in un’ulteriore applicazione terza.
Conclusioni
Il protocollo OAuth 2.0 e la sua estensione OpenID Connect permettono di interfacciare tra loro applicazioni diverse semplificando l’autenticazione degli utenti e garantendo l’autorizzazione e l’integrazione tra tutti i servizi.