SALES: 1-800-867-1380

Create and Use a Shared Access Signature

Updated: April 22, 2014

A shared access signature is a URI that grants restricted access rights to containers, blobs, queues, and tables for a specific time interval. By providing a client with a shared access signature, you can enable them to access resources in your storage account without sharing your account key with them.

For an in-depth conceptual overview and tutorial on shared access signatures, see Shared Access Signatures.

Supported operations using shared access signatures include:

  • Reading and writing page or block blob content, block lists, properties, and metadata

  • Deleting, leasing, and creating a snapshot of a blob

  • Listing the blobs within a container

  • Adding, removing, updating, and deleting queue messages (in Storage Client Library 2.0 and newer)

  • Getting queue metadata, including the message count (in Storage Client Library 2.0 and newer)

  • Querying, adding, updating, deleting, and upserting table entities (in Storage Client Library 2.0 and newer)

The shared access signature URI query parameters incorporate all of the information necessary to grant controlled access to a storage resource. The URI query parameters specify the time interval over which the shared access signature is valid, the permissions that it grants, the resource that is to be made available, and the signature that the storage services should use to authenticate the request.

Additionally, the shared access signature URI can reference a stored access policy that provides an additional level of control over a set of signatures, including the ability to modify or revoke access to the resource if necessary. For more information on stored access policies, see Use a Stored Access Policy.

For information on the URI format of a shared access signature, see Delegating Access with a Shared Access Signature.

A shared access signature grants access to the resource specified by the URI's granted permissions. You should always use HTTPS to construct a shared access signature URI. Using HTTP with shared access signatures can make your storage account vulnerable to malicious use.

If a shared access signature grants access that is not intended for the general public, then it should be constructed with the fewest possible permissions. In addition, a shared access signature should be distributed securely to clients over a secure connection, should be associated with a stored access policy for the purpose of revocation, and should specify the shortest possible lifetime for the signature.

A shared access signature URI is associated with the account key used to create the signature, and the associated stored access policy (if any). If no stored access policy is specified, the only way to revoke a shared access signature is to change the account key.

The following code example creates an access policy on a container and then generates a shared access signature for the container. This shared access signature can then be given to clients:

// The connection string for the storage account.  Modify for your account.
string storageConnectionString =
   "DefaultEndpointsProtocol=https;" +
   "AccountName=myaccount;" +

// As an alternative, you can retrieve storage account information from an app.config file. 
// This is one way to store and retrieve a connection string if you are 
// writing an application that will run locally, rather than in Windows Azure.

// string storageConnectionString = ConfigurationManager.AppSettings["StorageAccountConnectionString"];

// Create the storage account with the connection string.
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(storageConnectionString);
// Create the blob client object.
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();

// Get a reference to the container for which shared access signature will be created.
CloudBlobContainer container = blobClient.GetContainerReference("mycontainer");

// Create blob container permissions, consisting of a shared access policy 
// and a public access setting. 
BlobContainerPermissions blobPermissions = new BlobContainerPermissions();

// The shared access policy provides 
// read/write access to the container for 10 hours.
blobPermissions.SharedAccessPolicies.Add("mypolicy", new SharedAccessBlobPolicy()
   // To ensure SAS is valid immediately, don’t set start time.
   // This way, you can avoid failures caused by small clock differences.
   SharedAccessExpiryTime = DateTime.UtcNow.AddHours(10),
   Permissions = SharedAccessBlobPermissions.Write |

// The public access setting explicitly specifies that 
// the container is private, so that it can't be accessed anonymously.
blobPermissions.PublicAccess = BlobContainerPublicAccessType.Off;

// Set the permission policy on the container.

// Get the shared access signature to share with users.
string sasToken =
   container.GetSharedAccessSignature(new SharedAccessBlobPolicy(), "mypolicy");

A client who receives a shared access signature can use it from their code to construct an object of type StorageCredentials. Those credentials can then be used to construct a CloudStorageAccount or a CloudBlobClient object for working with the resource, as shown in this example:

Uri blobUri = new Uri("");
// Create credentials with the SAS token. The SAS token was created in previous example.
StorageCredentials credentials = new StorageCredentials(sasToken);

// Create a new blob.
CloudBlockBlob blob = new CloudBlockBlob(blobUri, credentials);

// Upload the blob. 
// If the blob does not yet exist, it will be created. 
// If the blob does exist, its existing content will be overwritten.
using (var fileStream = System.IO.File.OpenRead(@"c:\Test\myblob.txt"))

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft