Lion Cipher Lab
Sign an AWS API request with Signature Version 4 — from scratch
- Cloud Security
- Advanced
- ~75 min
- Free · no account required
Why it matters
Every request to nearly every AWS service is authenticated with Signature Version 4, and yet most engineers treat it as an opaque thing the SDK does. That opacity is a security blind spot. If you cannot explain WHY AWS signs each request instead of sending a static token, you cannot reason about the failure modes that actually bite: a leaked long-lived access key, a presigned URL that outlives its purpose, a clock-skew replay window, a signature that silently breaks the moment a proxy reorders a query string. SigV4 is a small, fully-knowable algorithm — HMAC-SHA256 chained four times over a…
What you'll learn
- Building a SigV4 canonical request (method, URI, sorted query, canonical headers, signed headers, payload hash)
- Assembling the AWS4-HMAC-SHA256 string-to-sign with its credential scope
- Deriving the signing key via the four chained HMAC-SHA256 steps (kDate -> kRegion -> kService -> kSigning)
- Computing the final signature and assembling the Authorization header by hand
- Proving an implementation byte-for-byte against a known-good vector and re-deriving the key with openssl
- Reasoning about the X-Amz-Date replay window, the payload hash, presigned-URL expiry, and STS X-Amz-Security-Token
Steps in this lab
- What SigV4 is, and the one bit it proves
- The four artifacts, in the order you'll build them
- Set up the inputs and two tiny crypto helpers
- Build the canonical request
- Build the string-to-sign
- Derive the signing key: four chained HMAC-SHA256 steps
- Compute the signature and assemble the Authorization header
- Run it and PROVE it byte-for-byte
- Independent check: re-derive the signing key with openssl
- Break it on purpose: the SignatureDoesNotMatch failure modes
- The judgment: why a per-request signature beats a static token
- When NOT to hand-roll this — the better way in production