Create an account SAS

As of version 2015-04-05, Azure Storage supports creating a shared access signature (SAS) at the level of the storage account. Account SAS authorization is supported for the following Azure Storage services: Blob storage (including Data Lake Storage and dfs endpoints), Queue storage, Table storage, or Azure Files. By creating an account SAS, you can:

• Delegate access to service-level operations that aren't currently available with a service-specific SAS, such as the Get/Set Service Properties and Get Service Stats operations.

• Delegate access to more than one service in a storage account at a time. For example, you can delegate access to resources in both Azure Blob Storage and Azure Files by using an account SAS.

• Delegate access to write and delete operations for containers, queues, tables, and file shares, which are not available with an object-specific SAS.

• Specify an IP address or a range of IP addresses from which to accept requests.

• Specify the HTTP protocol from which to accept requests (either HTTPS or HTTP/HTTPS).

Stored access policies are currently not supported for an account SAS.

Authorize an account SAS

You secure an account SAS by using a storage account key. When you create an account SAS, your client application must possess the account key.

To use Microsoft Entra credentials to secure a SAS for a container or blob, create a user delegation SAS.

Construct an account SAS URI

The account SAS URI consists of the URI to the resource for which the SAS will delegate access, followed by a SAS token. The SAS token is the query string that includes all the information that's required to authorize a request to the resource. It specifies the service, resource, and permissions that are available for access, and the time period during which the signature is valid.

Specify the account SAS parameters

The required and optional parameters for the SAS token are described in the following table:

Specify the signedVersion field

The signedVersion (sv) field contains the service version of the shared access signature. This value specifies the version of Shared Key authorization that's used by this shared access signature (in the signature field). The value also specifies the service version for requests that are made with this shared access signature.

For information about which version is used when you execute requests via a shared access signature, see Versioning for Azure Storage services.

For information about how this parameter affects the authorization of requests made with a shared access signature, see Delegate access with a shared access signature.

Specify an IP address or IP range

As of version 2015-04-05, the optional signedIp (sip) field specifies a public IP address or a range of public IP addresses from which to accept requests. If the IP address from which the request originates doesn't match the IP address or address range that's specified on the SAS token, the request isn't authorized. Only IPv4 addresses are supported.

When you're specifying a range of IP addresses, keep in mind that the range is inclusive. For example, specifying sip=198.51.100.0 or sip=198.51.100.10-198.51.100.20 on the SAS restricts the request to those IP addresses.

The following table describes whether to include the signedIp field on a SAS token for a specified scenario, based on the client environment and the location of the storage account.

Specify the HTTP protocol

As of version 2015-04-05, the optional signedProtocol (spr) field specifies the protocol that's permitted for a request made with the SAS. Possible values are both HTTPS and HTTP (https,http) or HTTPS only (https). The default value is https,http. Note that HTTP only isn't a permitted value.

Specify the encryption scope

By using the signedEncryptionScope field on the URI, you can specify the encryption scope that the client application can use. It enforces the server-side encryption with the specified encryption scope when you upload blobs (PUT) with the SAS token. The GET and HEAD will not be restricted and performed as before.

The following table describes how to refer to a signed encryption scope on the URI:

This field is supported with version 2020-12-06 or later. If you add the ses before the supported version, the service returns error response code 403 (Forbidden).

If you set the default encryption scope for the container or file system, the ses query parameter respects the container encryption policy. If there's a mismatch between the ses query parameter and x-ms-default-encryption-scope header, and the x-ms-deny-encryption-scope-override header is set to true, the service returns error response code 403 (Forbidden).

When you provide the x-ms-encryption-scope header and the ses query parameter in the PUT request, the service returns error response code 400 (Bad Request) if there's a mismatch.

Construct the signature string

To construct the signature string for an account SAS, first construct the string-to-sign from the fields that compose the request, and then encode the string as UTF-8 and compute the signature by using the HMAC-SHA256 algorithm.

To construct the string-to-sign for an account SAS, use the following format:

StringToSign = accountname + "\n" +  
    signedpermissions + "\n" +  
    signedservice + "\n" +  
    signedresourcetype + "\n" +  
    signedstart + "\n" +  
    signedexpiry + "\n" +  
    signedIP + "\n" +  
    signedProtocol + "\n" +  
    signedversion + "\n"  
  

Version 2020-12-06 adds support for the signed encryption scope field. To construct the string-to-sign for an account SAS, use the following format:

StringToSign = accountname + "\n" +  
    signedpermissions + "\n" +  
    signedservice + "\n" +  
    signedresourcetype + "\n" +  
    signedstart + "\n" +  
    signedexpiry + "\n" +  
    signedIP + "\n" +  
    signedProtocol + "\n" +  
    signedversion + "\n" +
    signedEncryptionScope + "\n"  
  

Account SAS permissions by operation

The tables in the following sections list various APIs for each service and the signed resource types and signed permissions that are supported for each operation.

Blob service

The following table lists Blob service operations and indicates which signed resource type and signed permissions to specify when you delegate access to those operations.

¹ The Delete permission allows breaking a lease on a blob or container with version 2017-07-29 and later.
² The Delete Version permission allows deletion of blob versions with version 2019-12-12 and later.
³ The Permanent Delete permission allows permanent deletion of a blob snapshot or version with version 2020-02-10 and later.

Queue service

The following table lists Queue service operations and indicates which signed resource type and signed permissions to specify when you delegate access to those operations.

Table service

The following table lists Table service operations and indicates which signed resource type and signed permissions to specify when you delegate access to those operations.

¹ Add and Update permissions are required for upsert operations on the Table service.

File service

The following table lists File service operations and indicates which signed resource type and signed permissions to specify when you delegate access to those operations.

Account SAS URI example

The following example shows a Blob service URI with an account SAS token appended to it. The account SAS token provides permissions to the service, container, and objects. The table breaks down each part of the URI:

https://blobsamples.blob.core.windows.net/?sv=2022-11-02&ss=b&srt=sco&sp=rwlc&se=2023-05-24T09:51:36Z&st=2023-05-24T01:51:36Z&spr=https&sig=<signature>

Because permissions are restricted to the service level, accessible operations with this SAS are Get Blob Service Properties (read) and Set Blob Service Properties (write). However, with a different resource URI, the same SAS token could also be used to delegate access to Get Blob Service Stats (read).

See also

• Delegate access with a shared access signature
• Create a user delegation SAS
• Create a service SAS
• SAS error codes