2. JWT Access Token Header and Data Structure (Intestazione e struttura dati del token di accesso JWT)
2.1. Header (Intestazione)
I token di accesso JWT devono (MUST) essere firmati. Sebbene i token di accesso JWT possano utilizzare qualsiasi algoritmo di firma, l'uso della crittografia asimmetrica è raccomandato (RECOMMENDED) poiché semplifica il processo di acquisizione delle informazioni di validazione per i server di risorse (vedere Sezione 4). I token di accesso JWT non devono (MUST NOT) utilizzare "none" come algoritmo di firma. Vedere la Sezione 4 per ulteriori dettagli.
I server di autorizzazione e i server di risorse conformi a questa specifica devono (MUST) includere RS256 (come definito in [RFC7518]) tra i loro algoritmi di firma supportati.
Questa specifica registra il tipo di media (Media Type) "application/at+jwt", che può essere utilizzato per indicare che il contenuto è un token di accesso JWT. I token di accesso JWT devono (MUST) includere questo tipo di media nel parametro di intestazione "typ" per dichiarare esplicitamente che il JWT rappresenta un token di accesso conforme a questo profilo. Secondo la definizione di "typ" nella Sezione 4.1.9 di [RFC7515], è raccomandato (RECOMMENDED) che il prefisso "application/" sia omesso. Pertanto, il valore "typ" utilizzato dovrebbe (SHOULD) essere "at+jwt". Vedere la sezione Considerazioni sulla sicurezza per i dettagli sull'importanza di impedire che i token ID di OpenID Connect (come definiti dalla Sezione 2 di [OpenID.Core]) vengano accettati come token di accesso dai server di risorse che implementano questo profilo.
2.2. Data Structure (Struttura dati)
I seguenti claim vengono utilizzati nella struttura dati del token di accesso JWT.
iss RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.1 di [RFC7519].
exp RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.4 di [RFC7519].
aud RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.3 di [RFC7519]. Vedere la Sezione 3 per indicazioni su come un server di autorizzazione dovrebbe determinare il valore di "aud" a seconda della richiesta.
sub RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.2 di [RFC7519]. Nei casi di token di accesso ottenuti tramite concessioni in cui è coinvolto un proprietario di risorse (Resource Owner), come la concessione del codice di autorizzazione (Authorization Code Grant), il valore di "sub" dovrebbe (SHOULD) corrispondere all'identificatore del soggetto del proprietario di risorse. Nei casi di token di accesso ottenuti tramite concessioni in cui non è coinvolto alcun proprietario di risorse, come la concessione delle credenziali del client (Client Credentials Grant), il valore di "sub" dovrebbe (SHOULD) corrispondere a un identificatore che il server di autorizzazione utilizza per indicare l'applicazione client. Vedere la Sezione 5 per ulteriori dettagli su questo scenario. Vedere anche la Sezione 6 per una discussione su come diverse scelte nell'assegnazione dei valori "sub" possano influire sulla privacy.
client_id RICHIESTO (REQUIRED) - come definito nella Sezione 4.3 di [RFC8693].
iat RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.6 di [RFC7519]. Questo claim identifica il momento in cui il token di accesso JWT è stato emesso.
jti RICHIESTO (REQUIRED) - come definito nella Sezione 4.1.7 di [RFC7519].
2.2.1. Authentication Information Claims (Claim di informazioni di autenticazione)
I claim elencati in questa sezione possono (MAY) essere emessi nel contesto di concessioni di autorizzazione che coinvolgono il proprietario di risorse e riflettono i tipi e la forza dell'autenticazione nel token di accesso che il server di autenticazione ha applicato prima di restituire la risposta di autorizzazione al client. I loro valori sono fissi e rimangono gli stessi per tutti i token di accesso che derivano da una determinata risposta di autorizzazione, sia che il token di accesso sia stato ottenuto direttamente nella risposta (ad esempio, tramite il flusso implicito (Implicit Flow)) o dopo uno o più scambi di token (ad esempio, ottenendo un nuovo token di accesso utilizzando un token di aggiornamento (Refresh Token) o scambiando un token di accesso con un altro tramite le procedure [RFC8693]).
auth_time OPZIONALE (OPTIONAL) - come definito nella Sezione 2 di [OpenID.Core].
acr OPZIONALE (OPTIONAL) - come definito nella Sezione 2 di [OpenID.Core].
amr OPZIONALE (OPTIONAL) - come definito nella Sezione 2 di [OpenID.Core].
2.2.2. Identity Claims (Claim di identità)
Nel contesto delle concessioni di autorizzazione che coinvolgono il proprietario di risorse, i server di autorizzazione commerciali spesso includono attributi del proprietario di risorse direttamente nei token di accesso in modo che i server di risorse possano consumarli direttamente per scopi di autorizzazione o altri senza ulteriori round trip agli endpoint di introspezione (Introspection) ([RFC7662]) o UserInfo ([OpenID.Core]). Questo è particolarmente comune in scenari in cui il client e il server di risorse appartengono alla stessa entità e fanno parte della stessa soluzione, come nel caso dei client di prima parte (First-Party Client) che invocano la propria API backend.
Questo profilo non introduce alcun meccanismo per un client di richiedere direttamente la presenza di claim specifici nei token di accesso JWT, poiché il server di autorizzazione può determinare quali claim aggiuntivi sono richiesti da un particolare server di risorse considerando il client_id del client e i parametri "scope" e "resource" inclusi nella richiesta.
Qualsiasi attributo di identità aggiuntivo la cui semantica è ben descritta da una voce nel registro IANA "JSON Web Token (JWT)" introdotto in [RFC7519] dovrebbe (SHOULD) essere codificato utilizzando il nome del claim corrispondente, se tale attributo deve essere incluso nel token di accesso JWT. Si noti che il registro IANA JWT include i claim trovati nella Sezione 5.1 di [OpenID.Core].
I server di autorizzazione possono (MAY) restituire attributi arbitrari non definiti in alcuna specifica esistente, purché i nomi dei claim corrispondenti siano resistenti alle collisioni o i token di accesso siano destinati a essere utilizzati solo all'interno di un sottosistema privato. Si prega di fare riferimento alle Sezioni 4.2 e 4.3 di [RFC7519] per i dettagli.
I server di autorizzazione che includono attributi del proprietario di risorse nei token di accesso JWT devono prestare attenzione e verificare che tutti i requisiti di privacy siano soddisfatti, come discusso nella Sezione 6.
2.2.3. Authorization Claims (Claim di autorizzazione)
Se una richiesta di autorizzazione include un parametro scope, il token di accesso JWT emesso corrispondentemente dovrebbe (SHOULD) includere un claim "scope" come definito nella Sezione 4.2 di [RFC8693].
Tutte le stringhe di ambito individuali nel claim "scope" devono (MUST) avere significato per le risorse indicate nel claim "aud". Vedere la Sezione 5 per ulteriori considerazioni sulla relazione tra le stringhe di ambito e le risorse indicate dal claim "aud".
2.2.3.1. Claims for Authorization Outside of Delegation Scenarios (Claim per autorizzazione al di fuori degli scenari di delega)
Molti server di autorizzazione incorporano attributi di autorizzazione che vanno oltre gli scenari delegati descritti da [RFC7519] nei token di accesso che emettono. Esempi tipici includono le appartenenze del proprietario di risorse a ruoli (Role) e gruppi (Group) rilevanti per la risorsa a cui si accede, autorizzazioni (Entitlement) assegnate al proprietario di risorse per la risorsa di destinazione che il server di autorizzazione conosce, ecc.
Un server di autorizzazione che desidera includere tali attributi in un token di accesso JWT dovrebbe (SHOULD) utilizzare gli attributi "groups", "roles" e "entitlements" dello schema di risorsa "User" definito dalla Sezione 4.1.2 di [RFC7643] come tipi di claim.
I server di autorizzazione dovrebbero (SHOULD) codificare i valori dei claim corrispondenti secondo le linee guida definite in [RFC7643]. In particolare, un esempio non normativo di un attributo "groups" può essere trovato nella Sezione 8.2 di [RFC7643]. Non viene fornito alcun vocabolario specifico per "roles" e "entitlements".
La Sezione 7.2.1 di questo documento fornisce voci per la registrazione degli attributi "groups", "roles" e "entitlements" da [RFC7643] come tipi di claim da utilizzare in questo profilo.