Signature des requêtes HMAC
Tous les endpoints /v1/*, GET compris, exigent HMAC-SHA256 sans exception. La vérification utilise une comparaison en temps constant contre les attaques temporelles.
Besoin de fichiers prêts à exécuter ? Consultez la page Intégration pour les exemples, Postman et .http utilisant cette même formule.
Voir l’intégrationHeaders obligatoires
Les 4 premiers headers sont obligatoires à chaque requête. Liste issue du schéma de sécurité openapi.json.
| Header | Type | Signification |
|---|---|---|
X-TKE-Key | chaque requête | key_id public (tke_live_… / tke_test_… / tke_member_live_… / tke_member_test_…) |
X-TKE-Timestamp | chaque requête | Époque en millisecondes (chaîne entière) |
X-TKE-Nonce | chaque requête | UUID v4 ou v7 unique par requête |
X-TKE-Signature | chaque requête | HMAC-SHA256 hexadécimal minuscule |
Idempotency-Key | 5 endpoints | Chaîne créée par le client : même clé et même corps exécutés une seule fois, avec résultat initial aux reprises. Portée par |
Idempotency-Key/v1/ordersPOST/v1/orders/bulkPOST/v1/esims/{id}/cancelPOST/v1/esims/{id}/change-planPOST/v1/esims/{id}/refund-requestsFormule canonique de signature
Authentification HMAC-SHA256 (§4). Envoyer 4 en-têtes : X-TKE-Key (key_id public), X-TKE-Timestamp (époque en ms), X-TKE-Nonce (UUID par requête), X-TKE-Signature (hexadécimal minuscule). signing_string = method path timestamp nonce body_hash ; body_hash = SHA256(raw_body) hexadécimal. Comparaison à temps constant. path INCLUT la chaîne de requête.
Les segments sont joints par saut de ligne \n (LF), puis signés sur SHA256(raw_body) plutôt que le corps direct : le serveur recalcule le hash des octets reçus.
signing_string = method + "\n"
+ path + "\n" # query inclus, sans scheme/hôte
+ timestamp + "\n" # = header X-TKE-Timestamp (epoch ms)
+ nonce + "\n" # = header X-TKE-Nonce
+ body_hash # SHA256(raw_body) hex lowercase
signature = HMAC_SHA256(secret, signing_string) → hex lowercaseraw_body = "" → body_hash = SHA256("") = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.Exemples de signature HMAC
Remplacez secret et key_id. Envoyez les octets hachés, sans resérialiser après signature.
#!/usr/bin/env bash
# Yeu cau: openssl. Ky POST /v1/orders.
KEY_ID="tke_test_ab12cd34..."
SECRET="tke_secret_test_0123456789abcdef"
METHOD="POST"
PATH_Q="/v1/orders"
BODY='{"items":[{"package_code":"THAY-BANG-MA-GOI-CUA-BAN","quantity":2}]}'
TS="$(date +%s000)" # epoch milliseconds
NONCE="$(uuidgen)"
BODY_HASH="$(printf '%s' "$BODY" | openssl dgst -sha256 -hex | awk '{print $NF}')"
SIGNING="$METHOD"$'
'"$PATH_Q"$'
'"$TS"$'
'"$NONCE"$'
'"$BODY_HASH"
SIG="$(printf '%s' "$SIGNING" | openssl dgst -sha256 -hmac "$SECRET" -hex | awk '{print $NF}')"
curl -sS "https://api.tongkhoesim.com$PATH_Q" -H "X-TKE-Key: $KEY_ID" -H "X-TKE-Timestamp: $TS" -H "X-TKE-Nonce: $NONCE" -H "X-TKE-Signature: $SIG" -H "Idempotency-Key: $(uuidgen)" -H "Content-Type: application/json" --data-raw "$BODY"Vecteurs de test du backend
Ces vecteurs générés par le backend servent à vérifier votre implémentation.
Signez les entrées exactes ci-dessous et comparez. En cas d’écart, vérifiez signing_string.
tke_secret_test_0123456789abcdefPOST/v1/orders172068000000011111111-1111-4111-8111-111111111111{"items":[{"package_code":"VN_5GB_30D","quantity":2}]}c197853f7fe46a9f2de1478e565c48ef9369d0152af5117434be8ccfa9391b31POST
/v1/orders
1720680000000
11111111-1111-4111-8111-111111111111
c197853f7fe46a9f2de1478e565c48ef9369d0152af5117434be8ccfa9391b3197147afdebb5d15cf8441278ef524ce15c715ca95962ddb1cb2604a1672fc5d5GET/v1/wallet/balance172068000000022222222-2222-4222-8222-222222222222(vide)e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855GET
/v1/wallet/balance
1720680000000
22222222-2222-4222-8222-222222222222
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855ab16941884d407924c7b15dea008d6f1d8c0c1be96dca3745344218a99257dbe