Sécurité de l'API REST: HMAC / hachage de clé vs JWT

Je viens de lire cet article qui date de quelques années mais décrit une manière intelligente de sécuriser vos API REST. Essentiellement:

Chaque client possède une paire de clés publique / privée unique
Seuls le client et le serveur connaissent la clé privée; il n'est jamais envoyé sur le fil
Avec chaque demande, le client prend plusieurs entrées (la demande entière elle-même, l'horodatage actuel et la clé privée) et les exécute via une fonction HMAC pour produire un hachage de la demande
Le client envoie ensuite la requête normale (qui contient la clé publique) et le hachage au serveur
Le serveur recherche la clé privée du client (sur la base de la clé publique fournie) et effectue une vérification d'horodatage (que je ne comprends pas) qui vérifie que la demande n'est pas victime d'une attaque de relecture
Si tout va bien, le serveur utilise la clé privée et la même fonction HMAC pour générer son propre hachage de la demande
Le serveur compare ensuite les deux hachages (celui envoyé par le client ainsi que celui qu'il a généré); s'ils correspondent, la demande est authentifiée et autorisée à continuer

Je suis ensuite tombé sur JWT , ce qui semble très similaire. Cependant, le premier article ne mentionne pas du tout JWT, et donc je me demande si JWT est différent de la solution d'authentification ci-dessus, et si oui, comment.

— smeeb
source

Lol ... Je voulais juste poser la même question exacte et suis tombé sur la vôtre. L'une des premières choses que j'ai trouvées sur l'authentification sans état est venue d' AWS: docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/… , et a implémenté quelque chose comme massimilianosciacco.com/… . Ensuite, j'ai trouvé JWS / JWT et c'est en quelque sorte similaire. Mais pour autant que je sache, JWT est un standard et les autres solutions décrites ci-dessus sont des implémentations personnalisées (non standardisées). Quelqu'un me corrige si je me trompe.

— nyxz

Bon à savoir, je ne suis pas le seul à m'inquiéter de ce genre de détails! JWT se sent certainement similaire, et le bonus est qu'il est standardisé. Je me demande simplement comment cela va (sur le plan de la sécurité) avec cette solution HMAC personnalisée.

— smeeb

Commençons par une réponse très basique.

JWT (tel qu'utilisé dans le contexte d'OAuth et d'OpenID) ne nécessite pas de secrets partagés entre le client et l'API. Il y a 3 composants et des paires de 2 partagent un secret chacun: client <-> serveur d'identification, serveur d'identification <-> API.

Cela déplace la plus grande complexité de l'API vers le serveur d'identification, l'API n'a qu'à vérifier que le jeton a été émis par le serveur d'identification et n'a pas été tempéré. Pour vérifier que l'API vérifie que la signature JWT est valide avec le seul secret partagé connu entre le serveur d'identification et l'API. C'est ça!

La façon dont le serveur d'identification valide l'identité de l'utilisateur peut varier considérablement (dans de nombreux cas, il s'agit de l'ancienne paire nom d'utilisateur + mot de passe via une connexion TLS), mais n'a aucun effet sur votre API.

La confidentialité et la sécurité du message et du jeton lui-même lors de l'utilisation de JWT sont gérées par TLS, JWT ignore ces problèmes.

— Patrick
source