1. Introduzione

In OAuth 2.0 [RFC6749], il contenuto dei token è opaco per i client. Ciò significa che il client non ha bisogno di sapere nulla sul contenuto o sulla struttura del token stesso, se presente. Tuttavia, esiste ancora una grande quantità di metadati che possono essere allegati a un token, come la sua attuale validità, gli scope approvati e informazioni sul contesto in cui il token è stato emesso. Queste informazioni sono spesso vitali affinché le risorse protette prendano decisioni di autorizzazione basate sui token presentati. Poiché OAuth 2.0 non definisce un protocollo per consentire al server di risorse di apprendere meta-informazioni su un token che ha ricevuto da un server di autorizzazione, sono stati sviluppati diversi approcci per colmare questa lacuna. Questi includono l'uso di formati di token strutturati come JWT [RFC7519] o meccanismi di comunicazione inter-servizio proprietari (come database condivisi e bus di servizi aziendali protetti) che trasmettono informazioni sui token.

Questa specifica definisce un protocollo che consente alle risorse protette autorizzate di interrogare il server di autorizzazione per determinare l'insieme di metadati per un dato token che è stato presentato loro da un client OAuth 2.0. Questi metadati includono se il token è attualmente attivo o meno (o se è scaduto o altrimenti revocato), quali diritti di accesso porta il token (solitamente trasmessi tramite gli scope OAuth 2.0) e 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 consente a una risorsa protetta di interrogare queste informazioni indipendentemente dal fatto che siano contenute o meno nel token stesso, consentendo di utilizzare questo metodo insieme o indipendentemente dai valori di token strutturati. Inoltre, una risorsa protetta può utilizzare il meccanismo descritto in questa specifica per introspezionare il token in un particolare contesto decisionale di autorizzazione e accertare i metadati rilevanti sul token per prendere questa decisione di autorizzazione in modo appropriato.

1.1. Convenzioni di notazione

Le parole chiave 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', e 'OPTIONAL' in questo documento devono essere interpretate come descritto in [RFC2119].

Salvo diversa indicazione, tutti i nomi e i valori dei parametri di protocollo fanno distinzione tra maiuscole e minuscole.

1.2. Terminologia

Questa sezione definisce la terminologia utilizzata da questa specifica. Questa sezione è una parte normativa di questa specifica, imponendo requisiti alle implementazioni.

Questa specifica utilizza i termini "access token (token di accesso)", "authorization endpoint (endpoint di autorizzazione)", "authorization grant (concessione di autorizzazione)", "authorization server (server di autorizzazione)", "client", "client identifier (identificatore client)", "protected resource (risorsa protetta)", "refresh token (token di aggiornamento)", "resource owner (proprietario della risorsa)", "resource server (server di risorse)", e "token endpoint (endpoint del token)" definiti da OAuth 2.0 [RFC6749], e i termini "claim names (nomi di claim)" e "claim values (valori di claim)" definiti da JSON Web Token (JWT) [RFC7519].

Questa specifica definisce i seguenti termini:

Token Introspection (Introspezione del token) : L'atto di interrogare lo stato corrente di un token OAuth 2.0 attraverso l'uso del protocollo di rete definito in questo documento.

Introspection Endpoint (Endpoint di introspezione) : L'endpoint OAuth 2.0 attraverso il quale viene eseguita l'operazione di introspezione del token.