How AWS Signature Version 4 (SigV4) Works - The Cryptographic Mechanics of API Authentication
A cryptographic deep dive into the 4-step SigV4 signing process (canonical request creation, string-to-sign construction, signing key derivation, signature calculation) used for AWS API authentication, plus an overview of SigV4A and presigned URLs.
Why Signing Is Necessary
Requests to AWS APIs require authentication information proving that the sender is a legitimate AWS user. The simplest authentication method would be to include the access key and secret key directly in the request, but this is dangerous - if the request is intercepted, the secret key is exposed. SigV4 is a signing scheme that authenticates without including the secret key in the request. It uses the secret key to compute a signature (HMAC-SHA256 hash) from the request contents and includes that signature in the request. AWS performs the same calculation with the same secret key, and if the signatures match, authentication succeeds. The secret key itself never travels over the network. Furthermore, since the SigV4 signature is calculated from the request contents (HTTP method, URL, headers, body), any tampering with the request causes the signature to mismatch. This guarantees both authentication and integrity.
The 4-Step Signing Process
The SigV4 signing process consists of 4 steps. Step 1 is creating the Canonical Request. You construct a string by concatenating the HTTP method, URL path, query string, headers, and body hash in a specific format. Headers are sorted alphabetically by key, with leading and trailing whitespace removed from values. This canonicalization ensures that the same request always produces the same canonical request. Step 2 is constructing the String to Sign. You concatenate the algorithm name (AWS4-HMAC-SHA256), timestamp, credential scope (date/region/service/aws4_request), and the SHA-256 hash of the canonical request. Step 3 is deriving the Signing Key. Starting from the secret key, you generate the signing key by sequentially applying HMAC-SHA256 with the date, region, and service name. Step 4 is computing the Signature. You calculate the HMAC-SHA256 of the string to sign using the signing key and convert it to a hexadecimal string. This signature is included in the Authorization header when sending the request.
Signing Key Derivation - Why Multi-Stage HMAC?
The signing key derivation involves 4 stages of HMAC-SHA256 from the secret key: kDate = HMAC(AWS4 + SecretKey, Date), kRegion = HMAC(kDate, Region), kService = HMAC(kRegion, Service), kSigning = HMAC(kService, aws4_request). This multi-stage derivation serves two purposes. First, it limits the scope of the signature. Since the signing key is tied to a specific date, region, and service, a signing key for S3 in the Tokyo region on a given day cannot be used for a different day, region, or service. Even if a signing key is leaked, the damage is contained. Second, it enables signing key caching. For requests to the same service in the same region on the same day, the signing key is identical. SDKs cache the signing key and reuse it until the date changes, eliminating the need to derive it from the secret key every time and improving performance. The timestamp included in the signature must be within 5 minutes of the AWS server time, or the request is rejected. This prevents replay attacks using old signatures.
Presigned URLs - Embedding Signatures in URLs
S3 presigned URLs are URLs with SigV4 signatures embedded in the query string. Anyone with this URL can access S3 objects without AWS credentials. Presigned URLs have an expiration period of up to 7 days (for IAM user access keys) or up to 12 hours (for STS temporary credentials). The presigned URL query string includes X-Amz-Algorithm (signing algorithm), X-Amz-Credential (access key ID and credential scope), X-Amz-Date (timestamp), X-Amz-Expires (expiration in seconds), X-Amz-SignedHeaders (headers included in the signature), and X-Amz-Signature (the signature). An important characteristic of presigned URLs is that they are evaluated based on permissions at the time the URL is used, not at the time it was generated. If the access key is invalidated or IAM policies are changed after URL generation, the URL becomes unusable.
SigV4A - A New Signing Scheme for Multi-Region Support
Since SigV4 signing keys are tied to a specific region, a single signature cannot be used to send requests to multiple regions. For cases like S3 Multi-Region Access Points where requests may be routed to multiple regions, SigV4 cannot handle this. SigV4A (Signature Version 4A) is an extension introduced to solve this limitation. SigV4A uses ECDSA (Elliptic Curve Digital Signature Algorithm) instead of HMAC-SHA256. Since ECDSA is asymmetric cryptography, the signing key derivation does not need to include a region. A single signature can be used to send requests to multiple regions. SigV4A is currently used with S3 Multi-Region Access Points and EventBridge global endpoints. SDKs automatically switch between SigV4 and SigV4A based on the target service and endpoint, so developers rarely need to be aware of the signing scheme. To systematically learn about AWS API authentication, specialized books (Amazon) are a helpful reference.