Che cos'è PKCE: dalle nozioni di base alla comprensione approfondita

Proof Key for Code Exchange (PKCE) è un'estensione del Authorization Code Flow, originariamente progettata per proteggere il flusso di codice di autorizzazione nelle app mobili e ora è consigliato anche per le app a pagina singola. Da OAuth 2.1, PKCE è obbligatorio per tutti i tipi di client, inclusi client pubblici e client riservati (privati).

In questo articolo ti aiuteremo a capire perché PKCE è stato creato e come protegge le tue applicazioni, offrendoti una comprensione approfondita di PKCE.

Perché è necessario PKCE?#

Nel flusso di codice di autorizzazione OAuth 2.0, gli utenti richiedono di accedere tramite un'applicazione. Il server di autenticazione indirizza gli utenti a una pagina di autenticazione. Dopo l'autenticazione dell'utente, il server restituisce un codice di autorizzazione all'applicazione, che utilizza quindi questo codice per richiedere un token di accesso al server di autenticazione.

Questo flusso presenta un rischio di sicurezza significativo: il codice di autorizzazione può essere intercettato da programmi dannosi. Questo è particolarmente preoccupante sui dispositivi mobili, dove altre applicazioni possono registrare lo stesso URI di reindirizzamento e intercettare il codice di autorizzazione.

Il processo di intercettazione è mostrato nel diagramma seguente:

Fase (1): L'app esegue una richiesta di autorizzazione tramite un'API sicura che non può essere intercettata. In questa fase, il richiedente fornisce anche un URI di reindirizzamento.

Fase (2): La richiesta viene quindi inoltrata al server di autorizzazione OAuth 2.0. Poiché OAuth richiede l'uso di TLS, questa comunicazione è protetta da TLS e non può essere intercettata.

Fase (3): Il server di autorizzazione restituisce il codice di autorizzazione.

Fase (4.a): il codice di autorizzazione viene restituito al richiedente tramite l'URI di reindirizzamento fornito nella fase (1). In questa fase, se l'applicazione dannosa si è registrata come gestore per l'URI di reindirizzamento, può intercettare il codice di autorizzazione. Con il codice di autorizzazione, l'attaccante può richiedere e ottenere un token di accesso nelle fasi (5.a) e (6.a), rispettivamente.

Come mostrato sopra, nel flusso di codice di autorizzazione OAuth 2.0, se il codice di autorizzazione viene intercettato, gli attaccanti possono utilizzarlo per ottenere token di accesso. Pertanto, abbiamo bisogno di un meccanismo per prevenire l'intercettazione del codice di autorizzazione, che ha portato alla creazione di PKCE.

Come funziona PKCE?#

Come menzionato sopra, se vogliamo evitare attacchi, dobbiamo garantire che solo l'app che ha avviato la richiesta possa richiedere e ottenere il token di accesso. Ed è qui che entra in gioco PKCE.

PKCE risolve questo problema introducendo il concetto di "proof key".

Quando richiede un codice di autorizzazione, l'applicazione genera prima un code verifier casuale e lo memorizza localmente. Successivamente, converte questo code verifier in una code challenge utilizzando algoritmi specifici. L'applicazione invia sia la code challenge che il metodo di code challenge al server di autenticazione durante la richiesta del codice di autorizzazione.

Il code verifier è una stringa generata casualmente e la code challenge è derivata dal code verifier attraverso la conversione. Sono supportati due metodi di conversione:

• plain: Utilizza il code verifier direttamente come code challenge

• S256: Applica un hashing SHA-256 al code verifier, seguito dalla codifica Base64URL. Poiché l'output dell'hash non può essere recuperato per ottenere il code verifier e poiché il metodo plain potrebbe essere vulnerabile agli attacchi man-in-the-middle durante la trasmissione, si consiglia vivamente di usare S256 per motivi di sicurezza.

Dopo l'autenticazione dell'utente, il server di autenticazione ritorna il codice di autorizzazione all'applicazione. Quando si richiede un token di accesso, l'applicazione invia sia il codice di autorizzazione che il code verifier al server di autenticazione. Il server trasforma il "code verifier" utilizzando il "metodo di code challenge" precedentemente ricevuto e confronta il risultato con il "code challenge" precedentemente ricevuto per verificare il possesso del client del "code verifier".

Fase (1-3): L'app crea e registra un segreto denominato "code verifier" e deriva una versione trasformata "code challenge", che viene inviata nella Richiesta di Autorizzazione OAuth 2.0 insieme al metodo di trasformazione "code challenge method".

Fase (3-6): Il Server Autenticazione risponde come di consueto, ma registra "code challenge" e il "code challenge method".

Fase (7.a): L'app invia quindi il codice di autorizzazione al endpoint del token come di consueto, ma include il segreto "code verifier" generato nella fase (1).

Fase (8.a-9.a): Il server di autorizzazione trasforma il "code verifier" in "code challenge" e lo confronta con "code challenge" dalla fase (1-3). L'accesso viene negato se non sono uguali.

In questo caso, anche se l'applicazione dannosa ha intercettato il codice di autorizzazione nella fase (6.b), non è in grado di incassarlo per un token di accesso, poiché non ha il segreto "code_verifier" e poiché il "code verifier" viene inviato tramite TLS, non può essere intercettato.

Riepilogo#

Questo articolo spiega come PKCE funziona e perché è necessario per proteggere il flusso di codice di autorizzazione. Aggiungendo un meccanismo chiave di prova, PKCE impedisce alle applicazioni dannose di intercettare e abusare dei codici di autorizzazione. Speriamo che questa spiegazione ti aiuti a capire PKCE a fondo.