SAS Token Types: Account, Service, User Delegation

A Shared Access Signature (SAS) is a URI that grants granular, time-limited access to Azure Storage resources. It allows you to delegate access to a storage account's containers, blobs, queues, tables, or files without sharing the account key. The SAS token is appended to the storage resource URL as a query string parameter. The token contains all the necessary information for the storage service to authenticate the request: the target resource, permissions, expiry time, allowed IP addresses, and protocol (HTTPS only or HTTP/HTTPS).

SAS tokens are essential for scenarios where you need to provide temporary access to storage data, such as:

The three SAS types differ in scope, how they are generated, and their security properties.

An Account SAS is generated using the storage account key. It delegates access to one or more storage services (Blob, Queue, Table, File) at the account level. The token applies to all resources within the specified services, including containers, blobs, queues, tables, and shares. You can also include operations that are not permitted with a Service SAS, such as creating or deleting containers, listing containers, and setting container metadata.

How it works internally: 1. You create a string-to-sign that includes the signed permissions (e.g., r, w, d), signed services (b for Blob, q for Queue, t for Table, f for File), signed resource types (s for service-level, c for container-level, o for object-level), signed expiry time (ISO 8601 UTC), signed start time (optional), signed IP range (optional), signed protocol (https only or https,http), and the storage account version. 2. You sign this string with the storage account key (either primary or secondary) using HMAC-SHA256. 3. The resulting signature is appended to the URI as the 'sig' query parameter. 4. When a request arrives, the storage service reconstructs the string-to-sign from the request parameters and verifies the signature using the account key. If the signature matches and the token is not expired, the request is authorized.

Key components and defaults: - SignedServices: 'b' (blob), 'q' (queue), 't' (table), 'f' (file). You can combine, e.g., 'bq' for blob and queue. - SignedResourceTypes: 's' (service – e.g., get service properties), 'c' (container – e.g., create container), 'o' (object – e.g., read blob). - SignedPermission: 'r' (read), 'w' (write), 'd' (delete), 'l' (list), 'a' (add), 'c' (create), 'u' (update), 'p' (process). The permissions depend on the resource type. - SignedExpiry: Required. Maximum validity is 7 days from creation if no stored access policy is used. With a stored access policy, the expiry can be longer but is limited by the policy. - SignedStart: Optional. If omitted, the token is valid immediately. - SignedIP: Optional. Restricts requests to specific IP addresses or ranges (e.g., 192.168.1.0/24). - SignedProtocol: 'https' (default) or 'https,http'. HTTPS is recommended. - SignedVersion: Must match the storage service version (e.g., '2021-04-10').

Example Account SAS URL:

https://myaccount.blob.core.windows.net/?sv=2021-04-10&ss=b&srt=sco&sp=rwdl&se=2025-12-31T23:59:59Z&sig=...

Configuration and verification: - Generate via Azure Portal: Storage account → Shared access signature → Configure permissions → Generate SAS. - Generate via Azure CLI:

az storage account generate-sas --account-name myaccount --services b --resource-types sco --permissions rwdl --expiry 2025-12-31T23:59:59Z --https-only

New-AzStorageAccountSASToken -Service Blob -ResourceType Service,Container,Object -Permission "rwdl" -ExpiryTime (Get-Date).AddDays(7)

A Service SAS is generated using the storage account key or a stored access policy. It delegates access to a specific resource (container, blob, queue, table, file share) and its children. Unlike Account SAS, it cannot perform service-level operations like listing all containers. It is scoped to a single container or blob.

How it works internally: 1. The string-to-sign includes the same fields as Account SAS but also includes the resource URI (canonicalized resource) and optionally a stored access policy identifier. 2. The signature is computed using the account key or the policy key. 3. The token is appended to the resource URL, e.g., for a blob:

https://myaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2021-04-10&se=2025-12-31T23:59:59Z&sr=b&sp=r&sig=...

Key differences from Account SAS: - Scope: Single container or blob (not account-level). - Cannot perform service-level operations (e.g., list containers). - Can be associated with a stored access policy for easier management and revocation.

Stored Access Policy: A stored access policy is a set of permissions and expiry defined on a container, queue, table, or file share. When a Service SAS is created with a reference to a policy, the token inherits the policy's permissions and expiry. The policy can be modified or deleted to revoke all SAS tokens associated with it. This is a key security feature: without a policy, the only way to revoke a SAS is to regenerate the account key, which invalidates all SAS tokens and applications using that key.

Default values: - Maximum SAS token validity without a stored access policy: 7 days. - With a stored access policy: limited by the policy's expiry (can be up to the policy's expiry, which itself has no hard limit but should be reasonable).

Configuration and verification: - Generate via Azure Portal: Storage account → Containers → Container → Shared access tokens → Configure → Generate. - Generate via Azure CLI:

az storage container generate-sas --account-name myaccount --name mycontainer --permissions rwdl --expiry 2025-12-31T23:59:59Z --https-only

New-AzStorageContainerSASToken -Name mycontainer -Permission rwdl -ExpiryTime (Get-Date).AddDays(7)

A User Delegation SAS is the most secure SAS type. It is secured with Azure AD credentials and does not require the storage account key. Instead, you first obtain a user delegation key from Azure AD by authenticating with a user or service principal that has the appropriate RBAC role (e.g., Storage Blob Data Contributor). The user delegation key is then used to sign the SAS token.

