1. Introduction (Introduzione)
La specifica originale del framework di autorizzazione OAuth 2.0 (OAuth 2.0 Authorization Framework) [RFC6749] non impone alcun formato specifico per i token di accesso (Access Token). Sebbene ciò rimanga del tutto appropriato per molti scenari importanti, l'utilizzo sul mercato ha dimostrato che molte implementazioni commerciali di OAuth 2.0 hanno scelto di emettere token di accesso in un formato che può essere analizzato e validato direttamente dai server di risorse (Resource Server), senza ulteriore coinvolgimento del server di autorizzazione (Authorization Server). Questo approccio è particolarmente comune in topologie in cui il server di autorizzazione e il server di risorse non sono co-localizzati, non sono gestiti dalla stessa entità o sono altrimenti separati da qualche confine. Al momento della stesura, molte implementazioni commerciali sfruttano il formato JSON Web Token (JWT) [RFC7519].
Molti token di accesso JWT specifici del fornitore condividono lo stesso layout funzionale, utilizzando claim (Claim) JWT per trasmettere le informazioni necessarie per supportare un insieme comune di casi d'uso: validazione dei token, trasporto di informazioni di autorizzazione sotto forma di ambiti (Scope) e autorizzazioni (Entitlement), trasporto di informazioni di identità sul soggetto (Subject), ecc. Le differenze sono principalmente limitate ai nomi dei claim e alla sintassi utilizzata per rappresentare le stesse entità, il che suggerisce che l'interoperabilità potrebbe essere facilmente raggiunta standardizzando un insieme comune di claim e regole di validazione.
L'assunzione che i token di accesso siano associati a informazioni specifiche non appare solo nelle implementazioni commerciali. Varie specifiche della famiglia OAuth 2.0 (come gli indicatori di risorsa (Resource Indicator) [RFC8707], l'uso dei token bearer OAuth 2.0 (Bearer Token Usage) [RFC6750] e altri) postulano la presenza di meccanismi di ambito, come un pubblico (Audience), nei token di accesso. Anche la famiglia di specifiche associate all'introspezione (Introspection) suggerisce indirettamente un insieme fondamentale di informazioni che ci si aspetta che i token di accesso trasportino o almeno siano associati.
Questa specifica mira a fornire un profilo (Profile) standardizzato e interoperabile come alternativa ai layout proprietari dei token di accesso JWT in futuro. Oltre a definire un insieme comune di claim obbligatori e opzionali, il profilo fornisce indicazioni chiare su come i parametri della richiesta di autorizzazione determinano il contenuto del token di accesso JWT emesso, come un server di autorizzazione può pubblicare metadati pertinenti ai token di accesso JWT che emette e come un server di risorse dovrebbe validare i token di accesso JWT in arrivo.
Infine, questa specifica fornisce considerazioni sulla sicurezza e sulla privacy volte a prevenire errori comuni e anti-pattern che possono verificarsi con un uso ingenuo del formato JWT per rappresentare i token di accesso.
Si prega di notare: Sebbene sia questo documento che [RFC7523] utilizzino JSON Web Token nel contesto del framework OAuth2, le due specifiche differiscono sia nell'intento che nei meccanismi. Mentre [RFC7523] definisce come un token bearer JWT (JWT Bearer Token) può essere utilizzato per richiedere un token di accesso, questo documento descrive come codificare i token di accesso nel formato JWT.
1.1. Requirements Notation and Conventions (Notazione e convenzioni dei requisiti)
Le parole chiave "MUST" (deve), "MUST NOT" (non deve), "REQUIRED" (richiesto), "SHALL" (deve), "SHALL NOT" (non deve), "SHOULD" (dovrebbe), "SHOULD NOT" (non dovrebbe), "RECOMMENDED" (raccomandato), "NOT RECOMMENDED" (non raccomandato), "MAY" (può) e "OPTIONAL" (opzionale) in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono tutte in maiuscolo, come mostrato qui.
1.2. Terminology (Terminologia)
Token di accesso JWT (JWT access token): Un token di accesso OAuth 2.0 codificato nel formato JWT e conforme ai requisiti descritti in questa specifica.
Questa specifica utilizza i termini "access token" (token di accesso), "refresh token" (token di aggiornamento), "authorization server" (server di autorizzazione), "resource server" (server di risorse), "authorization endpoint" (endpoint di autorizzazione), "authorization request" (richiesta di autorizzazione), "authorization response" (risposta di autorizzazione), "token endpoint" (endpoint del token), "grant type" (tipo di concessione), "access token request" (richiesta di token di accesso), "access token response" (risposta del token di accesso) e "client" definiti dal framework di autorizzazione OAuth 2.0 (The OAuth 2.0 Authorization Framework) [RFC6749].