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

16

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.

security rest authentication keys hmac smeeb
la source
1
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
2
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

Réponses:

7

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
la source