Générateur de signature d'API

L'authentification HMAC (Hash-based Message Authentication Code) fonctionne par le partage d'une clé secrète entre les deux parties. L'expéditeur calcule HMAC(secret, message) et envoie le résultat comme en-tête de signature. Le destinataire calcule indépendamment le même HMAC et le compare à la signature reçue. Comme seules les parties détenant la clé secrète peuvent produire une signature valide, un HMAC correspondant prouve l'authenticité et l'intégrité du message.

Un hachage SHA256 simple est déterministe et public — n'importe qui peut calculer SHA256(données). HMAC-SHA256 intègre une clé secrète dans le calcul en utilisant une construction en deux passes : HMAC(k, m) = H((k ⊕ opad) || H((k ⊕ ipad) || m)). Cela signifie que seules les parties détenant la clé secrète peuvent produire ou vérifier la signature, ce qui la rend adaptée à l'authentification là où les hachages simples ne le sont pas.

Les webhooks transmettent des requêtes HTTP POST d'un serveur à votre point de terminaison. Sans authentification, n'importe quel serveur pourrait envoyer de faux événements. Les signatures HMAC résolvent ce problème : le fournisseur de webhook signe la charge utile avec un secret partagé, et votre serveur recalcule le HMAC pour vérifier l'authenticité avant de traiter l'événement. GitHub, Stripe, Shopify et la plupart des systèmes de webhooks modernes utilisent ce modèle avec HMAC-SHA256.

Le contenu du message varie selon l'API. Les approches courantes incluent : la signature du corps de la requête seule (Stripe, webhooks GitHub), la signature d'une chaîne canonique de méthode + URL + horodatage + corps (AWS Signature V4), ou la signature d'une chaîne de requête triée. Consultez toujours la documentation de votre fournisseur d'API pour connaître leur format exact de chaîne canonique, car même les différences d'espacement produiront une signature différente.