7. Creating and Validating JWTs (Creazione e convalida dei JWT)

7.1. Creating a JWT (Creazione di un JWT)

Per creare un JWT, vengono eseguiti i seguenti passaggi. L'ordine dei passaggi non è significativo nei casi in cui non vi sono dipendenze tra gli input e gli output dei passaggi.

1. Creare un JWT Claims Set contenente le rivendicazioni (claims) desiderate. Si noti che gli spazi bianchi sono esplicitamente consentiti nella rappresentazione e non è necessario eseguire alcuna canonizzazione prima della codifica.

2. Sia il Message gli ottetti della rappresentazione UTF-8 del JWT Claims Set.

3. Creare un JOSE Header contenente il set desiderato di parametri di intestazione. Il JWT deve (MUST) essere conforme alla specifica [JWS] o [JWE]. Si noti che gli spazi bianchi sono esplicitamente consentiti nella rappresentazione e non è necessario eseguire alcuna canonizzazione prima della codifica.

4. A seconda che il JWT sia un JWS o un JWE, ci sono due casi:

   • Se il JWT è un JWS, creare un JWS utilizzando il Message come payload JWS; tutti i passaggi specificati in [JWS] per creare un JWS devono essere seguiti (MUST).

   • Altrimenti, se il JWT è un JWE, creare un JWE utilizzando il Message come plaintext per il JWE; tutti i passaggi specificati in [JWE] per creare un JWE devono essere seguiti (MUST).

5. Se verrà eseguita un'operazione di firma o crittografia nidificata, sia il Message il JWS o JWE, e tornare al passaggio 3, utilizzando un valore "cty" (content type) di "JWT" nel nuovo JOSE Header creato in quel passaggio.

6. Altrimenti, sia il JWT risultante il JWS o JWE.

7.2. Validating a JWT (Convalida di un JWT)

Nella convalida di un JWT, vengono eseguiti i seguenti passaggi. L'ordine dei passaggi non è significativo nei casi in cui non vi sono dipendenze tra gli input e gli output dei passaggi. Se uno qualsiasi dei passaggi elencati fallisce, allora il JWT deve essere rifiutato (MUST) -- ovvero, trattato dall'applicazione come input non valido.

1. Verificare che il JWT contenga almeno un carattere punto ('.').

2. Sia l'intestazione JOSE codificata la porzione del JWT prima del primo carattere punto ('.').

3. Decodificare in base64url l'intestazione JOSE codificata seguendo la restrizione che nessun carattere di interruzione di riga, spazio bianco o altro carattere aggiuntivo sia stato utilizzato.

4. Verificare che la sequenza di ottetti risultante sia una rappresentazione codificata in UTF-8 di un oggetto JSON completamente valido conforme a RFC 7159 [RFC7159]; sia il JOSE Header questo oggetto JSON.

5. Verificare che il JOSE Header risultante non contenga nomi di parametri di intestazione duplicati. Quando si utilizza un parser JSON che restituisce solo l'ultimo nome di membro duplicato lessicalmente, come specificato nella Sezione 15.12 di ECMAScript 5.1 [ECMAScript], questo passaggio può essere eseguito automaticamente.

6. Determinare se il JWT è un JWS o un JWE esaminando il parametro di intestazione "enc" (encryption algorithm) nel JOSE Header.

   • Se il parametro di intestazione "enc" è presente, il JWT è un JWE.

   • Altrimenti, il JWT è un JWS.

7. A seconda che il JWT sia un JWS o un JWE, ci sono due casi:

   • Se il JWT è un JWS, seguire i passaggi specificati in [JWS] per convalidare un JWS utilizzando l'algoritmo nel JOSE Header e la chiave, nonché il payload JWS e la firma JWS. Sia il Message il payload JWS.

   • Altrimenti, se il JWT è un JWE, seguire i passaggi specificati in [JWE] per convalidare un JWE utilizzando l'algoritmo nel JOSE Header e la chiave. Sia il Message il plaintext risultante dalla decrittazione.

8. Se il JOSE Header contiene un parametro di intestazione "cty" (content type) con un valore di "JWT", allora il JWT è un JWT nidificato (Nested JWT). In questo caso, tornare al passaggio 1, utilizzando il Message come JWT.

9. Altrimenti, decodificare in base64url il Message seguendo la restrizione che nessun carattere di interruzione di riga, spazio bianco o altro carattere aggiuntivo sia stato utilizzato.

10. Verificare che la sequenza di ottetti risultante sia una rappresentazione codificata in UTF-8 di un oggetto JSON completamente valido conforme a RFC 7159 [RFC7159]; sia il JWT Claims Set questo oggetto JSON.

11. Verificare che il JWT Claims Set non contenga nomi di rivendicazioni duplicati. Quando si utilizza un parser JSON che restituisce solo l'ultimo nome di membro duplicato lessicalmente, come specificato nella Sezione 15.12 di ECMAScript 5.1 [ECMAScript], questo passaggio può essere eseguito automaticamente.

Infine, si noti che quando più chiavi sono disponibili per un'applicazione, essa può tentare di convalidare un JWS o JWE più volte con chiavi diverse. Se l'applicazione determina che il fallimento è dovuto all'uso di una chiave specifica, può continuare a provare altre chiavi fino a quando non ha successo o tutte le chiavi sono state esaurite.

7.3. String Comparison Rules (Regole di confronto delle stringhe)

L'elaborazione di un JWT richiede il confronto di valori di stringa JSON.

I confronti dei nomi delle rivendicazioni e dei nomi dei parametri di intestazione vengono sempre eseguiti come confronti di stringhe con distinzione tra maiuscole e minuscole senza conversione di tipo.

I confronti di URI nei valori StringOrURI e nei valori di stringa JSON vengono eseguiti come segue:

• Se un valore è un URI e l'altro non è un URI, i due valori sono diversi.

• Se entrambi i valori sono URI, essi vengono confrontati utilizzando un confronto di stringhe con distinzione tra maiuscole e minuscole senza conversione di tipo, canonizzazione o elaborazione di escape con barra rovesciata.

• Se nessuno dei valori è un URI, essi vengono confrontati utilizzando un confronto di stringhe con distinzione tra maiuscole e minuscole senza conversione di tipo o elaborazione di escape con barra rovesciata.

Si noti che per qualsiasi caso d'uso specifico, regole di confronto più permissive o più rigorose possono essere appropriate per URI e altre stringhe, ma tali regole di confronto devono essere specificate esplicitamente (MUST).

---