Nel corso degli ultimi mesi in cui sto sviluppando web per la Pubblica Amministrazione, sto “mettendo al centro” delle piattaforme che realizzo l’utente, inteso come un vero destinatario attivo di un servizio online, talvolta fondamentale. Questo approccio mi impone di dedicare un’attenzione ai flussi che va al di là della user experience “marketing-oriented” e mi impone di utilizzare una cura al dettaglio molto puntigliosa.
Facendo un minimo di contesto, credo che ci troviamo in un momento storico in cui vari fattori sembrano convergere e mi danno l’impressione che stiamo un po’ “rinnovando il web”; l’Agenzia per l’Italia Digitale (AGID), i Designers Italia e Developers Italia team stanno facendo un ottimo lavoro che parte dal design, inteso come progettazione, e arriva alla prototipazione, allo sviluppo e alla realizzazione pratica di componenti usabili, accessibili e funzionali. Tutto questo, sommato alla fruizione semantica del web, anche grazie alle AI, e all’attenzione all’Accessibilità mi fanno ben sperare per il futuro a breve termine del web.
Nello sviluppo, sempre più orientato a soluzioni Frontend/Backend o che comunque prevedono sistemi non più basilari in cui spesso le componenti in gioco sono più di una, è necessario trovare fili conduttori che tengano insieme web application complesse e non più gestibili in un unico sistema. Eccoci quindi a fare i conti con chiamate API continue, verifiche dei dati da terze parti, trasmissioni di dati, export, …
Proprio per questo mi voglio soffermare su uno degli aspetti che ho individuato come strategici, di fondamentale importanza, per il lavoro nel web odierno: l’autenticazione.
Utilizziamo sistemi Oauth2 tutti i giorni, probabilmente senza saperlo, ma sono una delle chiavi che tengono insieme il nostro modo di utilizzare il web oggi. Permettetemi di descriverlo in breve.
Voglio accedere a Gmail
Vado quindi su gmail.com.
Ma non mi trovo su gmail.com (o su mail.google.com); mi vengo reindirizzato a accounts.google.com/v3/signin/identifier…, ovvero il sistema di autenticazione di Google.
Perchè succede questo?
Beh, perchè di Google non usiamo solo la Gmail. Usiamo decine di servizi a cui servono gli stessi nostri dati e per i quali risulterebbe ormai davvero sconvieniente autenticarsi ogni volta. Perciò si è arrivati ad un metodo che prevede soltanto una volta la nostra autenticazione tramite un Identity Provider.
Identity Provider (IDP)
È il soggetto responsabile dell’accertamento dell’identità di un utente. L’Auth Server stesso può esere un Identity Provider, contenendo nel DB i dati di utenti configurati direttamente, oppure può riferirsi ad altri soggetti come ad esempio un server Active Directory. Meglio ancora, come nei casi su cui lavoro più spesso, sono SPID o CIE ad essere gli IDP di riferimento.
Un token
Una volta accertata la nostra identità, la web application su cui ci troviamo riceve dall’Auth Server un token, che ci permette di usurfruire dei servizi fino alla sua scadenza (lifetime) o al suo rinnovo (refresh).
Di conseguenza, ogni volta che questo token “va in giro”, può essere controllato presso l’Auth Server (introspection), per sapere se è valido.
Informazioni Basilari
Piccolo chiarimento, stiamo parlando di un JWT token (JSON Web Token), che porta quindi con sè delle informazioni basilari, che decidiamo noi, riguardanti l’identità dell’utente.
Per fare un breve esempio, se inseriamo il nome dell’utente nel token potremo tranquillamente inserire in ogni pagina delle login info (es. “Ciao Giacomo“) che indicano che l’utente è loggato.
Nota: È possibile decodificare un token in vari modi, tra cui questo.
Ruoli
Oltre ai dati personali (generalmente nome, cognome e email), il token contiene anche dati relativi ai ruoli, pertanto possiamo perimetrare il raggio di azione degli utenti nelle varie web app. I permessi possono essere gestiti direttamente dall’Auth Server e possono essere, generalmente:
- Relativi al realm (All’Auth Server in sè, per farla breve)
- Al Client (quindi alla web application)
- All’Utente
- Al Gruppo di utenti
Singel Sign On (SSO)
Cosa significa? In realtà, più chiaro di così non può essere.
In breve, se dopo essere andati su Gmail volessimo andare su Google Analytics per dare un’occhiata alle visite sui nostri siti, ci troveremmo già autenticati.
Questo perchè, per lo stesso meccanismo, quando andiamo su analytics.google.com, in realtà “passiamo” sempre da accounts.google.com/v3/signin/identifier… , il quale saprà che siamo autenticati e ci rimanderà, questa volta, al corretto redirect_uri, in questo caso: analytics.google.com.
Interoperabilità
Ed ora viene il bello! Come avrete senz’altro notato, anche innumerevoli altri siti e applicazioni al di fuori degli ecosistemi Google, Meta, GitHub, … possono usare Auth Server terzi, proprio per questa semplicità e interoperabilità sviluppata by design.
Ci capita quindi di poter accedere tramite Account Google, Meta, GitHub, X (Twitter), … e il meccanismo sarà sempre il medesimo; prima di accedere ad una piattaforma potremo scegliere che autenticazione utilizzare; verremo quindi riportati all’Auth Server del proviver che abbiamo selezionato e su cui abbiamo un account, il quale se non siamo già autenticati ci chiederà di inserire username e password (o altri n sistemi di autenticazione) e poi ci riporterà alla piattaforma di partenza (redirect_uri), previo consenso dell’invio di alcuni dati (sempre indicati, come username, nome, cognome e indizizzo email) alla piattaforma di destinazione.
Esempio: per accedere ad una web app posso autenticarmi con GitHub.
A sua volta, anche per accedere a GitHub posso utilizzare un’ altro Auth Server ‘autenticazione di terze parti se non sono in possesso di un account su GitHub stesso.
Una volta eseguito l’accesso, vengo portato all’applicazione iniziale (redirect_uri), e sono autenticato.
Per approfondire…
Se volete sapere tutto ma proprio tutto sui sistemi di autenticazione Oauth2, andate qui.
Keycloak è un ottimo Auth Server Open Source.
Per ora mi fermo qui
Ho tentato di semplificare molto e mi rendo conto che alcuni concetti potrebbero non essere così semplici da comunicare; ho tralasciato dettagli tecnici fondamentali sulle varie chiamate e sui dati necessari per effettuarle (come client_id e client_secret) ma saranno approfonditi a breve in altri contenuti.
Ho parlato prima di aspetti strategici; oltre all’autenticaizone, penso che l’interazione tra le piattaforme sia un altro di questi e, nella fattispecie, lo sviluppo di un API Gateway è un altro dei miei attuali progetti di cui parlerò a breve. Se vi interessa… pingatemi!
mini