Autenticazione per WebAPI (parte 1 – introduzione e API Keys)

Proseguo nell’opera di riordinare gli appunti sui metodi di autenticaizone per applicazioni web inziata con il primo post della serie Autenticazione per applicazioni web concentrando ora l’attenzione sulle WebAPI

apparch
Scenario di riferimento

Prendendo in considerazione uno scenario applicativo in cui in diversi client devono accederea risorse private pubblicate attraverso una WebAPI la l’elenco (ordinato per complessità crescente) dei metodi di autenticazione/autorizzazione più comunemente utilizzati è il seguente:

Panoramica Generale

Le API Key sono la soluzione più semplice e rapida da implementare.

L’autorizzazione basata sui token e sul protocollo OAuth 2.0 permette una gestione molto più raffinata rispetto alle API Key. I token possono essere fondamentalmente di due tipi:

  • Token leggeri (access token e refresh token) usati solo per accerere a risorse protette.
  • Token con payload utile anche per lo scambio di informazioni (ad esempio possono contenere i dati del profilo utente ed i ruoli associati all’utente nell’ambito di una specifica applicazione). Questi token possono essere in formato XML (come nel caso di SAML 2.0) o in formato JSON (come nel caso di JWT e OpenID Connect). Le informazioni contenute e le funzionalità variano a seconda della specifica implementazione.

SAML 2.0 e OpenId Connect sono sistemi di identità federata che prevedono casi d’uso più estesi e complessi rispetto allo scenario considerato, ma possono essere utilizzanti anche per autenticare gli utenti che accedono ad una web API.

API Keys

Il metodo in assoluto più semplice per limitare l’utilizzo di una webapi sono le API Keys.

In pratica ad ogni utente viene assegnata una chiave (API Key) da includere in ogni richiesta indirizzata verso la web API. L’applicazione solitamente include anche una interfaccia utente più o meno completa per la gestione delle chiavi (richiesta, rinnovo, revoca, … ) da parte dell’utente autorizzato.

Tutta la sicurezza di basa sul presupposto che la chiave deve essere mantenuta segreta: chi utilizza la chiave è automaticamente autorizzato ad utilizzare le web API.

Solitamente le chiavi rimangono valide per un tempo molto lungo e sono particolarmente soggette al rischio di non rimanere riservate (ad esempio potrebbero essere presenti nei log del servizio o di un proxy).

Un altro limite di questo metodo è la scarsa granularità delle autorizzazioni: solitamente la chiave autorizza l’utilizzo dell’intera API senza la possiiblità di specificare il livello di accesso sulle singole risorse esposte.

Questo metodo è comunemente usato delle API pubbliche come ad esempio quelle per i servizi di cartografia, riconoscimento vocale, ecc.. offerti da Google e Microsoft.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...