OAuth 2.0, PKCE, JWT, JWK e JWKS compaiono spesso nella stessa architettura, ma non sono intercambiabili. Alcuni concetti descrivono flussi di autorizzazione, altri un formato di token o un modo di rappresentare chiavi crittografiche.
GuidaBuone praticheIntermedio
OAuth 2.0, PKCE, JWT, JWK e JWKS: capire i loro ruoli
Comprendi come si collegano OAuth 2.0, PKCE, JWT, JWK e JWKS: autorizzazione, token, chiavi pubbliche e verifica.
Mostra indice
OAuth 2.0 organizza l’autorizzazione
OAuth 2.0 è un framework di autorizzazione delegata. Consente a un’applicazione di ottenere accesso limitato senza chiedere all’utente la password di un altro servizio.
OAuth non richiede che ogni access token sia un JWT. Il formato del token è una scelta separata.
PKCE protegge lo scambio del codice di autorizzazione
PKCE aggiunge una prova temporanea al flusso Authorization Code. Il client crea un code_verifier casuale e invia una challenge derivata. Quando scambia il codice ricevuto deve presentare il verifier originale.
Il generatore PKCE permette di visualizzare verifier, challenge e trasformazione S256.
PKCE non cifra un JWT e non sostituisce TLS. Protegge una fase specifica del flusso di autorizzazione.
JWT è un formato di token
JWT definisce una struttura compatta composta da segmenti separati da punti. I JWT firmati possono contenere claim e una firma verificabile.
L’ispettore JWT, il decoder JWT e l’encoder JWT aiutano a esaminare la struttura.
Decodificare un JWT non significa verificarne la firma. Il payload di un normale JWT non deve essere considerato confidenziale solo perché è codificato.
JWK e JWKS rappresentano chiavi
JWK è una rappresentazione JSON di una chiave crittografica. Un JWKS è un insieme di JWK, spesso pubblicato per fornire ai client le chiavi pubbliche necessarie alla verifica.
L’ispettore JWK/JWKS aiuta a controllare tipo, identificatori e parametri.
Un header JWT può contenere un kid, usato per scegliere la chiave corrispondente nel JWKS.
Come si collegano i componenti
- il client avvia OAuth e crea i valori PKCE;
- il server di autorizzazione autentica l’utente e restituisce un codice;
- il client scambia il codice presentando il verifier;
- il server restituisce token, che possono includere JWT;
- il destinatario legge l’header e seleziona una chiave dal JWKS;
- verifica la firma e poi issuer, audience, scadenza e altre regole.
Confusioni comuni da evitare
- OAuth non è un formato di token.
- PKCE non è crittografia.
- I payload JWT non sono automaticamente confidenziali.
- Decodificare non significa verificare una firma.
- JWKS è un insieme di chiavi, non un elenco di sessioni.
Il punto essenziale è distinguere protocollo, contenitore e chiavi.