Amazon Simple Storage Service
API Reference (API Version 2006-03-01)

Authenticating Requests: Using Query Parameters (AWS Signature Version 4)

As described in the authentication overview (see Authentication Methods), you can provide authentication information using query string parameters. Using query parameters to authenticate requests is useful when you want to express a request entirely in a URL. This method is also referred as presigning a URL.

A use case scenario for presigned URLs is that you can grant temporary access to your Amazon S3 resources. For example, you can embed a presigned URL on your website or alternatively use it in command line client (such as Curl) to download objects.

The following is an example presigned URL.

In the example URL, note the following:

  • The line feeds are added for readability.

  • The X-Amz-Credential value in the URL shows the "/" character only for readability. In practice, it should be encoded as %2F. For example:


The following table describes the query parameters in the URL that provide authentication information.

Query String Parameter NameExample Value

Identifies the version of AWS Signature and the algorithm that you used to calculate the signature.

For AWS Signature Version 4, you set this parameter value to AWS4-HMAC-SHA256. This string identifies AWS Signature Version 4 (AWS4) and the HMAC-SHA256 algorithm (HMAC-SHA256).


In addition to your access key ID, this parameter also provides scope (AWS region and service) for which the signature is valid. This value must match the scope you use in signature calculations, discussed in the following section. The general form for this parameter value is as follows:


For example:


For Amazon S3, the AWS-service string is s3. For a list of S3 AWS-region strings, see Regions and Endpoints in the AWS General Reference.


The date and time format must follow the ISO 8601 standard, and must be formatted with the "yyyyMMddTHHmmssZ" format. For example if the date and time was "08/01/2016 15:32:41.982-700" then it must first be converted to UTC (Coordinated Universal Time) and then submitted as "20160801T083241Z".


Provides the time period, in seconds, for which the generated presigned URL is valid. For example, 86400 (24 hours). This value is an integer. The minimum value you can set is 1, and the maximum is 604800 (seven days).

A presigned URL can be valid for a maximum of seven days because the signing key you use in signature calculation is valid for up to seven days.


Lists the headers that you used to calculate the signature. The following headers are required in the signature calculations:

  • The HTTP host header.

  • Any x-amz-* headers that you plan to add to the request.


For added security, you should sign all the request headers that you plan to include in your request.


Provides the signature to authenticate your request. This signature must match the signature Amazon S3 calculates; otherwise, Amazon S3 denies the request. For example, 733255ef022bec3f2a8701cd61d4b371f3f28c9f193a1f02279211d48d5193d7

Signature calculations are described in the following section.

Calculating a Signature

The following diagram illustrates the signature calculation process.

The following table describes the functions that are shown in the diagram. You need to implement code for these functions.

Lowercase()Convert the string to lowercase.
Hex()Lowercase base 16 encoding.
SHA256Hash()Secure Hash Algorithm (SHA) cryptographic hash function.
HMAC-SHA256()Computes HMAC by using the SHA256 algorithm with the signing key provided. This is the final signature.
Trim()Remove any leading or trailing whitespace.

URI encode every byte. UriEncode() must enforce the following rules:

  • URI encode every byte except the unreserved characters: 'A'-'Z', 'a'-'z', '0'-'9', '-', '.', '_', and '~'.

  • The space character is a reserved character and must be encoded as "%20" (and not as "+").

  • Each URI encoded byte is formed by a '%' and the two-digit hexadecimal value of the byte.

  • Letters in the hexadecimal value must be uppercase, for example "%1A".

  • Encode the forward slash character, '/', everywhere except in the object key name. For example, if the object key name is photos/Jan/sample.jpg, the forward slash in the key name is not encoded.


The standard UriEncode functions provided by your development platform may not work because of differences in implementation and related ambiguity in the underlying RFCs. We recommend that you write your own custom UriEncode function to ensure that your encoding will work.

The following is an example uri-encode() function in Java.

public static String UriEncode(CharSequence input, boolean encodeSlash) {
          StringBuilder result = new StringBuilder();
          for (int i = 0; i < input.length(); i++) {
              char ch = input.charAt(i);
              if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
              } else if (ch == '/') {
                  result.append(encodeSlash ? "%2F" : ch);
              } else {
          return result.toString();

For more information about the signing process (details of creating a canonical request, string to sign, and signature calculations), see Signature Calculations for the Authorization Header: Transferring Payload in a Single Chunk (AWS Signature Version 4). The process is generally the same except that the creation of CanonicalRequest in a presigned URL differs as follows:

  • You don't include a payload hash in the Canonical Request, because when you create a presigned URL, you don't know the payload content because the URL is used to upload an arbitrary payload. Instead, you use a constant string UNSIGNED-PAYLOAD.

  • The Canonical Query String must include all the query parameters from the preceding table except for X-Amz-Signature.

  • Canonical Headers must include the HTTP host header. If you plan to include any of the x-amz-* headers, these headers must also be added for signature calculation. You can optionally add all other headers that you plan to include in your request. For added security, you should sign as many headers as possible.

An Example

Suppose you have an object test.txt in your examplebucket bucket. You want to share this object with others for a period of 24 hours (86400 seconds) by creating a presigned URL.

The following steps illustrate first the signature calculations and then construction of the presigned URL. The example makes the following additional assumptions:

  • Request timestamp is Fri, 24 May 2013 00:00:00 GMT.

  • The bucket is in the US East (N. Virginia) region, and the credential Scope and the Signing Key calculations use us-east-1 as the region specifier. For more information, see Regions and Endpoints in the AWS General Reference.

You can use this example as a test case to verify the signature that your code calculates; however, you must use the same bucket name, object key, time stamp, and the following example credentials:


  1. StringToSign

    1. CanonicalRequest


    2. StringToSign


  2. SigningKey

    signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "<YourSecretAccessKey>","20130524"),"us-east-1"),"s3"),"aws4_request")

  3. Signature


    Now you have all information to construct a presigned URL. The resulting URL for this example is shown as follows (you can use this to compare your presigned URL):