Autenticazione delle Chiamate API

Il principale metodo per lo scambio di informazioni tra sistemi distribuiti consiste nell’implementare una o più API, spesso esposte attraverso interfacce web, attraverso le quali i dati possono essere scambiati in modo rapido al momento in cui servono. Nel realizzare questo tipo di integrazione tra sistemi la principale preoccupazione è quella di garantire che i dati siano scambiati con soggetti che sono autorizzati ad accedervi.

In questo articolo sono descritti i principali metodi di autenticazione utilizzati per garantire la sicurezza delle API, identificando i pro e i contro di ogni approccio.

Autenticazione vs Autorizzazione

Prima di entrare nel dettaglio del tema affrontato nell’articolo, può essere utili dare una definizione di cosa si intende per autenticazione, questo perché spesso viene confuso con un concetto molto prossimo ed intimamente correlato, quello dell’autorizzazione. La loro relazione è talmente forte che non è difficile trovarli integrati in soluzioni ibride, ovvero che combinano autenticazione ed autorizzazione, e che contribuiscono a rendere confuso l’argomento.

Il modo migliore per distinguere i due concetti è quello di chiedersi quali sono le loro finalità e che cosa intendono “provare“. In termini semplici l’autenticazione è un processo che consente ad una entità di dimostrare la propria identità e provare di essere ciò che si dice di essere. L’autorizzazione, invece, è un concetto completamente diverso, sebbene strettamente correlato. In termini semplicistici, l’autorizzazione è quando un’entità dimostra di avere un diritto di accesso.

Volendo fare un parallelo con la vita reale, la carta di identità è uno strumento di autenticazione certificato che prova la nostra identità. Diversamente un biglietto del cinema è uno strumento di autorizzazione che prova che abbiamo diritto di accedere alla visione di uno specifico film in uno specifico orario.  Si noti che il biglietto non prova la nostra identità, così come la carta di identità non ci autorizza ad accedere al cinema.  Se prendiamo in considerazione, invece, la patente di guida, questa non solo provare la nostra identità, ma fornisce anche una informazioni in più, ovvero che possiamo guidare. Si tratta di una caso di soluzione ibrida tra autenticazione ed autorizzazione.

Metodi Comuni di Autenticazione

Detto ciò vediamo nel seguito quali sono le tecniche che consentono ad un client di utilizzare una interfaccia API provando la propria identità. Ogni sistema commerciale in genere adotta un proprio sistema proprietario, ma fondamentalmente si tratta di variazioni di metodi principali sviluppati per introdurre l’autenticazione in architetture largamente utilizzate nei sistemi distribuito, come quella dei sistemi web.

HTTP Basic Authentication

Uno dei sistemi di autenticazione più semplice è la Basic Authentication, in cui una entità prova la propria identità fornendo una username ed una password. Questo approccio non richiede l’utilizzo di cookie, ID di sessione, pagine di accesso e altre soluzioni specializzate. Inoltre poiché utilizza le intestazioni (header) del protocollo HTTP, non necessita di processi di handshaking o di altri sistemi complessi di comunicazione.

Nella pratica il protocollo prevede che la username e la password vengono concatenati nella forma username:password e poi encodati in Base 64. Infine vengono trasmessi al server in un header HTTP denominato Authorization. Un esempio di richiesta HTTP conforme a tale protocollo è:

Si noti che l’operazione di encoding in Base 64 è reversibile, il server infatti, utilizza l’operazione opposta di decoding per recuperare le credenziali di autenticazione. Conseguentemente tale metodo di autenticazione è hackerabile attraverso un semplice attacco man on the middle. Per tale motivo tale tipo di autenticazione deve essere utilizzata esclusivamente in accoppiamento con il protocollo SSL/TSL, che cifra l’intero flusso di comunicazione. Per contro tale vincolo rende la comunicazione più lenta e non utilizzabile in determinati contesti.

Un ulteriore svantaggio della Basic Authentication è che richiede l’invio delle credenziali ad ogni invocazione delle API. Infine non si tratta di protocollo robusto in caso di manomissione degli header da parte di un attaccante (tampering).

HMAC Authentication

Una variante del processo descritto precedentemente è l’HMAC (keyed-hash message authentication code o hash-based message authentication code) in cui, come indicato nel nome, è utilizzata una funzione di hash ed una chiave segreta per la comunicazione al server delle credenziali utente. Tale operazione non è reversibili ed è considerata crittograficamente sicura se si utilizza come algoritmo almeno lo SHA-256 o uno considerato più “forte”.

Nella realtà il protocollo non prevede esclusivamente la generazione dell’hash della password utente, ma al fine di garantire una maggiore protezione della risorsa richiesta, possono essere inserite altre informazioni (non necessariamente tutte) quali:

• la URL della risorsa richiesta;
• il metodo HTTP utilizzato (GET, POST, etc.);
• un timestamp;
• un numero generato casualmente (nonce);
• l’MD5 del body della request (riduce il rischio di tampering).

