How can I successfully send a rest call to listServiceSas to get access to a blob?

Thanks for the response! I prefer blob level access, but it isn't critical. I tested with the exact json above (and the container level canonicalizedResource)--getting the same error:

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:c837d92f-901e-0002-289e-00cb59000000 Time:2025-07-29T15:38:38.7473363Z</Message>

<AuthenticationErrorDetail>Signature did not match. String to sign used was r 2025-07-29T16:37:45.0000000Z /blob/<storageaccountnamehere>/deploy https 2023-08-03 c </AuthenticationErrorDetail>

</Error>

Double checking dates.. this is the exact string I am sending for expiry: 2025-07-29T16:37:45Z

It is interesting, the token response has milliseconds (even though I didn't send them):
"serviceSasToken":"sv=2023-08-03&sr=c&spr=https&se=2025-07-29T16%3A37%3A45.0000000Z&sp=r&sig=YGRWTr....

I am just not sure what is going on here.

Hello Jason Drinen

Thanks for the quick response!

There are two problems here API Version Mismatch: Your request body has signedVersion: "2023-01-01" but the string to sign shows 2023-08-03, and your SAS token also shows sv=2023-08-03 missing signedServices: The string to sign format suggests it's expecting the signedServices field, but it might not be included properly.

Please be informd that the listServiceSas API is automatically using a different storage service version than what you're specifying. When you call the API with api-version=2023-01-01, it seems the service is defaulting to 2023-08-03 for the actual SAS generation.

So Update your request body to use the version that the service is actually using:

{
  "canonicalizedResource": "/blob/{StorageAccountName}/{ContainerName}",
  "signedServices": "b",
  "signedResourceTypes": "co", 
  "signedPermission": "r",
  "signedProtocol": "https",
  "signedStart": "{startDateTime}",
  "signedExpiry": "2025-07-29T16:37:45Z",
  "signedVersion": "2023-08-03"
}

Change signedVersion from "2023-01-01" to "2023-08-03" Keep your datetime format as 2025-07-29T16:37:45Z (the service will add milliseconds automatically).

If the issue still persists could also try using the REST API version that matches your desired storage service version:

POST https://{storageaccount}.blob.core.windows.net/listServiceSas?api-version=2023-08-03

{
  "canonicalizedResource": "/blob/{StorageAccountName}/{ContainerName}",
  "signedServices": "b", 
  "signedResourceTypes": "co",
  "signedPermission": "r",
  "signedProtocol": "https",
  "signedExpiry": "2025-07-29T16:37:45Z",
  "signedVersion": "2023-08-03"
}

The version mismatch is definitely what's causing the signature calculation to fail. Try matching signedVersion to "2023-08-03" first.

Let me know if you have any questions or concerns. If this answers your query, do click "Accept the answer” for the same,

I had no idea that the signedVersion needed to match the API version in the url to the call. In switching this... I no longer get the token response, but now get an authorization error:

{"error":{"code":"AuthorizationFailed","message":"The client 'f2f40fXXXX' with object id 'f2f40fXXXX' does not have authorization to perform action 'Microsoft.Storage/storageAccounts/action' over scope '/subscriptions/bf119XXXX/resourceGroups/<storageaccountname>/providers/Microsoft.Storage/storageAccounts/listServiceSas' or the scope is invalid. If access was recently granted, please refresh your credentials."}}",

I've never received this.. always got back a token, but it never worked. I'm not sure if this is truly a permissions issue or not. I have a custom role and assignment at the resource group level that gives the app registration this action:

Microsoft.Storage/storageAccounts/listServiceSas/action

Here is the full custom role for reference:

{
    "id": "/subscriptions/bf1196cXXX/providers/Microsoft.Authorization/roleDefinitions/b5e29323XXX",
    "properties": {
        "roleName": "<MyRoleName>",
        "description": "Create W...",
        "assignableScopes": [
            "/subscriptions/bf1196cXXX/resourceGroups/<resourcegroupname>"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Web/sites/*",
                    "Microsoft.Web/serverfarms/read",
                    "Microsoft.Web/sites/hostNameBindings/*",
                    "Microsoft.Web/certificates/*",
                    "Microsoft.Storage/storageAccounts/listkeys/action",
                    "Microsoft.Resources/deployments/*",
                    "Microsoft.Storage/storageAccounts/listServiceSas/action"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}

I switched back to known versions:
api-version=2025-01-01
"signedVersion": "2024-11-04"

I am back to getting a token--resulting url with token still is not working, unfortunately. "Signature did not match" remains.

Hello Jason Drinen

If you are using api-version=2025-01-01, then signedVersion should also be set to 2025-01-01. If you are using signedVersion: "2024-11-04", ensure that the API version in the URL is also compatible with that version.

{signedPermissions}\n
{signedStart}\n
{signedExpiry}\n
{signedResource}\n
{signedServices}\n
{signedVersion}\n
{canonicalizedResource}

Each component should be on a new line, and there should be no extra spaces or characters. Ensure that the canonicalizedResource is correctly formatted. For a blob-level SAS, it should look like:

/blob/{StorageAccountName}/{ContainerName}/{BlobName}

For a container-level SAS, it should be:

/blob/{StorageAccountName}/{ContainerName}

Make sure that the signedPermissions field includes the correct permissions for the operation you are trying to perform (e.g., r for read). Ensure that the signedExpiry is in UTC format and does not include milliseconds. The format should be YYYY-MM-DDTHH:MM:SSZ.

Let me know if you have any question.