Passa al contenuto principale

4. Validating JWT Access Tokens (Validazione dei token di accesso JWT)

Allo scopo di facilitare il recupero dei dati di validazione, qui è raccomandato (RECOMMENDED) che i server di autorizzazione firmino i token di accesso JWT con un algoritmo asimmetrico.

I server di autorizzazione dovrebbero (SHOULD) utilizzare i metadati del server di autorizzazione OAuth 2.0 (OAuth 2.0 Authorization Server Metadata) [RFC8414] per pubblicizzare ai server di risorse le loro chiavi di firma tramite "jwks_uri" e quale valore di claim "iss" aspettarsi tramite il valore dei metadati "issuer". In alternativa, i server di autorizzazione che implementano OpenID Connect possono (MAY) utilizzare il documento di scoperta OpenID Connect (Discovery) [OpenID.Discovery] per lo stesso scopo. Se un server di autorizzazione supporta sia i metadati del server di autorizzazione OAuth 2.0 sia la scoperta OpenID Connect, i valori forniti devono (MUST) essere coerenti tra i due metodi di pubblicazione.

Un server di autorizzazione può (MAY) scegliere di utilizzare chiavi diverse per firmare i token ID di OpenID Connect e i token di accesso JWT. Questa specifica non fornisce un meccanismo per identificare una chiave specifica come quella utilizzata per firmare i token di accesso JWT. Un server di autorizzazione può firmare i token di accesso JWT con qualsiasi delle chiavi pubblicizzate tramite i metadati del server di autorizzazione (AS) o la scoperta OpenID Connect. Vedere la Sezione 5 per ulteriori indicazioni sulle implicazioni di sicurezza.

I server di risorse che ricevono un token di accesso JWT devono (MUST) validarlo nel modo seguente.

  • Il server di risorse deve (MUST) verificare che il valore dell'intestazione "typ" sia "at+jwt" o "application/at+jwt" e rifiutare i token che portano qualsiasi altro valore.

  • Se il token di accesso JWT è crittografato, decrittarlo utilizzando le chiavi e gli algoritmi che il server di risorse ha specificato durante la registrazione. Se la crittografia è stata negoziata con il server di autorizzazione al momento della registrazione e il token di accesso JWT in arrivo non è crittografato, il server di risorse dovrebbe (SHOULD) rifiutarlo.

  • L'identificatore dell'emittente per il server di autorizzazione (che tipicamente si ottiene durante la scoperta) deve (MUST) corrispondere esattamente al valore del claim "iss".

  • Il server di risorse deve (MUST) validare che il claim "aud" contenga un valore di indicatore di risorsa corrispondente a un identificatore che il server di risorse si aspetta per se stesso. Il token di accesso JWT deve (MUST) essere rifiutato se "aud" non contiene un indicatore di risorsa del server di risorse corrente come pubblico valido.

  • Il server di risorse deve (MUST) validare la firma di tutti i token di accesso JWT in arrivo secondo [RFC7515] utilizzando l'algoritmo specificato nel parametro di intestazione "alg" del JWT. Il server di risorse deve (MUST) rifiutare qualsiasi JWT in cui il valore di "alg" è "none". Il server di risorse deve (MUST) utilizzare le chiavi fornite dal server di autorizzazione.

  • L'ora corrente deve (MUST) essere precedente all'ora rappresentata dal claim "exp". Gli implementatori possono (MAY) prevedere una piccola tolleranza, solitamente non più di pochi minuti, per tenere conto dello sfasamento dell'orologio.

Il server di risorse deve (MUST) gestire gli errori come descritto nella Sezione 3.1 di [RFC6750]. In particolare, in caso di qualsiasi fallimento nei controlli di validazione elencati sopra, la risposta del server di autorizzazione deve (MUST) includere il codice di errore "invalid_token". Si prega di notare che questo requisito non impedisce ai token di accesso JWT di utilizzare schemi di autenticazione diversi da "Bearer".

Se il token di accesso JWT include claim di autorizzazione come descritto nella Sezione 2.2.3, il server di risorse dovrebbe (SHOULD) utilizzarli in combinazione con qualsiasi altra informazione contestuale disponibile per determinare se la chiamata corrente debba essere autorizzata o rifiutata. I dettagli su come un server di risorse esegue questi controlli sono al di fuori dell'ambito di questa specifica di profilo.