OAuth 2.0

OAuth 2.0 è un framework per l’autorizzazione delegata. Invece di dare la tua password a un’app, approvi una richiesta presso un authorization server, che rilascia all’app un access token limitato per scope (ad esempio orders:read) e per durata. L’app invia quel token all’API, di solito come Authorization: Bearer <token>. I quattro ruoli sono il resource owner (l’utente), il client (l’app), l’authorization server (rilascia i token) e il resource server (l’API).

Autenticazione e autorizzazione

L’autenticazione risponde a “chi sei?”. L’autorizzazione risponde a “cosa ti è permesso fare?”. OAuth 2.0 da solo riguarda l’autorizzazione: un access token dice a cosa può accedere chi lo possiede, non chi sia l’utente in modo affidabile. Far accedere gli utenti è compito di OpenID Connect, uno strato sopra OAuth 2.0 che aggiunge un ID token (un JWT) che descrive l’utente. I pulsanti “Accedi con…” usano OpenID Connect.

Grant type più comuni

• Authorization code con PKCE: per le app che agiscono per conto di un utente, comprese app browser e mobile. L’utente accede presso l’authorization server, l’app riceve un codice di breve durata e lo scambia con i token.
• Client credentials: per chiamate service-to-service senza utente. È il flusso usato più spesso dalle suite di test delle API.
• Refresh token: scambia un refresh token di lunga durata con un nuovo access token.

I grant implicit e resource owner password sono sconsigliati dalle attuali linee guida di sicurezza di OAuth e sono stati eliminati nella bozza di OAuth 2.1.

Esempio: client credentials

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id="$CLIENT_ID" \
  -d client_secret="$CLIENT_SECRET" \
  -d scope=orders:read

La risposta contiene un access_token, un token_type pari a Bearer e un expires_in in secondi. Recupera il token una sola volta in una fixture, tienilo in cache finché non si avvicina alla scadenza e conserva i client secret nei secret della CI, non nel repository.

Cosa testare

• Un token mancante, scaduto o malformato restituisce 401.
• Un token valido senza lo scope richiesto restituisce 403.
• I token emessi per un’audience o un client diverso vengono rifiutati.
• Nel flusso authorization code, il parametro state viene verificato e il redirect URI deve corrispondere esattamente a un valore registrato.
• Le risposte con i token e i redirect non espongono mai i token nei log o negli URL.