Request Signing

Request signing authenticates an API call by attaching cryptographic evidence derived from the request and the caller's credentials. Instead of sending a secret access key with every call, the client uses that secret, or a derived signing key, to calculate a signature. The receiving service verifies the signature against the same request details. A valid signature establishes possession of the relevant credentials and protects the signed components against undetected modification; it does not establish that the caller is authorized to perform the operation.

Signing schemes define a canonical representation of the request so that the client and server calculate matching results. This representation commonly includes the HTTP method, request path, normalized query parameters, selected headers, and a representation of the payload. Exact encoding rules matter: changing a signed header, altering query-string encoding, or rewriting a path after signing can invalidate the signature. Payload protection depends on the scheme and request mode; not every signed request includes a hash of the complete body.

For AWS service API calls, Signature Version 4, commonly called SigV4, is the standard mechanism engineers encounter. It creates a canonical request and a string to sign, then uses HMAC-SHA256 with a derived signing key. The credential scope includes a date, AWS Region, and service. The request normally carries signing information in the Authorization header, although supported operations can place it in query parameters instead. The access key ID identifies the credentials; the secret access key is never included in the request.

Temporary AWS credentials contain an access key ID, secret access key, and session token. All three are needed when signing requests with those credentials, and the session token accompanies the request, commonly through the X-Amz-Security-Token header. An application running with an assigned IAM role should obtain temporary credentials through its SDK credential provider rather than embed long-lived keys. AWS SDKs and the AWS CLI normally perform signing automatically and can refresh credentials when their configured provider supports it.

For example, a worker reading an object from Amazon S3 can use its role credentials to sign a GetObject request. S3 verifies the request, and applicable policies determine whether access is allowed. A correctly signed call can still receive AccessDenied because a policy denies access or a required permission is missing. Similarly, calling an Amazon API Gateway endpoint configured for IAM authorization requires an appropriately signed request and permission to invoke that API; an API key alone does not replace IAM authentication.

Presigned URLs move signing information into the URL so another client can perform a specific operation without receiving the signing credentials. An application might generate a short-lived URL for downloading a private object. Treat that URL as a bearer capability: anyone possessing it can generally use it within its validity and policy constraints. It can usually be reused until it expires, and temporary signing credentials can expire before the URL's requested expiration time.

Signing is not encryption, so HTTPS remains necessary to protect request confidentiality and transport security. Timestamps and expiration checks limit replay opportunities but do not inherently make requests single-use; use idempotency mechanisms where duplicate operations matter. Operationally, prefer maintained signing libraries, synchronize system clocks, select the correct endpoint and Region, and investigate credential expiration, missing session tokens, and proxy modifications when signatures fail.