JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties.

RFC 7519

C'est la fondation "Internet Engineering Task Force (IETF)" qui est à l'origine d'un ensemble de standard pour représenter le contenu crypté et/ou signé en tant que données JSON.

 JSON Object Signing and Encryption (JOSE)

A l'origine

en 2015...

Cookbook officiel

https://datatracker.ietf.org/group/jose/documents/

• JSON Web Encryption (JWE)
  • ​est un standard ouvert pour représenter le contenu chiffré en tant que données JSON codées en base64url. (RFC 7516)
• JSON Web Signature (JWS)
  • Une signature Web JSON (JWS) est un moyen standard de représenter du contenu signé numériquement et/ou HMAC à l'aide de structures de données JSON. (RFC 7515)
• JSON Web Token (JWT)
  • ​JSON Web Token (JWT) est un standard ouvert pour représenter la transmission sécurisée des revendications entre deux parties sous la forme de trois chaînes concaténées de données JSON codées en base64url, jointes par des points (.). (RFC 7519)
•  

Les jetons signés peuvent vérifier l'intégrité des "claims" qu'ils contiennent, tandis que les jetons cryptés cachent ces "claims" à d'autres parties.

JSON Web Token (JWT)

JWT permet de communiquer des "claims" qui sont des commandes / paires (clef-valeur).

• réservés
  • iss(émetteur): Émetteur du JWT
  • sub(sujet): Sujet du JWT (l'utilisateur)
  • aud(audience) : bénéficiaire auquel le JWT est destiné
  • exp(délai d'expiration) : délai d'expiration du JWT...
• personnalisés
  • Selon la norme JWT, vous devez nommer les réclamations privées avec prudence pour éviter les collisions

2 catégories de "claims"

• symétrique
  • algo AEC, HMAC...
• asymétrique
  • algo ECDSA ou RSA notamment

 Les JWT peuvent être signés à l'aide d'un secret (avec l'algorithme HMAC) ou d'une paire de clés publique/privée à l'aide de RSA ou ECDSA. (+ info RFC-7518)

Signer un jeton

via la cryptographie

• Si possible, éviter le symétrique
  • secret partagé... faiblesse en sécurité
  • difficile d'identifier le "générateur" du jeton car le secret est partagé

Comment choisir ?

1. contrôler les accès
   1. via cookie
   2. via l'entête Authorization: Bearer...
2. jeton d'autorisation à usage unique (oauth...)
   1. claims -> sémantiquement une commande
3. vérifier une adresse email
   1. JWT en query, mode stateless
4. ​Transmettre une information

Permet de

Le meilleur cas d'usage de JWT est celui d'un usage d'autorisation unique

• doit attendre l'expiration du JWT
• pas de Refresh du jeton, on regénère
• pour gérer les sessions (révocation compliquée)
• les données du JWT peuvent devenir obsolètes
• toutes utilisations où la durée de vie est longue
• peut être long dans l'URL....

Moins pratique

• vérifier toujours
  • iss : issuer
  • aud : audience
  • exp: expiration
  • nbf: not before
• rejeter éventuellement des vieux jetons
  • iat: issued at
• vérifier l'intention
  • ex: access_token, token_id
•  +vie privée : Pairwise Pseudonymous Identifiers

Contrôle d'accès