Shared Access Signature (SAS) tokens allow you to grant limited, time-bound access to Azure storage resources without exposing your storage account key. The token is embedded in a signed URL that specifies exactly what permissions are granted and for how long. This URL can then be given to clients, enabling them to perform specific actions on blobs, files, queues, and tables within your storage account.
Types of SAS Tokens
There are three types of SAS tokens, each suited for different scenarios. A Service SAS is signed with the account key and grants access to specific resources within a single service, such as a single blob container or queue. An Account SAS, also signed with the account key, provides broader access across multiple services within the storage account, allowing operations like managing service properties. A User Delegation SAS is signed with Microsoft Entra credentials, applies only to blob storage, and offers enhanced security by avoiding the use of account keys entirely.
Creating and Configuring SAS Tokens
When creating a SAS token, you must define its permissions, set an expiration time, and optionally apply IP address restrictions. Permissions define the allowed actions, such as read, write, delete, or list. The expiration time sets a limit on how long the token is valid, and IP restrictions limit access to requests originating from specific IP addresses or ranges.
Best Practices for Generating SAS Tokens
To generate SAS tokens securely, always enforce HTTPS by limiting the token to HTTPS connections only, which prevents eavesdropping on the signed URL. Grant only the minimum necessary permissions to avoid over-privileged access, and set short expiration times to reduce the risk of token misuse. When applicable, use IP address restrictions to control access from specific network locations.
Revoking SAS Tokens
If a SAS token needs to be invalidated, the revocation method depends on the SAS type. For a User Delegation SAS, you revoke the associated user delegation keys, which invalidates all tokens generated with those keys. Be aware that due to caching, there may be a delay between the revocation process and the actual invalidation of the tokens.
Differentiate Shared Access Signature Types and Scopes
Each SAS type differs in its authorization method, scope, and security profile. The User Delegation SAS is secured with Microsoft Entra credentials, making it the most secure option because it eliminates the need to manage or expose storage account keys. It is supported only for Blob Storage and Data Lake Storage (using the blob and dfs endpoints) and must be an ad hoc SAS, meaning it cannot be associated with a stored access policy.
The Service SAS is signed with the storage account key and delegates access to a single Azure Storage service, such as Blob, Queue, Table, or File. It can be associated with a stored access policy, which provides centralized management and the ability to revoke access without changing the account key. The Account SAS is also signed with the storage account key but provides broader access across multiple storage services and can authorize service-level operations that a Service SAS cannot. Like the User Delegation SAS, it must be an ad hoc SAS.
Security Implications
Choosing the correct SAS type has significant security implications. The User Delegation SAS is recommended by Microsoft whenever possible because it leverages Microsoft Entra ID and avoids exposing account keys. When using Service or Account SAS tokens (Shared Key authorization), you must adhere to strict practices: always use HTTPS, implement short expiration times (one hour or less for ad hoc SAS), and associate Service SAS tokens with stored access policies to enable revocability.
Determining Appropriate Application
Select the correct SAS type based on your specific access requirements. Use a User Delegation SAS for Blob and Data Lake Storage scenarios, especially when clients authenticate via Microsoft Entra ID. Use a Service SAS for granular access to a single service when you need to leverage stored access policies for manageability. Use an Account SAS sparingly, only for complex scenarios requiring cross-service access or administrative operations not covered by other SAS types.
Implement Lifecycle Management and Security Best Practices for SAS
Time Management and Clock Skew
Managing the validity interval of a SAS is critical for maintaining security. Use near-term expiration times for ad hoc SAS tokens to limit the window of opportunity if a token is leaked. Setting the start time at least 15 minutes in the past helps account for clock skew, which prevents intermittent authorization failures across different machines. Client applications should be designed to automatically renew tokens well before they expire to ensure continuous service availability.
Stored Access Policies and Revocation
For centralized control, implement a Stored Access Policy (SAP) for a Service SAS. An SAP allows you to manage constraints like permissions and expiration dates on the server side. The primary benefit is the ability to revoke access immediately by deleting or modifying the policy without changing the storage account keys. However, there is a limit of five stored access policies per container when creating a revocation plan.
Least Privilege and Secure Distribution
Always apply the principle of least privilege when generating SAS tokens. Grant only the minimum required permissions to the specific resources a user needs. Use read-only access when data modification is not required, limit the resource scope to a single blob or container rather than the whole account, and force the use of HTTPS for all requests. Always distribute SAS tokens over secure connections to prevent man-in-the-middle attacks from intercepting the signature.
Expiration Policies and Monitoring
Organizations can enforce better lifecycle management by configuring a SAS expiration policy at the storage account level. This policy sets a recommended upper limit for the validity period of any SAS generated for that account. If a user creates a token that exceeds this limit, Azure can provide a warning or log the event. Monitoring these events through Azure Monitor and storage logs allows administrators to track how requests are authorized and identify potential security risks.