Basic/Bearer/API-key all send a secret with every request. Signature schemes avoid that: you prove you know the secret without transmitting it.
HMAC / custom signatures
Common in trading and payment APIs (Binance, payment gateways). You build a string from the request (timestamp + method + path), compute HMAC-SHA256 over it using your secret key, and send the signature in a header. The server recomputes it and compares. A timestamp window blocks replays.
- x-app-id — your App ID (public identifier).
- x-timestamp — current time; requests older than 5 minutes are rejected.
- x-signature — HMAC_SHA256(key = your API key, message = `${timestamp}.${method}.${path}`), hex-encoded.
In these signature modules the signing secret is your API key and the public id is your App ID — the same access-key-id + secret-key split real APIs use.
Digest (RFC 7616)
A challenge-response scheme. You request without auth; the server replies 401 with a WWW-Authenticate: Digest header containing a one-time nonce. You hash your credentials together with the nonce and resend. The nonce prevents replay.
curl -v https://api.ifsjaipur.cloud/playground/auth/digest
# note the nonce in the WWW-Authenticate header, then send a Digest Authorization responseTip · You rarely hand-build these — libraries and n8n do it. The value here is seeing the round trip so the concept is not a mystery.