Les jetons Web JSON sont un outil utile et un meilleur moyen d'implémenter l'autorisation dans les applications Web, mais que sont-ils exactement et comment fonctionnent-ils?
Qu'est-ce qu'un JWT? Un jeton Web JSON (JWT) est une norme ouverte ( RFC 7519 ) qui définit un moyen compact et autonome pour transmettre en toute sécurité des informations entre les parties en tant qu'objet JSON.
Un JWT est un moyen de représentant des créances à transférer entre deux parties. Les revendications dans un JWT sont codées en tant qu'objet JSON qui est signé numériquement à l'aide de la signature Web JSON (JWS) et / ou chiffré à l'aide du cryptage Web JSON (JWE).
Ces informations peuvent être vérifiées et approuvées car elles sont signées numériquement. Les jetons Web JSON peuvent être signés à l'aide d'une clé secrète (avec l'algorithme HMAC ) ou d'une paire de clés publique / privée utilisant RSA ou ECDSA .
JWT vs Session
L'autorisation est généralement effectuée en utilisant une session. La différence critique entre les JWT et les sessions est que les JWT sont autonomes alors que les sessions ne le sont pas.
Un jeton Web JSON contient:
- Payload: Stocke des informations sur l'utilisateur et l'autorisation
- Signature : Vérifie que le jeton est valide
Ainsi, lorsque le serveur reçoit un JWT, il peut déjà récupérer toutes les informations directement à partir du jeton, donc autonome. En revanche, un SessionID est simplement une longue chaîne unique et aléatoire. À lui seul, il n'a aucune information. Lorsque vous faites une demande à un serveur avec votre SessionID, il doit faire un travail supplémentaire pour savoir à quel utilisateur il appartient.
Structure JWT
Les jetons Web JSON se composent de trois parties séparées par des points (. ):
- En-tête: L'en-tête généralement se compose de deux parties: le type de jeton (qui est JWT) et l'algorithme de signature utilisé, tel que HMAC SHA256 ou RSA.
{
«Typ» : «JWT»
«Alg» : «SHA256»
}
- Charge utile: La deuxième partie du jeton est la charge utile, qui contient les revendications. Les revendications sont des déclarations sur une entité (généralement, l'utilisateur) et des données supplémentaires. Il existe deux types de revendications JWT:
a. Réservé: Revendications définies par la spécification JWT pour garantir l'interopérabilité avec des applications tierces ou externes. Les revendications standard OIDC sont des revendications réservées. Voici quelques-unes des affirmations standard que nous pouvons utiliser:
- Sujet (sous): Sujet du JWT (l'utilisateur)
- Émetteur (émetteur): Émetteur du JWT
- Audience (aud): Destinataire de auquel le JWT est destiné
- Heure d'expiration (exp): heure après laquelle le JWT expire
- Délivré à (iat): heure à laquelle le JWT a été émis; peut être utilisé pour déterminer l'âge du JWT
b. Personnalisé : Revendications que vous définissez vous-même. Nommez ces revendications soigneusement pour éviter toute collision avec des revendications réservées ou d'autres revendications personnalisées. Il peut être difficile de traiter deux revendications du même nom contenant des informations différentes.
{
«Sous» : «JohnDoe19»
"Iat" : " 17837373 "
}
- Signature: C'est la partie la plus importante du JWT. La signature est calculée en codant l'en-tête et la charge utile à l'aide du codage Base64url et en les concaténant avec un séparateur de point. Il est ensuite donné à l'algorithme de cryptage.
data = base64urlEncoder ( header ) + «. » + base 64 urlEncoder ( payload )
Signature = HMAC - SHA256 ( data secret_salt )
Ainsi, lorsque l'en-tête ou la charge utile change, la signature doit être calculé à nouveau. Seul le fournisseur d'identité (IdP) a la clé privée pour calculer la signature, ce qui empêche la falsification du jeton.
Flux JWT
Jetons un coup d'œil au flux de JTW, pour mieux comprendre:
-
L'utilisateur se connecte en utilisant «Nom d'utilisateur» et «Mot de passe».
-
Le serveur vérifie l'authenticité de vos informations d'identification (nom d'utilisateur et mot de passe).
-
Si les informations d'identification sont authentiques, le serveur crée un objet JSON.
-
Ensuite, le serveur sérialise l'objet JSON, génère un jeton, puis l'envoie au navigateur.
-
Le navigateur reçoit le jeton et l'enregistre dans les cookies.
-
Lorsque l'utilisateur envoie ensuite une requête à un point d'extrémité protégé, le JWT est transmis dans l'en-tête HTTP de la requête.
-
Le serveur vérifie la signature sur le JWT pour s'assurer que le même serveur a créé le JWT. De cette manière, le JWT agit comme un moyen d'autoriser les utilisateurs en toute sécurité, sans stocker réellement aucune information (en dehors de la clé) sur le serveur d'application.
-
Le serveur lit les revendications et autorise la requête, après quoi il répond avec les données nécessaires.
Quand devriez-vous utiliser JWT?
Voici quelques scénarios où les jetons Web JSON sont utiles:
-
Autorisation: Il s'agit du scénario le plus courant pour l'utilisation de JWT. Une fois que l'utilisateur est connecté, chaque demande ultérieure inclura le JWT, permettant à l'utilisateur d'accéder aux routes, services et ressources qui sont autorisés avec ce jeton.
-
Échange d'informations: Les jetons Web JSON sont un bon moyen de transmettre des informations en toute sécurité entre les parties. Étant donné que les JWT peuvent être signés, par exemple à l'aide de paires de clés publiques / privées, vous pouvez être sûr que les expéditeurs sont bien ceux qu'ils prétendent être.
Meilleures pratiques lors de l'utilisation de JWT
-
Créez un cookie HttpOnly si JWT est conservé sur le cookie pour empêcher JavaScript tiers de lire le jeton JWT à partir du cookie.
-
Si un jeton JWT n’a pas expiré et qu’il tombe entre de mauvaises mains, cela peut conduire à des exploits. La création d'une liste de révocation de jetons sur votre serveur pour invalider les jetons une fois que les utilisateurs ont quitté votre site pourrait aider à renforcer la sécurité.
-
Utilisez toujours HTTPS pour sécuriser les en-têtes d'autorisation.
Source link