Outh2 token

Oauth2 – Tipologie di Token

Analizzando il protocollo OAuth2 (introdotto in un precedente post), utilizzato per l’accesso tramite token,  trattiamo le modalità fondamentali per ottenere il token.

OAuth2 definisce quattro modalità  di generazione :

  • Authorization Code Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant
  • Client Credentials Grant

Authorization Code Grant ( RFC 6749)

Questa tipologia di accesso è particolarmente indicata con server web. Il token rilasciato ha una durata relativamente lunga e può essere rinnovato con un refresh token (previa abilitazione sul server di rilascio).

Un server web necessita di accedere alle informazioni del profilo dell’utente memorizzate all’interno di un server web (es. Google). L’applicazione esegue il rederict verso il server web richiedendo l’autorizzazione. Se l’autorizzazione viene concessa, il server web (es. Google) invia al client un auth code che verrà utilizzato per ottenere il token (ed eventualmente il refresh token). A questo punto il flusso per l’accesso sarà effettuato utilizzando il token.

Implicit Grant (RFC 6749)

Indicato nello sviluppo di applicazioni client con linguaggi di scripting (es. Javascript). Questo tipo di implementazione non prevede il rilascio di un refresh token. Uno scenario tipico potrebbe essere quello di un client Angular che necessita di accedere al profilo di Facebook. Il primo steps consiste nell’indirizzamente verso il server di autenticazione (Facebook). Se viene autorizzato l’accesso, il server di autenticazione invia una ridirezione verso il server delle risorse impostanto il token di accesso nell’url. Il client può quindi recupare il token direttamente dall’url e utilizzarlo per gli accessi successivi.

Un esempio di url di risposta (ottenuta dai server di google):  https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN

Resource Owner Password Credentials Grant (RFC 6749)

In questa modalità di accesso le credenziali vengono inviate dal client al server. Il prerequisito è che tra client/server sia presente un trust di piena fiducia. Questo tipo di implementazione  è fortemente consigliato solo quanto client e server sono stati sviluppati dalla stessa autorità di autorizzazione (es. dominio-sottodominio). Uno scenario tipico potrebbe essere quello di una web-application (client) che accede ad alcune api pubbliche  esposte dal server di autenticazione . Una volta validate le credenziali, il server di autenticazione rilascerà al client il token che potrà essere utilizzato nelle comunicazioni successive.

Client Credentials Grant (RFC 6749)

Il client ed il server di autenticazione sono la stessa entità. Il client invia le proprie credenziali al server, il quale rilascia il token di autenticazione.

Pubblicato da

Andrea Merlin

Laureato in informatica, diversi corsi di specializzazione legati allo Sviluppo Software e alla Computer forensics. Appassionato di nuove tecnologie, amo la programmazione, la Business Intelligence e tematiche legate alla Privacy.Sempre alla ricerca di nuove idee, stimoli … e progetti da seguire!Amo trascorrere il tempo libero in Val Borbera, un piccolo angolo del Piemonte, in provincia di Alessandria.