AWS Signature Version 4 for API requests

Important

If you use an AWS SDKs (see Sample Code and Libraries) or AWS command line (CLI) tool to send API requests to AWS, you can skip SigV4 because the SDK and CLI clients authenticate your requests by using the access keys that you provide. Unless you have a good reason not to, we recommend that you always use an SDK or the CLI.

In Regions that support multiple signature versions, manually signing requests mean you must specify which signature version is used. When you supply requests to Multi-Region Access Points, SDKs and the CLI automatically switch to using Signature Version 4A without additional configuration.

Authentication information that you send in a request must include a signature. AWS Signature Version 4 (SigV4) is the AWS signing protocol for adding authentication information to AWS API requests.

You don't use your secret access key to sign API requests. Instead, you use the SigV4 signing process. Signing requests involves creating a canonical request based on the request details, calculating a signature using your AWS credentials, and adding this signature to the request as an Authorization header. AWS then replicates this process and verifies the signature, granting or denying access accordingly.

Note

AWS also supports an extension, Signature Version 4A, which supports signatures for multi-Region API requests. For more information, see the sigv4a-signing-examples project on GitHub.

How AWS SigV4 works

The following diagram illustrates the general process of computing a signature.

An image of the parts of a signature, including the string to sign, signing key, and calculated signature.
  • The string to sign depends on the request type. For example, when you use the HTTP Authorization header or the query parameters for authentication, you use a varying combination of request elements to create the string to sign. For an HTTP POST request, the POST policy in the request is the string you sign.

  • For signing key, the diagram shows series of calculations, where result of each step you feed into the next step. The final step is the signing key.

  • When an AWS service receives an authenticated request, it recreates the signature using the authentication information contained in the request. If the signatures match, the service processes the request. Otherwise, it rejects the request.

For more information, see Elements of an AWS API request signature.

When to sign requests

When you write custom code that sends API requests to AWS, you must include code that signs the requests. You might write custom code because:

  • You are working with a programming language for which there is no AWS SDK.

  • You need complete control over how requests are sent to AWS.

While API requests authenticate access with AWS SigV4, AWS SDKs and the AWS CLI authenticate your requests by using the access keys that you provide. For more information about authenticating with AWS SDKs and the AWS CLI, see Additional resources.

Why requests are signed

The signing process helps secure requests in the following ways:

  • Verify the identity of the requester

    Authenticated requests require a signature that you create by using your access keys (access key ID, secret access key). If you are using temporary security credentials, the signature calculations also require a security token. For more information, see AWS security credentials programmatic access.

  • Protect data in transit

    To prevent tampering with a request while it's in transit, some of the request elements are used to calculate a hash (digest) of the request, and the resulting hash value is included as part of the request. When an AWS service receives the request, it uses the same information to calculate a hash and matches it against the hash value in your request. If the values don't match, AWS denies the request.

  • Protect against potential replay attacks

    In most cases, a request must reach AWS within five minutes of the time stamp in the request. Otherwise, AWS denies the request.

AWS SigV4 can be expressed in the HTTP Authorization header or as a query string in the URL. For more information, see Authentication methods.

Additional resources