Signed requests, by default.
Every request carries a keyed HMAC signature over its canonical form, with a timestamp expiry window and nonce-based replay prevention. The signature proves both the caller’s identity and that the payload arrived untampered.
1. Identity and integrity in one primitive
An HMAC is a keyed hash computed over a canonical representation of the request — method, path, headers that matter, body, and a timestamp — using a secret shared only between the caller and the service. Because only a holder of the key can produce a valid signature, the signature proves identity; because it covers the whole request, any change to the payload invalidates it. One primitive answers two questions: who sent this, and did it arrive unaltered.
// canonical string the signature commits to
canonical = METHOD + "n" + PATH + "n" + TIMESTAMP + "n" + NONCE + "n" + sha256(BODY);
signature = base64( HMAC-SHA256(secretKey, canonical) );
// server recomputes and compares in constant time2. Why canonicalization is the hard part
HMAC is only as strong as the agreement on what is signed. If client and server canonicalize differently — header order, encoding, trailing slashes — valid requests fail or, worse, an attacker finds a representation that signs one thing and executes another. A disciplined, unambiguous canonical form, with a timestamp and a nonce inside the signed material, is what makes the scheme both reliable and replay-resistant.
3. How B5 Secure handles it
B5 Secure makes HMAC a first-class authentication scheme in the pipeline: requests are signed over a canonical form with an expiry window and a nonce, and the server verifies the signature, the freshness, and the nonce before the request proceeds. It is the default posture for sensitive and machine traffic — identity and integrity established together, on every call.