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.
https://s3.amazonaws.com/examplebucket/test.txt ?X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=
<your-access-key-id>/20130721/us-east-1/s3/aws4_request &X-Amz-Date=20130721T201207Z &X-Amz-Expires=86400 &X-Amz-SignedHeaders=host &X-Amz-Signature=
In the example URL, note the following:
The line feeds are added for readability.
X-Amz-Credentialvalue 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 Name||Example 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
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 Amazon S3, the
The date in ISO 8601 format, for example,
Provides the time period, in seconds, for which the generated
presigned URL is valid. For example,
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:
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,
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.
|Convert the string to lowercase.|
|Lowercase base 16 encoding.|
|Secure Hash Algorithm (SHA) cryptographic hash function.|
|Computes HMAC by using the SHA256 algorithm with the signing key provided. This is the final signature.|
|Remove any leading or trailing whitespace.|
URI encode every byte. UriEncode() must enforce the following rules:
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.
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
The Canonical Query String must include all the query parameters from the preceding table except for
Canonical Headers must include the HTTP
hostheader. 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.
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.
https://s3.amazonaws.com/examplebucket/test.txt ?X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIAIOSFODNN7EXAMPLE%2F20130524%2Fus-east-1%2Fs3%2Faws4_request &X-Amz-Date=20130524T000000Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host &X-Amz-Signature=
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
Signing Keycalculations use
us-east-1as 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:
GET /test.txt X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIOSFODNN7EXAMPLE%2F20130524%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20130524T000000Z&X-Amz-Expires=86400&X-Amz-SignedHeaders=host host:examplebucket.s3.amazonaws.com host UNSIGNED-PAYLOAD
AWS4-HMAC-SHA256 20130524T000000Z 20130524/us-east-1/s3/aws4_request 3bfa292879f6447bbcda7001decf97f4a54dc650c8942174ae0a9121cf58ad04
signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "
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):