Cyber Security Academy · Lezione

Flussi OAuth 2.0

Grant di autorizzazione e token.

Flussi OAuth 2.0 è una lezione Cyber Security Academy gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cyber Security Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cyber Security Academy include 4 lezioni in totale.

Che cosa risolve davvero OAuth 2.0

OAuth 2.0 è un framework di autorizzazione delegata. Consente a un utente di concedere a un'applicazione di terze parti un accesso limitato alle proprie risorse su un altro servizio senza condividere la propria password.

Riguarda l'autorizzazione (che cosa può fare un'app), non l'autenticazione (chi è l'utente).
L'app riceve un access_token con ambito limitato, mai le credenziali dell'utente.

Chi si occupa della difesa deve ricordare che OAuth, da solo, non dimostra l'identità. Considerare un access token come prova di accesso è un errore classico che OIDC risolve.

I quattro ruoli

Ogni flusso OAuth coinvolge quattro ruoli. Identificarli correttamente è essenziale per la modellazione delle minacce.

Proprietario della risorsa: l'utente che possiede i dati.
Client: l'app che richiede l'accesso.
Server di autorizzazione (AS): emette i token dopo il consenso.
Server delle risorse (RS): l'API che contiene i dati protetti e convalida i token.

Tra questi ruoli si trovano confini di fiducia. Un client compromesso o un AS troppo permissivo compromettono l'intera catena.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Grant Authorization Code

Il grant Authorization Code è il flusso raccomandato per le app web e mobile. Separa il reindirizzamento rivolto all'utente dallo scambio segreto dei token.

L'utente viene reindirizzato all'AS per autenticarsi e prestare il consenso.
L'AS restituisce un code di breve durata all'URI di reindirizzamento registrato.
Il client scambia il code (lato server) con i token tramite un back channel.

Poiché i token vengono ottenuti tramite il back channel, non compaiono mai nella barra degli indirizzi o nella cronologia del browser.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: Proof Key for Code Exchange

PKCE (RFC 7636) rafforza il grant Authorization Code ed è ora raccomandato per tutti i client, inclusi quelli confidenziali.

Il client genera un code_verifier casuale e ne invia l'hash come code_challenge.
Al momento dello scambio dei token deve presentare il verificatore originale.

In questo modo il codice viene associato al richiedente originale, impedendo a un attaccante che intercetti il codice di autorizzazione di riscattarlo.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Grant Client Credentials

Il grant Client Credentials serve per l'accesso da macchina a macchina, quando non è coinvolto alcun utente (ad esempio, un servizio backend che chiama un'API).

Il client si autentica con le proprie credenziali e riceve un access token.
Non è previsto il consenso dell'utente e in genere non viene emesso alcun refresh token.

Limiti strettamente l'ambito di questi token e ruoti i segreti del client. Non utilizzi mai questo flusso per impersonare gli utenti finali.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Access token e refresh token

OAuth emette due tipi principali di token, con durate e regole di gestione molto diverse.

Access token: di breve durata, viene inviato al server delle risorse per ogni chiamata. Lo consideri una credenziale bearer.
Refresh token: di lunga durata, viene utilizzato solo verso l'AS per ottenere nuovi access token.

I refresh token hanno un valore elevato. Li conservi in modo sicuro, li associ al client e supporti la revoca.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Token bearer e trasporto

La maggior parte dei token di accesso OAuth sono token bearer: chiunque possieda il token può usarlo, proprio come il denaro contante.

Trasmetterli sempre tramite TLS; mai negli URL, dove potrebbero finire nei log e nei referrer.
Inviare tramite l'header Authorization.
Per le API ad alto rischio, valutare token vincolati al mittente (DPoP, mTLS).

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

Il grant implicito è deprecato

Il grant legacy Implicit restituiva i token direttamente nel frammento dell'URI di reindirizzamento. Ora è sconsigliato dall'OAuth 2.0 Security BCP ed è stato rimosso da OAuth 2.1.

I token potevano finire nella cronologia del browser, negli header referrer e nei log.
L'assenza di un canale back-channel comportava un'autenticazione del client più debole.

Per le SPA, usare invece Authorization Code with PKCE.

Il parametro state e il CSRF

Il parametro state protegge il passaggio di reindirizzamento dal CSRF. Il client genera un valore casuale, lo memorizza nella sessione e lo verifica nel callback.

Se lo state restituito non corrisponde, rifiutare la risposta.
In questo modo si impedisce a un attaccante di inserire il proprio codice di autorizzazione nella sessione della vittima.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Scope e privilegio minimo

Gli scope esprimono il livello di dettaglio dell'accesso concesso da un token. Applicare il principio del privilegio minimo a ogni passaggio.

Richiedere solo gli scope necessari alla funzionalità (read:profile, non admin).
I resource server devono applicare lo scope a ogni endpoint, invece di fidarsi soltanto di un token valido.

Un consenso eccessivamente ampio è un rischio comune nella pratica: gli utenti approvano app che chiedono molto più di quanto sia necessario.

Configurazioni errate comuni di OAuth

La maggior parte degli incidenti OAuth deriva dalla configurazione, non dal protocollo in sé.

Gli open redirect / controlli permissivi di redirect_uri consentono agli attaccanti di sottrarre i codici.
L'assenza di state o PKCE abilita il CSRF e l'iniezione di codici.
Token di accesso di lunga durata senza possibilità di revoca.
Trattare un token di accesso come un'asserzione di autenticazione.

Registrare URI di reindirizzamento esatti e convalidarli rigorosamente.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Verifica rapida: protezione dell'autenticazione SPA

Selezionare il flusso corretto e moderno per lo scenario seguente.

Riepilogo: flussi OAuth 2.0

Punti chiave:

OAuth 2.0 è autorizzazione delegata, non autenticazione.
Quattro ruoli: proprietario della risorsa, client, authorization server e resource server.
Authorization Code + PKCE è l'impostazione predefinita per web, dispositivi mobili e SPA.
Client Credentials gestisce l'accesso da macchina a macchina.
Proteggere il sistema con state, una corrispondenza rigorosa degli URI di reindirizzamento, token di accesso di breve durata e TLS ovunque.
I grant Implicit e Password sono deprecati.

Domande Frequenti

La lezione «Flussi OAuth 2.0» è gratuita?

Sì — il testo completo di «Flussi OAuth 2.0» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cyber Security Academy, passa a CoddyKit PRO. Il corso Cyber Security Academy include 4 lezioni in totale.

Cosa imparerò in «Flussi OAuth 2.0»?

Grant di autorizzazione e token. Eserciti Cyber Security Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Cyber Security Academy?

Non è richiesta alcuna esperienza precedente. Cyber Security Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Flussi OAuth 2.0»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Cyber Security Academy?

Sì. Ogni lezione Cyber Security Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

← Torna a Cyber Security Academy