Sulla Programmazione

Quattro chiacchere sulla programmazione e sulle bit-tecnologie con Fabrizio Cipriani

OAuth 2 e i suoi predecessori: breve storia dell'autenticazione online

Quando Tim Berners-Lee inventò il web, il suo unico scopo era quello di aggregare informazioni presenti su computer differenti perchè potesse essere più facile consultarle.

Ma non appena l'idea rivoluzionaria del web prese piede, fu immediatamente chiaro che occorreva anche trovare il modo di proteggere i dati riservati: se un utente provava ad accedervi, il web server doveva identificarlo e verificare se l'accesso poteva essere consentito.

HTTP Basic Access Authentication

La prima forma di autenticazione per il web fu la HTTP Basic Access Authentication: se il server vuole che l'utente si autentichi, lo comunica al brower, il quale mostra all'utente una finestra per inserire una username e password. Quando l'utente le ha inserite, il browser le invia al server in un Authorization Header. Il server, in base ai dati ricevuti, decide se consentire o meno l'accesso.

L'HTTP Basic Access Authentication è supportata da tutti i browser, ma presenta un principale svantaggio: non è possibile personalizzare la finestra con la quale vengono inserite la username e la password.

La necessità di presentare all'utente una GUI in uno stile coerente con quello delle altre pagine del sito diede origine alla Form-Based Authentication.

Form-Based-Authentication

Nel caso della Form-Based Authentication, è il web server a preparare la pagina nella quale inserire le credenziali. L'utente le inserisce e, se sono corrette, il server lo autentica, salvando il suo stato nella memoria di sessione per poter continuare ad autorizzare l'accesso anche alle successive richieste dal browser.

Sia nell'HTTP Basic Access Authentication, che nella Form-based Authentication, le credenziali vengono inviate al server senza essere criptate, con il rischio che qualcuno possa inserirsi nella comunicazione ed entrarne in possesso.

Per aumentare il livello di sicurezza, normalmente si fa uso del protocollo TSL/SSL, che rende indecifrabili le informazioni che transitano tra il browser ed il web server.

OpenID

Con l'andare degli anni internet diventa sempre più diffuso, i servizi online si moltiplicano, e così pure le volte che all'utente è richiesto di creare un nuovo account. Percependo l'irritazione dell'internauta, i maghi dell'autenticazione inventarono OpenID.

L'idea di base fu quella di mettere l'utente in grado di creare un account su un solo server (un "Identity Provider") e renderlo in grado di provare la sua identità a chi lo richiedesse (in realtà uscirono vari standard che sostanzialmente facevano quello che è definito "[Single Sign On, OpenID fu uno di quelli ad avere maggiore successo).

Vediamo più in dettaglio, da un punto di vista più tecnico di cosa stiamo parlando. Gli attori in gioco sono:

  • L'utente
  • Un Identity Provider, il server dove vengono memorizzati i dati dell'account.
  • I Relying Parties, server che si fidano dell'Identity Provider (dall'inglese "to rely on") e che contiengono le risorse o i servizi protetti a cui l'utente vuole avere accesso.

Il flusso:

  1. L'utente accede ad un Relying Party.
  2. Il Relying Party invia all'Identity Provider un "association request".
  3. L'Identity Provider stabilisce l'associazione generando un association handle ed uno shared secret che trasmette al Relying Party
  4. Il Relying Party redirige l'utente alla pagina di login dell'Identity Provider, passandogli l'association handle
  5. L'utente inserisce le proprie credenziali e l'Identity Provider lo autentica.
  6. L'Identity provider fornisce all'utente un codice di autenticazione e lo rispedisce al Relying Party, il quale è in grado di verificare il codice usando lo shared secret ottenuto in precedenza.

L'utente può autenticarsi su tutti i Relying Parties che si fidano del suo Identity Provider (un esempio a caso di Identity Provider: Google) senza la necessità di crearsi ogni volta un account nuovo.

OAuth 2.0

OpenID fu (ed è tutt'ora) uno tra gli standard di autenticazione più popolari ad aver risolto il problema della centralizzazione dell'account.

Rimaneva però da risolvere il problema di come gestire anche l'autorizzazione all'accesso delle risorse, e di come delegare quella autorizzazione ad una applicazione.

Come si poteva fare se si voleva trasferire l'autorizzazione all'accesso ai dati ottenuta dall'utente inserendo le sue credenziali, ad una applicazione che potesse scaricarli ed elaborarli per lui?

La stessa domanda venne in mente a Blaine Cook mentre lavorava ad una implementazione di OpenId per Twitter quando provò a fare una cosa simile per una azienda committente (qui trovate maggiori informazioni sulla storia).

Fu così che nacque OAuth (di cui Blaine Cook è uno dei principali co-autori).

OAuth è uno standard per l'autorizzazione (diversamente dall'OpenID, che è uno standard per l'autenticazione).

Nato nel 2007 come specifica, consolidatosi nel 2010 come Request For Comments, si è evoluto oggi in OAuth 2.0, ed è pienamente supportato da Facebook, Google e Microsoft per i loro servizi online.

In questo caso, abbiamo un server di autorizzazione, un server di risorse, ed una applicazione che vuole accedere alle risorse protette.

A larghe linee il flusso è il seguente:

  • una applicazione A, usata dall'utente U, chiede ad un server di autorizzazione I dei diritti di accesso che può mostrare ad un server R per accedere alle sue risorse.
  • Ricevuta la richiesta, il server I chiede all'utente U di autenticarsi ed autorizzare l'applicazione A.
  • Ottenuta l'autenticazione dall'utente, il server I genera un gettone di accesso che restituisce all'applicazione A.
  • A mostra il gettone di accesso ad R ed accede alle sue risorse.

Scendendo più in dettaglio, questo è un esempio di flusso OAuth 2 per i server web rappresentato con un diagramma di sequenza:

  1. L'utente inserisce la url di una applicazione web (o una app per dispositivo mobile, o una applicazione desktop).
  2. L'applicazione web ha la necessità di accedere alle risorse dell'utente sul Resource Server quindi redirige il browser dell'utente all'Authorization server.
  3. Sull'Authorization server, l'utente inserisce le sue credenziali ed autorizza l'applicazione web ad accedere alle risorse.
  4. L'Authorization server genera un authorization code, uno shared secret, li inserisce come parametri in una url di ridirezionamento che riporta l'utente all'applicazione web.
  5. L'applicazione web presenta l'authorization code all'Authorization server il quale gli restituisce un access token di validità temporanea.
  6. L'applicazione web richiede al Resource Server una risorsa protetta presentando l'access token.
  7. Il Resource Server ritorna la risorsa protetta.

Evoluzioni?

Tutti gli standard di autenticazione ai quali ho accennato sono ancora utilizzati, ma con sponsors come Google, Facebook e Microsoft, OAuth 2 è decisamente il più popolare degli ultimi 2 anni.

Nel panorama degli standard di autenticazione online odierni, al momento non sembrano emergere candidati in grado di rivaleggiare con la sua flessibilità e la sua semplicità, e malgrado non sia mai facile prevedere come si evolveranno le tecnologie di accesso al web, visto la velocità a cui si muovono, OAuth si candida a dominare la scena ancora per qualche anno.

Comments