How it works internally: 1. The client authenticates with Azure AD (e.g., using az login or managed identity). 2. The client requests a user delegation key from the storage service via a REST API call (e.g., POST https://myaccount.blob.core.windows.net/?restype=service&comp=userdelegationkey). The request must be authorized with an Azure AD token. 3. The storage service returns a user delegation key that includes:

- SignedOid: Object ID of the Azure AD user/principal that requested the key. - SignedTid: Tenant ID of the Azure AD tenant. - SignedStart: Start time of the key. - SignedExpiry: Expiry time of the key (maximum 7 days from start). - SignedService: 'b' (blob), 'd' (datalake), 'f' (file). Note: User Delegation SAS currently supports only Blob storage (including Data Lake Storage Gen2) and File storage. - SignedVersion: Storage version. - Value: The actual key material (a base64-encoded string). 4. The client then creates a string-to-sign for the SAS token, including the user delegation key's fields (SignedOid, SignedTid, SignedStart, SignedExpiry, SignedService, SignedVersion) plus the SAS-specific fields (permissions, resource, expiry, etc.). 5. The client signs the string with the user delegation key's Value (using HMAC-SHA256) to produce the signature. 6. The resulting SAS token is appended to the blob URL.

Key differences from Account/Service SAS: - No account key exposure: The storage account key is never used. - Azure AD integration: The SAS is tied to the identity that requested the user delegation key. The key expires after a maximum of 7 days, and the SAS token cannot exceed the key's validity. - Supported services: Blob (including Data Lake Storage Gen2) and File storage only (not Queue or Table). - Revocation: Revoking the user delegation key is not directly possible; you must change the RBAC role assignment or wait for the key to expire. However, the key is short-lived (max 7 days).

Default values and limits: - User delegation key maximum lifetime: 7 days. - SAS token maximum lifetime: 7 days (cannot exceed the key's expiry). - The user delegation key is cached by the client; the storage service does not maintain a session. The key is valid until its expiry, regardless of RBAC changes (except if the storage account key is regenerated, but that does not affect user delegation keys).

Configuration and verification: - Generate via Azure CLI:

# First obtain a user delegation key (requires authenticated Azure AD session)
az storage container generate-sas --account-name myaccount --name mycontainer --permissions rwdl --expiry 2025-12-31T23:59:59Z --auth-mode login --as-user

UserDelegationKey key = await blobServiceClient.GetUserDelegationKeyAsync(DateTimeOffset.UtcNow, DateTimeOffset.UtcNow.AddDays(7));
BlobSasBuilder sasBuilder = new BlobSasBuilder()
{
    BlobContainerName = "mycontainer",
    Resource = "c",
    ExpiresOn = DateTimeOffset.UtcNow.AddDays(7)
};
sasBuilder.SetPermissions(BlobContainerSasPermissions.Read | BlobContainerSasPermissions.Write);
string sasToken = sasBuilder.ToSasQueryParameters(key, accountName).ToString();

A company has a mobile app that allows users to upload profile pictures directly to Azure Blob Storage. The app backend generates a SAS token for each upload request. The token is scoped to a specific container (e.g., 'profile-pics') with write permission only, and expires after 5 minutes. This prevents users from overwriting other files or accessing the storage account. The backend uses a Service SAS with a stored access policy on the container. The policy sets the maximum expiry to 1 hour, but the token itself is short-lived. If a user's token is intercepted, the attacker has only 5 minutes to upload a malicious file, and the token only allows writes to that container. The stored access policy allows the admin to revoke all tokens by updating the policy. In production, the backend handles millions of requests daily. The key consideration is performance: generating a SAS token is a simple cryptographic operation, so it does not become a bottleneck. However, the backend must securely store the account key (for Service SAS) or use managed identity with User Delegation SAS for better security. The team chose Service SAS over User Delegation SAS because the app does not use Azure AD authentication for end users. Misconfiguration: if the token's expiry is too long (e.g., 1 day), a leaked token could be used for a longer time. The fix is to always use the shortest possible expiry.

A data engineering team runs Azure Synapse Analytics jobs that read from Data Lake Storage Gen2 (which is built on Blob Storage). The jobs need to read multiple containers but not write. The team uses an Account SAS with read and list permissions for the entire storage account, valid for 24 hours. This is necessary because the job needs to list containers and read blobs across multiple containers. A Service SAS would not work because it cannot list containers. The token is generated by a DevOps pipeline using the storage account key stored in Azure Key Vault. The token is passed to the Synapse job as a configuration parameter. The team ensures the token is only valid for the duration of the job (24 hours) and is restricted to the IP range of the Synapse workspace. A common mistake is to use a Service SAS and then try to list containers, which fails. Another mistake is to set the expiry too long (e.g., 30 days) for convenience, which increases risk. The team also implements monitoring: if the token is used from an unexpected IP, an alert is triggered.

A company needs to provide a third-party vendor with temporary access to download a specific blob (a monthly report). The vendor does not have Azure AD accounts. The company uses a Service SAS with read permission on the blob, expiring in 7 days (the maximum without a stored access policy). The token is sent via a secure email. The vendor uses a tool like Azure Storage Explorer to download the file. The company creates a stored access policy on the container with the same permissions and expiry, then generates the SAS token referencing that policy. This allows the company to revoke access early if needed by deleting the policy. A common error is to generate the SAS without a policy, making revocation impossible without regenerating the account key. Another issue: the vendor might share the token; to mitigate, the company restricts the token to the vendor's IP address range. If the vendor's IP changes, the token becomes invalid, requiring a new one. The company also logs all SAS usage via Azure Storage analytics logs.