Azure Shared Access Signature - Signature Did Not Match

Azure Shared Access Signature - Signature did not match

Short Answer:

Add comp=list&restype=container to your SAS URL and you should not get this error.

Long Answer:

Essentially from your SAS URL, Azure Storage Service is not able to identify if the resource you're trying to access is a blob or a container and assumes it's a blob. Since it assumes the resource type is blob, it makes use of $root blob container for SAS calculation (which you can see from your error message). Since SAS was calculated for mark blob container, you get this Signature Does Not Match error. By specifying restype=container you're telling storage service to treat the resource as container. comp=list is required as per REST API specification.

Receiving Signature did not match. String to sign used was... when trying to access Azure blob with SAS

Problem solved! The issues were:

1. I did indeed need to use the account key instead of the connection string, and
2. When appending the sasToken to the blobUrl, I needed to add ?... facepalm.

Final code is as follows:

const blockBlobClient = containerClient.getBlockBlobClient(blobName);
await blockBlobClient.upload(data, data.length, { blobHTTPHeaders: { blobContentType: contentType }});
let blobUrl = `https://${process.env.STORAGE_ACCOUNT}.blob.core.windows.net/${container}/${blobName}`;

const sasOptions = {
    containerName: containerClient.containerName,
    blobName: blobName,
    expiresOn: new Date(new Date().valueOf() + 86400),
    permissions: BlobSASPermissions.parse('r'),
    protocol: SASProtocol.https
};

const sharedKeyCredential = new StorageSharedKeyCredential(process.env.STORAGE_ACCOUNT, process.env.STORAGE_ACCOUNT_KEY);

const sasToken = generateBlobSASQueryParameters(sasOptions, sharedKeyCredential).toString();

blobUrl += `?${sasToken}`;

Azure Stored access policy, Signature did not match

I believe you are getting this error is because you have not specified the blob container name in your GetBlobSas() method. Because the blob container name is omitted, the SAS token is computed for $root blob container. Since the SAS token is computed for $root blob container and you are using it with another blob container, you are getting this authorization failed error.

Another issue I noticed is that you have not included expiry in your SAS token. It is not there in your access policy as well as when you get the SAS token using the access policy.

Please try with the following code:

// Build a SAS token for the given blob
 private string GetBlobSas()
 {
     // Create a user SAS that only allows reading for a minute
     BlobSasBuilder sas = new BlobSasBuilder 
     {
         Identifier = _storedPolicyID,
         ExpiresOn = DateTimeOffset.UtcNow.AddHours(1),
         BlobContainerName = _iconfiguration.GetValue<string>("StorageAccount:Container")
     };

     // Use the shared key to access the blob
     var storageSharedKeyCredential = new StorageSharedKeyCredential(
         _iconfiguration.GetValue<string>("StorageAccount:AccountName"),
         _iconfiguration.GetValue<string>("StorageAccount:AccountKey")
     );

     return '?' + sas.ToSasQueryParameters(storageSharedKeyCredential).ToString();
 }

The SAS token you will get from above will expire in 1 hour from the time it was created.

Signature did not match. String to sign used was rl

According to the instructions provided here, your stringToSign should conform to the following structure:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               signedResource + "\n"
               signedSnapshotTime + "\n" +
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct

Which is not the same as what you're doing. Essentially you're missing canonicalizedResource and signedResource parameters.

Please form your stringToSign properly and you should not get the error you're encountering. I think it should be something like (not tested though):

String stringToSign= "rl\n"+ 
                     "2021-03-11T08:08:46Z" +"\n" + 
                     "2021-03-12T08:08:46Z"+ "\n"+ 
                     "/blob/{myAccountName}/quickstartcontainer/sampleFile2813061026464365578.txt 2020-02-10\n"+ 
                     "\n"+ 
                     "\n"+ 
                     "\n"+ 
                     2020-02-10"+"\n"+ 
                     "b\n"+"\n"+"\n"+"\n"+"\n"+"\n";

Azure Blob Storage Shared Access Signature (SAS) - Signature did not match

You are trying to use the URL of templateBlob with a signature for parameterBlob.

Right there:

ParametersURL = templateBlob.Uri + parameterBlob.GetSharedAccessSignature(sasConstraints)

It'll work better with the correct variable:

ParametersURL = parameterBlob.Uri + parameterBlob.GetSharedAccessSignature(sasConstraints)

Cheers!

Shared Access Signature URL returns The requested URL does not represent any resource on the server

The reason you are getting this error is because you are using an incorrect type of SAS token (URL). You are creating a SAS token on the container which is a Service SAS kind of token which will only work on the container (or blob) for which The SAS token is acquired.

Considering BlobServiceClient.GetPropertiesAsync() is an account level operation, you would need to create an Account SAS token and use that to perform this operation.

Please create an Account SAS URL with at least read permission and use that in your code and you should not get this error.

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

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.

---

Related Topics