Introspezione del token OAuth 2.0

L'introspezione del token OAuth 2.0 definisce un metodo che permette a una risorsa protetta autorizzata di interrogare il server di autorizzazione al fine di determinare i metadati associati a un dato token (sia un token di accesso che un token di aggiornamento), forniti da un client OAuth. Basandosi sui metadati del token specifico, permette al proprietario della risorsa di accedere alla risorsa protetta.

Questi metadati includono:

• Se il token è attualmente attivo (o se è scaduto o è stato revocato)
• Le autorizzazioni che il token di accesso concede (tipicamente trasmesse attraverso gli ambiti OAuth 2.0)
• Il contesto di autorizzazione in cui il token è stato concesso (incluso chi ha autorizzato il token e a quale client è stato emesso)

L'introspezione del token permette alla risorsa protetta di interrogare queste informazioni, indipendentemente dal fatto che siano contenute nel token stesso.

Esistono due tipi di token di accesso, a seconda di come sono codificati:

• Basato su identificatore: Il token rappresenta un identificatore casuale, difficile da indovinare, associato all'autorizzazione nel database del server di autorizzazione.
• Autocontenuto: L'autorizzazione è codificata all'interno del token stesso ed è protetta attraverso la crittografia per evitare manomissioni. JSON Web Token (JWT) è lo standard comune per questo metodo.

Per i token autocontenuti, i metadati relativi all'autorizzazione possono essere direttamente analizzati dal token di accesso. Tuttavia, per i token basati su identificatore, deve essere utilizzata la funzionalità di introspezione del token del server di autorizzazione per convalidare/ricevere i metadati.

Richiesta di introspezione del token#

Utilizzare token di accesso basati su identificatore richiede la verifica con il server di autorizzazione tramite una richiesta di rete. Esiste un protocollo standard per questo chiamato Introspezione del Token OAuth 2.0 (RFC 7662).

La risorsa protetta invierà il token al punto di introspezione del server di autorizzazione e, in cambio, riceverà un oggetto JSON contenente i parametri del token.

Si noti che le richieste di introspezione non possono essere avviate arbitrariamente; devono soddisfare una delle seguenti condizioni:

• Autenticazione utilizzando credenziali (che devono essere preregistrate con il server di autorizzazione), oppure
• Autorizzazione utilizzando un token di accesso.

Di conseguenza, in questa specifica interazione, la risorsa protetta diventa il client OAuth, e il server di autorizzazione diventa la risorsa protetta.

Di seguito è riportato un esempio di richiesta di introspezione, in cui la risorsa protetta si autentica utilizzando un ID client e un segreto client, ottenuti dopo la registrazione come client OAuth presso il server di autorizzazione.

Di seguito è riportato un esempio di richiesta di introspezione che utilizza direttamente un token di accesso. Il token di accesso può essere ottenuto direttamente dall'endpoint /token utilizzando le credenziali di un'applicazione da macchina a macchina registrata e il tipo di concessione client_credentials.

Risposta di introspezione del token#

Il parametro più importante è active, che è un valore booleano. Se true, indica che il token è valido, e l'oggetto JSON includerà altri dettagli del token, come i valori dell'ambito. Se false, il token è invalido o scaduto, e la risorsa protetta deve restituire una risposta 401 Non autorizzata con il codice di errore invalid_token.

Ecco un esempio di risposta per un token valido:

Oltre a active, che è obbligatorio, tutti gli altri parametri sono opzionali.

La risorsa protetta può utilizzare questi campi aggiuntivi per determinare le autorizzazioni di accesso, proprio come farebbe analizzando e validando un token di accesso JWT.