Quindi se indichiamo con il termine digest l’encoding in Base 64 del risultato dell’hash applicato a tali informazioni (concatenate):

l’header della richiesta HTTP si presenterà nel seguente modo:

Al fine di verificare l’autenticazione il server deve essere in grado di ricostruire il digest, ciò implica che la password deve essere memorizzata in chiaro. Questo è il motivo per cui si preferisce utilizzare il termine  secret  piuttosto che password . Naturalmente anche il timestamp e la nonce devono essere inviati con la request, inoltre il timestamp dovrà essere in un range di minuti di differenza con l’ora del server, altrimenti la request sarà ignorata.

Dal punto di vista della sicurezza, anche se un hacker si mette in ascolto della conversazione, non sarà comunque in grado di autenticarsi utilizzando le informazioni carpite. Questo perchè ogni cambiamento nel contenuto della request comporterebbe un’alterazione del digest. La presenza dei parametri timestamp e della nonce impediscono inoltre all’eventuale hacker di utilizzare la medesima request per interrogare il server.

Per quanto riguarda invece la chiave segreta utilizzata per il calcolo dell’hash, questa in genere è generata dal provider e scambiata anticipatamente con il client. La username è utilizzata dal server per recuperare la chiave o, alternativamente, è possibile indicare un id di chiave nel messaggio, che identifichi univocamente la chiave utilizzata.

API Keys

Questo metodo di autenticazione fu creato per superare le limitazioni della Basic Authentication. Una Api Key non è altro che in token univoco, generato casualmente, che il client comunica al server ogni volta che esegue una request e che serve ad identificarlo. Diversamente da una username o password una Api Key non è una stringa mnemonica semplice da ricordare e generalmente è molto più lunga, comportando una maggiore entropia rispetto ad una password. Un esempio di token è il seguente:

IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx

La sua trasmissione può avvenire in diversi modi:

• attraverso query string:

• all’interno di un header HTTP:

• mediante cookie:

Alcuni sistemi richiedono l’utilizzo di due token che sono utilizzati in AND ai fine dell’autenticazione. Non vi è una nomenclatura univoca per identificare tali chiavi, alcuni parlano di  Api Key  e  App Id , altri di  Api Key  e  Secret Key , etc.

Dal punto di vista della sicurezza l’utilizzo delle Api Keys soffre dello stesso problema della Basic Authentication, ovvero il protocollo, per essere considerato sicuro, deve essere utilizzato in accoppiamento con altri protocolli di sicurezza come SSL/TLS. Inoltre negli anni tale approccio è stato utilizzato in modo improprio, non solo per implementare l’autenticazione ma anche per fornire autorizzazione. Cosa molto pericolosa se si considera che la Api Key può essere recuperata, semplicemente sniffando la request in un qualsiasi punto della rete che non sia adeguatamente protetto.

OAuth

OAuth è un protocollo di autenticazione che consente a un utente (resource owner) di concedere a un’applicazione di terze parti (consumer/client) l’accesso alle proprie informazioni su un altro sito (resource). Il processo di autenticazione, descritto nella figura seguente, prevede che quando un utente richiede l’accesso ad una determinata risorsa, questi venga rediretto su di un server di autenticazione, detto OAuth provider. Al termine del riconoscimento dell’utente l’OAuth provider genera un token che viene restituito al server che detiene la risorsa ed è utilizzato da questi per validare la richiesta.

Esistono due versioni di tale protocollo. La specifica della version 1.0 fu rilasciata nel dicembre del 2007, anche se successivamente emendato per questioni di sicurezza, mentre la specifica della versione 2.0 risale ad ottobre del 2012.

OAuth Versione 1.0

La versione 1.0 è quella più ampiamente utilizzata, testata e sicura. Il protocollo, infatti, utilizza una firma crittografica, in genere HMAC-SHA1, che combina secret token, nonce e altre informazioni caratteristiche della request. Il grande vantaggio di tale versione è che non viaggia mai in modo diretto il secret token attraverso la rete, eliminando completamente la possibilità che qualche hacker possa sniffarla. Inoltre può essere utilizzato tranquillamente senza necessità di accoppiarlo ai protocolli SSL/TLS.
Tuttavia, questo livello di sicurezza ha un prezzo. La generazione e la convalida delle firme possono essere un processo complesso, che utilizza algoritmi di hashing specifici con una serie rigorosa di passaggi.

OAuth Versione 2.0

La versione 2.0 del protocollo non è una evoluzione della versione 1.0, ma ne è una completa riscrittura allo scopo di ridurne la complessità. La nuova specifica infatti rimuove la necessità delle firme digitali. Non è più necessario, infatti, utilizzare algoritmi crittografici per creare, generare e convalidare le firme. Tuttavia la crittografia è ancora utilizzata in quanto è richiesto obbligatoriamente l’utilizzo del protocollo TLS per cifrare la comunicazione.