Azure Documentation

Understanding and Using Shared Access Signatures (SAS) Tokens for Azure Storage

Shared Access Signatures (SAS) provide a secure way to grant limited access to resources in your Azure Storage account, such as blobs, containers, queues, and tables, without sharing your account access keys. This tutorial will guide you through understanding SAS tokens and how to generate and use them.

What is a Shared Access Signature (SAS)?

A SAS token is a URI that contains a security token in its query parameters. This token allows a client to have delegated access to storage resources in your account. With a SAS, you can grant clients access to specific resources for a specified period, with specific permissions, and from specific IP addresses or networks.

Types of SAS

• User Delegation SAS: Signed with Azure AD credentials. This type provides the highest level of security for access to blobs and containers.
• Account SAS: Signed with the storage account access key. It can grant access to all storage services and resources.
• Service SAS: Signed with the storage account access key. It grants access to a specific service (blob, queue, table, or file) and its resources.

When to Use SAS Tokens

• Granting temporary access to a specific blob for download or upload.
• Allowing a mobile application to upload data directly to blob storage.
• Granting read-only access to a container for a specific duration.
• Providing access to queues for message processing by external services.

Generating a SAS Token

You can generate SAS tokens using various methods:

1. Azure Portal: The easiest way for quick generation. Navigate to your storage account, then to the container or blob, and use the "Generate SAS" option.
2. Azure CLI: Useful for scripting and automation.
3. Azure PowerShell: Another scripting option.
4. Azure Storage SDKs: Programmatically generate SAS tokens within your applications.

Example: Generating a SAS Token using Azure CLI (for a blob)

This example generates a blob SAS token with read and write permissions, valid for 1 hour.

az storage blob generate-sas \
    --account-name mystorageaccount \
    --container-name mycontainer \
    --name myblob.txt \
    --permissions rwk \
    --expiry 2024-07-27T10:00:00Z \
    --https-only \
    --auth-mode login
            

Note: Replace placeholders like mystorageaccount, mycontainer, myblob.txt, and the expiry date with your actual values.

Using a SAS Token

Once you have generated a SAS token, it will be appended to the URI of the storage resource. A client can then use this full URI to access the resource with the granted permissions.

Example: Accessing a Blob with a SAS Token

The resulting URI will look something like this:

https://mystorageaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2022-11-02&ss=b&srt=sco&sp=rw&se=2024-07-27T10%3A00%3A00Z&st=2024-07-27T09%3A00%3A00Z&spr=https&sig=aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789ABCDEFGHIJKLMNO=
            

This URI can be used in applications, scripts, or even directly in a web browser (for read permissions) to access the specified blob.

Best Practices for SAS Tokens

• Principle of Least Privilege: Grant only the permissions that are absolutely necessary.
• Set Expiration Dates: Always specify an expiry date and time. Shorter validity periods are more secure.
• Use HTTPS: Always enforce HTTPS for SAS tokens to protect the token from eavesdropping.
• Avoid Storing Account SAS Long-Term: Account SAS tokens have broad permissions; generate them dynamically and with short expiry times when needed.
• Consider User Delegation SAS: For blob access, user delegation SAS tokens, signed with Azure AD, are generally more secure than account SAS.
• Protect Your SAS Tokens: Treat SAS tokens like credentials; they grant access to your data.

Conclusion

Shared Access Signatures are a powerful tool for securely managing access to your Azure Storage resources. By understanding their types, generation methods, and best practices, you can effectively grant granular and time-bound access to your data.