I token Jwt sono diventati lo standard per l’autenticazione e la autorizzazione all’interno di applicazioni web. In questo post analizzeremo i passaggi necessari alla validazione del token stesso.
In poche parole, JSON Web Token è uno standard aperto che definisce come condividere le informazioni tra i vari attori utilizzando il formato JSON.
La struttura JWT è composta da tre stringhe concatenate con codifica URL Base64, separate da punti:
- Intestazione
- Payload
- Firma
Le informazioni trasportate da un JWT sono firmate digitalmente in modo da poterne verificare l’origine e potersi fidare. La firma digitale garantisce l’integrità delle informazioni, ma non garantisce la privacy se non esplicitamente crittografata.
La specifica JWT non definisce lo scopo specifico di un token. Sebbene la maggior parte degli sviluppatori pensi all’autenticazione quando ha a che fare con i JWT, questa non è una proprietà intrinseca dei token nel formato JWT.
JWT è solo un formato.
Il significato del token dipende dal contesto o dall’applicazione specifica.
In OpenID Connect (OIDC), il formato JWT viene utilizzato per il token ID, ovvero il token che dimostra che un utente è autenticato. In OAuth 2.0, il formato JWT può essere utilizzato facoltativamente per l’access token , il token che consente a un’applicazione client di accedere a una risorsa specifica per conto dell’utente.
Ma come avviene la validazione?
La prima cosa che la nostra applicazione deve fare quando riceve un JWT è garantire che le informazioni che trasporta siano affidabili. È qui che entra in gioco la convalida.
Convalidare un JSON Web Token significa garantire che il token abbia la struttura definita nelle specifiche standard e che ci si possa fidare delle informazioni che trasporta.
La convalida JWT si basa sui seguenti cinque criteri:
- Verifica della struttura: il primo controllo riguarda la struttura del token. Il token corrisponde alla struttura di un Web Token JSON? Se il token non segue le linee guida standard, non è valido.
- Integrità dei token: questo controllo riguarda l’integrità del token. Il token è stato manomesso? Sipuò verificare controllando la firma. Se si verifica che la firma del token è valida, significa che non è stata alterata in alcun modo.
- Scadenza del token: I JWT hanno una data di scadenza definita nella dichiarazione exp. Il token è scaduto quando è stato ricevuto? Se un token è scaduto, non dovremmo più fidarci del suo contenuto.
- Autorità. Il controllo successivo consiste nel verificare che il token sia stato emesso e firmato dal mittente previsto (autorità). Ci sono due passaggi per questo controllo:
- Verifica che l’autorità sia quella prevista dalla tua applicazione confrontandola con il claim iss (emittente).
- Verificare che la chiave utilizzata per firmare il JWT appartenga effettivamente all’autorità prevista.
- Pubblico atteso. Infine, verifica che il token sia destinato alla tua applicazione. In altre parole, dobbiamo verificare che il claim aud corrisponda al valore che identifica la nostra applicazione. Ad esempio, in un token ID, il valore per il pub è l’ID client; in un token di accesso in formato JWT, il valore per il pub è l’identificatore API.
La convalida del token non coinvolge le informazioni personalizzate trasportate dal token.
Si tratta di una logica specifica dell’applicazione, che non rientra nell’ambito della convalida dei token. Ad esempio, la convalida di un token ID non include la verifica dell’esistenza dell’indirizzo e-mail dell’utente nell’attestazione e-mail.
Nel prossimo post vedremo come verificare la validatità di un token all’interno di un applicazione .NET Core.