Authenticating Access to Your Azure Storage Account
Updated: November 26, 2014
Every request you make to the Azure storage services must be authenticated, unless it is an anonymous request against a public container or its blobs. The Azure client library simplifies this authentication process for you. There are two ways to authenticate a request against the storage services:
By using the Shared Key or Shared Key Lite authentication schemes for resources in the Blob, Queue, Table, and File services. These authentication schemes use an HMAC computed with the SHA-256 algorithm and encoded as Base64. The HMAC is constructed from a set of fields related to the request. For details on the protocol, see Authentication for the Azure Storage Services.
By creating a shared access signature. A shared access signature incorporates the credentials required for authentication on the URI in a secure fashion, together with the address of the resource being accessed. Because the shared access signature includes all data necessary for authentication on the URI, it can be used to grant controlled access to a resource in the Blob, Queue, or Table service, and can be distributed apart from your code. For details on the protocol, see Delegating Access with a Shared Access Signature.
As noted above, you can specify that a container should be public, in which case all read operations on the container and any blobs within it are available for anonymous access. An anonymous request does not need to be authenticated, so a user can perform the operation without providing account credentials. See Restrict Access to Containers and Blobs for details on managing container and blob access.
The Azure .NET managed library provides a few key classes for authenticating access to your storage account:
The CloudStorageAccount class represents your Azure storage account.
The StorageCredentials class stores two different types of credentials that may be used to authenticate a request: a storage account name and access key, which can be used for authenticating requests via the Shared Key and Shared Key Lite authentication schemes, or a shared access signature.
The CloudBlobClient, CloudQueueClient, and CloudTableClient classes provide a point of entry to the resource hierarchy for the Blob service, Queue service, and Table service, respectively. In other words, to work with containers and blobs, you will create a CloudBlobClient object; to work with queues and messages, a CloudQueueClient; and to work with tables and entities, a CloudTableClient. The client object can be created directly, by providing the service endpoint and a set of credentials, or it can be created from a CloudStorageAccount object by calling one of the CreateCloudBlobClient, CreateCloudQueueClient, or CreateCloudTableClient methods. These methods permit you to return a client object for one or more services from a CloudStorageAccount object defined with a single set of credentials.
Note that to access a container or blob anonymously, you do not need to create a CloudStorageAccount or a client object. Authentication is not required for anonymous access, so you can access the resource directly. Only certain read operations (using HTTP GET) are supported via anonymous access.
You can use the CloudStorageAccount.DevelopmentStorageAccount property to return a CloudStorageAccount object that references the well-known storage emulator account.
This property is useful when you are writing code that will only use the storage emulator, but if you will want to point your code to an Azure storage account when you have finished testing against the storage emulator, you may want to use a connection string. You can quickly modify the connection string to switch between storage accounts without modifying your code; see Configuring Azure Connection Strings for more information.
The simplest way to access an Azure storage account from your code is to create a new CloudStorageAccount object by providing your storage account name and access key in the form of a StorageCredentials object, and indicating whether to access the account using HTTP or HTTPS. Requests made via this CloudStorageAccount or one of its derived objects will use these credentials for authentication.
This CloudStorageAccount object uses the default endpoints for the storage services. The default service endpoints are
myaccount is the name of your storage account.
The following code example shows how to create a new CloudStorageAccount object using a reference to your account name and access key. It then creates a new CloudBlobClient object, followed by a new container:
//Account name and key. Modify for your account. string accountName = "myaccount"; string accountKey = "nYS0gln9fA7bvY+rwu2iWADyzSNITGkhM88J8HUoyofpK7C8fHcZc2kIZp6cKgYJUM74rHI82L50Iau4+9hPjQ=="; //Get a reference to the storage account, with authentication credentials. CloudStorageAccount storageAccount = new CloudStorageAccount(new StorageCredentials(accountName, accountKey), true); //Create a new client object. CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient(); // Retrieve a reference to a container. CloudBlobContainer container = blobClient.GetContainerReference("mycontainer"); // Create the container if it does not already exist. container.CreateIfNotExists(); // Output container URI to debug window. Console.WriteLine(container.Uri);
You can also access a storage account by explicitly specifying the service endpoints. This approach is useful in two scenarios:
When you are accessing a storage account via a shared access signature.
When you have configured a custom domain for your storage account and wish to use those custom endpoints to access the account. Note that the default endpoints continue to be available in addition to your custom endpoints.
A shared access signature is a means to provide controlled access to resources in your storage account to other clients. The shared access signature incorporates information about the resource to be accessed, the permissions to be granted, the interval for which the resource is to be available, and the access policy on the container, if one exists. For the purposes of authentication, this information is encapsulated in a string-to-sign that's encoded as UTF-8, and a signature is then constructed using the HMAC-SHA256 algorithm. The signature forms part of a token that clients can use to access your resource. For example, a client can use a shared access signature to create or delete a blob in your storage account, operations they would not have access to if the container were only marked as public. For more information on shared access signatures, see Shared Access Signatures, Part 1: Understanding the SAS Model and Delegating Access with a Shared Access Signature.