Amazon Signature Version 4 for API requests - Amazon Identity and Access Management
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Amazon Signature Version 4 for API requests

Important

If you use an Amazon SDK (see Sample Code and Libraries) or Amazon Command Line Interface (Amazon CLI) tool to send API requests to Amazon, you can skip the signature process, as 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 means you must specify which signature version to use. 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. Amazon Signature Version 4 (SigV4) is the Amazon signing protocol for adding authentication information to Amazon API requests.

You don't use your secret access key to sign API requests. Instead, you use the SigV4 signing process. Signing requests involves:

  1. Creating a canonical request based on the request details.

  2. Calculating a signature using your Amazon credentials.

  3. Adding this signature to the request as an Authorization header.

Amazon then replicates this process and verifies the signature, granting or denying access accordingly.

Symmetric SigV4 requires you to derive a key that is scoped to a single Amazon service, in a single Amazon region, on a particular day. This makes the key and calculated signature different for each region, meaning you must know the region the signature is destined for.

Asymmetric Signature Version 4 (SigV4a) is an extension that supports signing with a new algorithm, and generating individual signatures that are verifiable in more than one Amazon region. With SigV4a, you can sign a request for multiple regions, with seamless routing and failover between regions. When you use the Amazon SDK or Amazon CLI to invoke functionality that requires multi-region signing, the signature type is automatically changed to use SigV4a. For details, see How Amazon SigV4a works.

How Amazon SigV4 works

The following steps describe the general process of computing a signature with SigV4:

  1. 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 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.

  2. The signing key is a series of calculations, with the result of each step fed into the next. The final step is the signing key.

  3. When an Amazon 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 Amazon API request signature.

How Amazon SigV4a works

SigV4a uses asymmetric signatures based on public-private key cryptography. SigV4a goes through a similar scoped credentials derivation process as SigV4, except Sigv4a uses the same key to sign all requests without needing to derive a distinct signing key based on the date, service, and region. An Elliptic Curve Digital Signature Algorithm (ECDSA) keypair can be derived from your existing Amazon secret access key.

The system uses asymmetric cryptography to verify multi-region signatures, so that Amazon only needs to store your public keys. Public keys are not secret and can't be used to sign requests. Asymmetric signatures are required for multi-region API requests, such as with Amazon S3 Multi-Region Access Points.

The following steps describe the general process of computing a signature with SigV4a:

  1. 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 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.

  2. The signing key is derived from an Amazon secret access key through a series of calculations, with the result of each step fed into the next. The final step produces the keypair.

  3. When an Amazon service receives a request signed with Sigv4a, Amazon verifies the signature using only the public half of the keypair. If the signature is valid, the request is authenticated and the service processes the request. Requests with invalid signatures is rejected.

For more information about SigV4a for multi-Region API requests, see the sigv4a-signing-examples project on GitHub.

When to sign requests

When you write custom code that sends API requests to Amazon, 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 Amazon SDK.

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

While API requests authenticate access with Amazon SigV4, Amazon SDKs and the Amazon CLI authenticate your requests by using the access keys that you provide. For more information about authenticating with Amazon SDKs and the Amazon 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 Amazon 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 Amazon Web Services 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, Amazon denies the request.

  • Protect against potential replay attacks

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

Amazon 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