The MAC signature found in the HTTP request 'XXXX' is not the same as computed signature

This issue happens when the authorization signature is incorrect. In this blog, we will be covering the cause and troubleshooting of this issue. While the client application sends the request, it builds the authorization header by building a string to sign and encoding it with one of the AccountKey. Here are the main causes of this issue.

1. The StringToSign is correct, but it was not encoded correctly using Base64. In this case, you need to investigate the application code logic and ensure that the stringtosign in created properly. This documentation explains how to build the string to sign. The logic involved in the StringtoSign generation is below:

• Construct the String to Sign.
• Decode the Base64 storage key.
• Use the HMAC-SHA256 algorithm and the decoded storage key from previous step to compute a hash of the string to sign.
• Base64 encode the hash and include this in the Authorization header. Syntax of signature looks like below:

                   Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

2. The account key that was used to encode the StringToSign got renewed. If the application uses hard-coded accountkey and the storage key gets renewed or regenerated at the Storage side. It is possible that this causes this issue too since storage will try to validate the authorization header by computing the stringtosign and encode it with the new keys. Since keys differ, storage service will never be able to get the same signature as the one provided by your application. In that case, you could try to find out if there has been any regeneration events of the Storage access keys which correspond to the time of the issue. You can also double check the AccessKey used in your application and check if it’s valid.

You can check if there has been any Key Regeneration event that was done on the Azure Storage account from the Activity logs:

3. The client signed the authorization header using the wrong StringToSign. Refer this article to construct the signature string.

Troubleshooting steps to be followed:
1. You could also capture a Fiddler trace while reproducing your issue and look at the response body to see the server's string to sign. Compare this to the one used by the client (the application will need to log the string to string to sign used in their code). Below is the screenshot from fiddler for a failing scenario (error 403):

In the Response Body under the RAW section, you can see the String to sign used by the Server (Storage):                       

2. You can debug your application code and log the output to show the string to sign it used.
3. Compare the server's string to sign that you received in the fiddler response body with the client's string to sign. They should match.
4. If you are not creating the string to sign using REST API / manually in your code but using the Azure Storage SDK to build the string to sign then you can set a breakpoint on the buildstringtosign function and check the string to sign computed by the application.

Hope this helps.