Ao sò Oauth!

Ao sò Oauth!

OAuth è un protocollo di autorizzazione che consente alle applicazioni di ottenere l’accesso alle API di terze parti per conto degli utenti senza la necessità di condividere le credenziali.

Use Cases

Le applicazioni moderne si basano spesso su API di servizi terzi. Un esempio comune è l’utilizzo di un identity provider per centralizzare l’autenticazione e cosi offrire più servizi sotto un unica gestione utenti. Molto comodo ma anche molto delicato implementarlo per rispettare gli aspetti legati alla sicurezza della sessione utente. Poi il flusso oauth dopo un primo scambio di segreti, che vedremo in seguito, si autentica attraverso accessToken limitando cosi la comunicazione di “api keys” ma tracciando solo degli access token, i quali possono essere storicizzati e/o limitati anche di ruoli

Componenti di OAuth 2.0

  • Resource Owner: l’utente che possiede i dati.
  • Resource Server: il server che ospita le risorse dell’utente.
  • Client: l’applicazione che richiede l’autorizzazione per accedere ai dati.
  • Authorization Server: il server che gestisce le richieste di autorizzazione e fornisce i token di accesso.

Tipologie di Client

  • Confidential Client: può memorizzare in modo sicuro segreti e token.
  • Public Client: eseguito nel browser o su dispositivi utente senza la possibilità di proteggere le credenziali.

Flussi di Autorizzazione

1. Authorization Code Grant

Questo metodo è il più sicuro e viene usato per applicazioni web e native.

  1. L’utente viene reindirizzato al server di autorizzazione.
  2. Dopo l’autenticazione e il consenso, il server fornisce un codice di autorizzazione.
  3. Il client scambia il codice con un token di accesso.

2. Implicit Grant (Deprecato)

Usato storicamente per applicazioni client-side, oggi è considerato insicuro perché espone il token nella URL.

3. Resource Owner Password Credentials Grant

Utilizzato in scenari legacy, dove l’utente fornisce direttamente le proprie credenziali all’applicazione.

4. Client Credentials Grant

Usato quando un’applicazione accede alle API per conto proprio, senza un utente specifico.

PKCE (Proof Key for Code Exchange)

PKCE è un’estensione di OAuth 2.0 pensata per migliorare la sicurezza del Authorization Code Grant, in particolare nelle applicazioni public client (es. app mobile o JavaScript).

Perché serve PKCE?

Senza PKCE, un attaccante potrebbe intercettare il authorization_code durante il reindirizzamento (attacco code interception). Questo codice potrebbe poi essere scambiato con un access_token, permettendo all’attaccante di impersonare l’utente.

Con PKCE, invece, il client genera un code_verifier e un code_challenge che rendono il codice di autorizzazione utilizzabile solo dal client che lo ha richiesto.

Come funziona PKCE?

  1. Il client genera un code_verifier (una stringa casuale).
  2. Da questa stringa, crea il code_challenge (hash SHA256).
  3. Quando richiede l’autorizzazione, include code_challenge nella richiesta.
  4. Quando scambia il codice di autorizzazione per un token, il client invia anche il code_verifier.
  5. Il server ricalcola l’hash e verifica che corrisponda al code_challenge originale

Richiesta di autorizzazione con PKCE

GET /authorize?
response_type=code
&client_id=<client_id>
&redirect_uri=<callback_uri>
&scope=read
&code_challenge=<hashed_verifier>
&code_challenge_method=S256

Scambio del codice con il token

POST /token
Host: authorizationserver.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=<authorization_code>
&client_id=<client_id>
&redirect_uri=<callback_uri>
&code_verifier=<original_verifier>

💡 Senza il code_verifier, il server rifiuterà la richiesta!

Esempio Completo del Flusso Authorization Code Grant

  1. L’utente accede alla pagina di login:

    GET /authorize?
response_type=code
&client_id=abc123
&redirect_uri=https://client.com/callback
&scope=read
&state=xyz123
&code_challenge=hashed_verifier
&code_challenge_method=S256

    Il parametro state garantisce che la risposta arrivi dallo stesso client che ha avviato la richiesta.

  2. L’utente concede l’autorizzazione e viene reindirizzato:

    HTTP/1.1 302 Found
Location: https://client.com/callback?code=auth_code&state=xyz123

  3. Il client scambia il codice per un token di accesso:

    POST /token
Host: authorizationserver.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=auth_code
&client_id=abc123
&redirect_uri=https://client.com/callback
&code_verifier=original_verifier

  4. Il server restituisce un access token:

    {
  "access_token": "xyz987",
  "token_type": "Bearer",
  "expires_in": 3600
}

Conclusione

OAuth 2.0 è uno standard fondamentale per la sicurezza delle API moderne. L’uso corretto di OAuth garantisce che le applicazioni possano accedere in modo sicuro ai dati degli utenti senza compromettere le credenziali personali.

Tags :