Azure: Shared access signature generated by the SDK does not work in browser

Question

I'm generating a SAS through CloudStorageAccount like so:

var sharedAccessAccountPolicy = new SharedAccessAccountPolicy
{
     Permissions = SharedAccessAccountPermissions.Read | SharedAccessAccountPermissions.Write,
     Services = SharedAccessAccountServices.Blob,
     ResourceTypes = SharedAccessAccountResourceTypes.Object,
     SharedAccessExpiryTime = DateTime.UtcNow.AddYears(1),
     Protocols = SharedAccessProtocol.HttpsOnly
};

return cloudStorageAccount.GetSharedAccessSignature(sharedAccessAccountPolicy);

The problem is, when I append the SAS to a blob URL and paste the resulting string into a browser, I'm getting AuthenticationFailed (Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature) with a Signature did not match detail.

If I generate a SAS on the Azure portal (or Azure Storage Explorer), then the SAS works in the browser. I've noticed that there are differences between the SDK generated SAS and the portal generated SAS.

• The portal shows ?sv=2019-02-02 whereas the SDK shows ?sv=2018-03-28. Is there a way to manually configure this in the SDK to match the portal?
• The portal adds : to the SAS expiry date whereas the SDK adds %3A. Does this make a difference?

Here's the URL and SAS token by the SDK:

https://myaccount.blob.core.windows.net/mycontainer/giphy.gif?sv=2018-03-28&sig=<sigValue>&spr=https&st=2020-02-22T18%3A02%3A12Z&se=2021-02-22T18%3A02%3A12Z&srt=o&ss=b&sp=rw

Page source:

<?xml version="1.0" encoding="utf-8"?><Error><Code>AuthenticationFailed</Code><Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:c662b297-e01e-0065-19ac-e9e3d0000000
Time:2020-02-22T18:17:24.7226395Z</Message><AuthenticationErrorDetail>Signature did not match. String to sign used was myaccount
rw
b
o
2020-02-22T18:02:12Z
2120-02-22T18:02:12Z

https
2018-03-28
</AuthenticationErrorDetail></Error>

This is generated by the portal:

?sv=2019-02-02&ss=b&srt=o&sp=rw&se=2021-02-23T02:18:59Z&st=2020-02-22T18:18:59Z&spr=https&sig=<sigValue>

Answer 1

Found the answer myself after wasting many hours trying to identify the root cause. For some reason, the $spr=https substring must be added to the end of the token. When the client SDK generates the token, this substring appears towards the beginning and causes authentication issues.