AWS Signature Version 4
Summary
Definition: AWS SigV4 authenticates requests by signing a deterministic, canonical form of the HTTP request using derived keys.
Why it matters: AWS uses the signature to verify request integrity and credential ownership without maintaining server-side session state.
Pitfall: Even minor differences in encoding, ordering, or payload hashing invalidate signatures.
AWS Signature Version 4 (SigV4) authenticates AWS API requests by signing a normalized representation of the HTTP request.
The signature binds the request method, path, query parameters, headers, payload hash, date, region, and service into a
verifiable cryptographic value.
- Canonical request
- A deterministic, normalized string representation of an HTTP request.
- String to sign
- Metadata plus the hash of the canonical request.
- Credential scope
- Date/region/service/aws4_request context for the signature.
- Signing key
- Derived HMAC key used to calculate the final signature.
- SigV4
- AWS Signature Version 4 authentication process.
How SigV4 works
AWS verifies SigV4 requests by rebuilding the canonical request from the received HTTP request.
If the reconstruction differs from what you signed, authentication fails.
AWS does not trust the signature you send at face value. It reconstructs the canonical request from the HTTP request it
receives,
then computes its own signature using the same algorithm. Authentication succeeds only if both signatures match exactly.
Canonical request components
A canonical request is constructed from:
Common misconception: SigV4 signs headers implicitly. In reality, only headers listed in SignedHeaders are
protected.
Signing flow
- Build the canonical request.
- Hash the canonical request.
- Create the string-to-sign.
- Derive the signing key.
- Compute the signature.
- Attach the Authorization header.
Credential scope
The credential scope uniquely identifies the request context:
YYYYMMDD/region/service/aws4_request
Any mismatch between this scope and the actual endpoint causes signature validation to fail.
Authorization header structure
The Authorization header contains:
Time and clock skew
Requests must use UTC timestamps. AWS typically rejects requests with more than ~5 minutes of clock skew.
- Synchronize system clocks before signing requests.
Payload handling
- Payload hashing is required for SigV4.
- Some services explicitly allow UNSIGNED-PAYLOAD.
- Large or streaming payloads may require chunked (streaming) SigV4.
UNSIGNED-PAYLOAD is allowed only for specific AWS services and operations.
Temporary credentials
When using IAM roles or STS credentials, include and sign the x-amz-security-token header.
Presigned URLs
SigV4 supports query-string authentication for presigned URLs, which is commonly used for Amazon S3 object access.
Debugging workflow
- Log the canonical request.
- Log the string-to-sign.
- Verify the credential scope.
- Compare signed headers to sent headers.
- Confirm the payload hash matches the request body.
FAQ
What headers must be signed? At minimum, host and x-amz-date must be signed. If temporary credentials are used, x-amz-security-token must also be signed.
What causes SignatureDoesNotMatch? Canonical request mismatches, wrong credential scope, header normalization errors, or payload hash differences.
Are query parameters signed? Yes. Canonicalized query parameters are always part of the canonical request.
Does SigV4 encrypt requests? No. SigV4 provides authentication and integrity, not encryption.