Authenticating REST Requests

Every REST request requires a signature. The signature is used as the value for the Signature parameter in the URL being constructed. The string you use to compute the HMAC signature is constructed using one of the following two methods.

	Important
For both signature methods, do not URL encode the concatenated string before computing the signature. URL encode the computed signature and other query parameters as specified in RFC1738, section 2.2. In addition, make sure to encode the + character although it is not required by RFC1738. This is required because the + character is interpreted as a blank space by Sun Java classes that perform URL decoding.

Important

For both signature methods, do not URL encode the concatenated string before computing the signature. URL encode the computed signature and other query parameters as specified in RFC1738, section 2.2. In addition, make sure to encode the + character although it is not required by RFC1738. This is required because the + character is interpreted as a blank space by Sun Java classes that perform URL decoding.

Signature Version 1

Signature version 1 is the recommended and more secure method of signing requests. This version catches spoofing of any of the request parameters.

To calculate a signature (version 1)

Create the string you'll use when generating the signature:

Sort all request parameters alphabetically, ignoring case.
Include SignatureVersion in the list but not Signature. Do not list as "empty" any optional parameters that are not included in the request. In other words, if no value for ParameterA is specified in the request, do not include a ParameterA entry in this sorted list.
Form a string by concatenating each request parameter's name with its value.
The format of the string is:
```
Param-name1Param-value1Param-name2Param-value2...Param-nameNParam-valueN
```
The parameter names are case sensitive. Do not include any separators in this string, such as question marks (?), ampersands (&), or equals signs (=). Do not URL encode the parameter values.

Calculate an RFC 2104-compliant HMAC-SHA1 Signature using your Secret Access Key as the key and the string you just created.
For more information, see HMAC-SHA1 Signature and go to http://www.faqs.org/rfcs/rfc2104.html.
Convert the resulting value to base64.
URL encode the resulting value as specified in RFC 1738, section 2.2.
This is required because base64 encoding can result in characters that are not legal in a URL, such as plus signs (+), slashes (/), and equals signs (=).
Pass this final value in the Signature request parameter.

The following is a Java code snippet that shows how to construct the string.

/*
* Assumes parameters are in a java.util.Map named paramMap
* where the key is the parameter name.
*/
Set<String> sortedKeys = new TreeSet<String>(String.CASE_INSENSITIVE_ORDER);
sortedKeys.addAll(paramMap.keySet());

// Don't include Signature in the string to sign.
sortedKeys.remove("Signature");

StringBuilder stringBuilder = new StringBuilder();
for(String key : sortedKeys) {
    stringBuilder.append(key);
    stringBuilder.append(paramMap.get(key));
    }

System.out.println("String to sign : " + stringBuilder.toString());

Signature Version 0

Signature Version 0 is a less secure, but simpler method to sign requests. The SignatureVersion query parameter is not necessary when using this version.

To calculate a signature (version 0)

Concatenate the values of the Action and Timestamp request parameters, in that order.

You can use the Expires parameter instead of Timestamp.

Calculate an RFC 2104-compliant HMAC-SHA1 Signature, using your Secret Access Key as the key.
For more information, go to http://www.faqs.org/rfcs/rfc2104.html.
Convert the resulting value to base64.
URL encode the resulting value as specified in RFC 1738, section 2.2
This is required because base64 encoding can result in characters that are not legal in a URL, such as plus signs (+), slashes (/), and equal signs (=).
Pass the final value in the Signature request parameter.