Standard

AWS Signature Version 4 (SigV4)

The AWS cryptographic request signing protocol used to authenticate and authorize S3 API requests. Every S3 request is signed with HMAC-SHA256 using the caller's credentials.

2 connections3 resources

Summary

What it is

The AWS cryptographic request signing protocol used to authenticate and authorize S3 API requests. Every S3 request is signed with HMAC-SHA256 using the caller's credentials.

Where it fits

SigV4 is the authentication layer of the S3 ecosystem. Every S3-compatible storage system that claims S3 API compatibility must implement SigV4 verification. Every S3 client library must implement SigV4 signing. It is the security handshake that makes the ecosystem work.

Misconceptions / Traps
  • SigV4 signing is region-scoped. Requests must be signed for the correct region, or they are rejected. This catches developers who hardcode regions or use global endpoints incorrectly.
  • Clock skew between client and server causes SigV4 failures. S3 requests are rejected if the timestamp is more than 15 minutes from the server's clock.
Key Connections
  • scoped_to S3 API — the authentication protocol for all S3 requests
  • enables S3 API interoperability — every S3-compatible system must implement SigV4
  • constrained_by S3 Compatibility Drift — some implementations handle SigV4 edge cases differently

Definition

What it is

AWS's cryptographic request signing protocol that authenticates and authorizes every S3 API request using HMAC-SHA256 signatures derived from the request components and the caller's secret key.

Why it exists

SigV4 is the authentication layer of the S3 API. Every S3-compatible implementation must support SigV4 for client compatibility. It provides request integrity, replay protection, and credential-based access control.

Primary use cases

S3 API authentication, presigned URL generation, cross-account access delegation, S3-compatible server implementation.

Recent developments

Latest signals

  • AWS KMS XKS Proxy: mTLS authentication deprecated June 15, 2026 — SigV4 is now the mandatory authentication path. The external-key-store proxy spec dropped mTLS as an auth option; SigV4 request signing is the single supported mechanism. Anyone running an XKS proxy (self-hosted HSM bridging into KMS) must have migrated. Per aws-kms-xksproxy-api-spec (GitHub).

  • Operational reality check: SigV4 breaks deterministically when proxies rewrite signed headers. Two July bug threads document the failure class — any in-transit hop that rewrites incidental headers invalidates the signature (401 InvalidSignature), and a Claude Code release regression shipped bare base64 instead of the AWS4-HMAC-SHA256 authorization format against Bedrock. The emerging fix pattern: sign only a minimal stable header set. Worth encoding because SigV4 is now load-bearing far beyond S3. Per aws/mcp-proxy-for-aws issue and claude-code-action regression report.

  • AgentCore's A2A protocol went GA with SigV4 + OAuth 2.0 as the two authentication paths. SigV4 extending into agent-to-agent auth is scope creep in the good sense — the same signing primitive that authenticates S3 requests now authenticates inter-agent calls on AWS's agent runtime. Aggregator-reported. Per AWS AgentCore vs Azure AI Foundry analysis.

  • GitHub. AWS APIs require SigV4 signing and use configurable proxy/backend endpoint. Updated February 21, 2026. Per GitHub (aws/aws-kms-xksproxy-api-spec).

  • aws-kms-xksproxy-api-spec/xks_proxy_api_spec.md. Last Updated: Mar 9, 2026. Authentication section: SigV4 Credentials Rotation. KMS signs all XKS Proxy API requests using AWS SigV4. After June 15, 2026, mTLS no longer viable; customers MUST rely on SigV4 authentication. Per GitHub (aws/aws-kms-xksproxy-api-spec).

  • gbrain-agent-brain/TODOS.md. Completed: v0.6.0 (2026-04-10) — replaced with @aws-sdk/client-s3 for proper SigV4 signing. Per GitHub (syntax-syndicate/gbrain-agent-brain) (2026-04-24).

  • SigV4-gated Iceberg REST Catalog endpoints break Trino compatibility. SeaweedFS's Iceberg REST Catalog started requiring SigV4 authentication after IAM user creation, but the Trino connector doesn't implement SigV4 request signing — Trino gets a bare 403 Forbidden. Per SeaweedFS issue #8220.

  • SigV4 signatures are region-locked; SigV4A isn't. SigV4 bakes the region name directly into CredentialScope, so a signature minted for one region fails verification in another — the reason multi-region and global-endpoint setups need SigV4A instead. Per AWS SigV4 and SigV4A Deep Dive.

  • rustfs was found persisting a SigV4-only header as real object metadata. It stored Content-Encoding: aws-chunked — a value SigV4 clients send only to flag chunked-transfer signing, not an actual encoding — which broke spec-compliant clients like the Nix package manager. Per rustfs issue #1857.

  • aws-sdk-rust dropped ring from its aws-sigv4 crate in favor of the hmac/sha2 crates, and upgraded p256 to 0.13.2 to support the SigV4A signing path. Per aws-sdk-rust May 2026 release notes. Sources: GitHub (aws/aws-kms-xksproxy-api-spec) · GitHub (syntax-syndicate/gbrain-agent-brain)

Connections2

Outbound2
scoped_to1
S3
enables1
S3 API

Resources3

SpecHigh
docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-aut...

Definitive reference for the SigV4 signing process used in S3 Authorization headers, the de facto authentication standard for S3-compatible APIs.

DocsHigh
docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html

AWS IAM reference for Signature Version 4 covering the signing algorithm, credential scope, and canonical request construction.

SpecHigh
docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticatin...

S3-specific SigV4 authentication documentation covering query string signing, chunked uploads, and presigned URLs.