Azure Storage REST API with Shared Key Suddenly Returns 403 errors

Question

Azure Storage REST API with Shared Key Suddenly Returns 403 errors

Jared Buschkopf 256

I've had a web page that uploads files to and downloads files from Azure Storage using the Blob Storage REST API, authenticating with Shared Key, for some time now and suddenly today it is failing with 403 errors.

"AuthenticationFailedServer failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature...The Date header in the request is incorrect."

My code and environment have not changed. The code is constructing the signature and request headers per the documentation. The same date in the x-ms-date header on the http request is going into the signature in the spot for x-ms-date. Is this related to the issue I see on the Azure Status page for Key Vaults (https://status.azure.com/en-us/status) ? Is there a separate issue on the Azure side that is causing this? Has Microsoft changed the API?

I saw at least one other post about a 403 error with Azure Blob Storage not long ago. Maybe more folks than just me are facing this?

Update:
I also tried using Date instead of x-ms-date in the header and signature (and different combinations) but that didn't work either. Same 403 error every time complaining about the date. It matches the format of the date in the documentation so I'm stumped here.

0 comments

2 answers

Your answer

Answer 1

SaiKishor-MSFT 17,341 Moderator

@Jared Buschkopf The date format for Azure Storage is mentioned here- https://learn.microsoft.com/en-us/rest/api/storageservices/formatting-datetime-values

This mentions the ISO 8601 UTC formats as acceptable.

"The following ISO 8601 UTC formats are currently accepted by Azure Storage. The date value is required, while the time value is optional:

YYYY-MM-DD
YYYY-MM-DDThh:mm<TZDSuffix>
YYYY-MM-DDThh:mm:ss<TZDSuffix>
For the date value in these formats, YYYY is a four-digit year representation, MM is a two-digit month representation starting at 1, and DD is a two-digit day representation starting at 1.

If the optional time value is included, a literal designator T is required to separate the time value from the date value. For the time value, hh is the hour representation in 24-hour notation, mm is the two-digit minute representation, and ss is the two-digit second representation. Each of these values is expressed as an integer, starting at zero."

Does that help? Thanks!

Jared Buschkopf 256 Reputation points

2022-11-04T14:27:42.35+00:00

@SaiKishor-MSFT I hadn't seen that before. But I don't believe it is correct either. Even if it is Microsoft's intent for it to be that way, in reality that is not what the API accepts - at least not for Get Blob and Put Blob operations using Shared Key authorization.

I tried a request for Put Blob with the following in the x-ms-date header and x-ms-date in the signature:
2022-11-04T14:06:17Z

This seems to align with the format specified by your page. However I still got the 403 error:
Response Status Code = 403
Response Text = AuthenticationFailedServer failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:0d50f238-201e-0071-4356-f08ad4000000 Time:2022-11-04T14:06:17.3194853ZThe Date header in the request is incorrect.

I think you should take a closer look at the examples on the actual page for the authorization that our code is using. When I look at the documentation for Get Blob (https://learn.microsoft.com/en-us/rest/api/storageservices/get-blob) and Put Blob (https://learn.microsoft.com/en-us/rest/api/storageservices/put-blob) the notes about x-ms-date point me to the documentation for authorizing requests (https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-requests-to-azure-storage) and from there is a link to the specific page for Shared Key Authorization (https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) which is what provided a link for earlier. The examples on that page do not use dates in the ISO-8601 format.
Elliott deLaunay 0 Reputation points

2023-12-21T15:34:05.2166667+00:00

This is still an issue - I tried all those formats and was met with the same 403 error - what ended up working was just removing the Date or x-ms-date header altogether.

Answer 2

Jared Buschkopf 256

After much troubleshooting my colleague discovered that apparently the day in the date needs to be 0 padded. I guess I had been getting lucky all this time. It would help if the documentation had more information on the date format that could have helped here. I will submit feedback to Microsoft on that article.

SaiKishor-MSFT 17,341 Reputation points Moderator

2022-11-03T19:55:08.163+00:00

@Jared Buschkopf Thank you for reaching out to Microsoft Q&SA. I understand that you were having issues with Azure Storage REST API with Shared Key which was giving you 403 errors due to the date format which was fixed after you 0 padded the date.

Can you please provide more information on how the date format was given previously and how you corrected it later so I can reach out to our team to check on this? Thank you!
Jared Buschkopf 256 Reputation points

2022-11-03T20:02:45.3+00:00

Sure @SaiKishor-MSFT

API Calls would fail with this date in the header and signature of the request:
Wed, 2 Nov 2022 22:20:32 GMT

API Calls succeed with this date in the header and signature of the request:
Wed, 02 Nov 2022 22:20:32 GMT

The documentation at the link below just says "All authorized requests must include the Coordinated Universal Time (UTC) timestamp for the request". I couldn't find any mention of the actual format and the examples don't use a day less than 10. Here's one example from the documentation:
Fri, 26 Jun 2015 23:39:12 GMT

So the doc seems a bit ambiguous.

https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key

Share via

Azure Storage REST API with Shared Key Suddenly Returns 403 errors

2 answers

Your answer