Skip to main content
In this lesson, you will learn about Shared Access Signatures (SAS) in Azure—a security feature that allows you to grant limited access to your resources without exposing your storage account keys. SAS tokens help you define specific permissions, constrain the allowed time window, and restrict access by IP range, making them ideal for secure data sharing in Azure.

​
Types of SAS Tokens

There are three main types of SAS tokens in Azure:

​
1. User Delegation SAS

User Delegation SAS is the most secure type because it is generated using Microsoft Entra ID credentials, thus enforcing the same access controls and Conditional Access Policies supported by Microsoft Entra ID. For example, if you have a storage account holding sensitive financial data, you can generate a User Delegation SAS to provide temporary and controlled access for specific users or groups. To create a User Delegation SAS, you need appropriate storage roles, such as Storage Blob Data Contributor, Owner, or Reader.

​
2. Service SAS

A Service SAS grants delegated access to specific resources within a storage account and is authenticated using the storage account key. With a Service SAS, you can limit access to particular services like Blob, File, Queue, or Table. A common scenario is a web application using a Service SAS to allow image uploads to a Blob container for a short duration.

​
3. Account SAS

Account SAS tokens provide access to the entire storage account—including blob containers, queues, tables, and file shares—and are useful when multiple teams need concurrent access to different storage components.
The image illustrates three types of Shared Access Signatures (SAS): User Delegation SAS, Service SAS, and Account SAS, each represented with an icon.

​
Best Practices for Using SAS Tokens

  • Always Use HTTPS: Enforce secure connections (HTTPS) when generating a SAS token to ensure data encryption during transmission.
  • Prefer User Delegation SAS: When possible, choose User Delegation SAS since it leverages Microsoft Entra ID for stronger security.
  • Set Short Expiration Times: Limit the SAS token validity period to minimize the exposure risk.
  • Apply the Principle of Least Privilege: Grant only the permissions needed for the task at hand. For instance, if read-only access is sufficient, avoid providing write or delete permissions.
  • Assess Alternatives: In environments with elevated security requirements, consider using Microsoft Entra ID directly instead of relying solely on SAS tokens.
Ensure that your SAS token usage aligns with your overall security policies to maintain secure data access.
The image lists best practices for using Shared Access Signatures, including using HTTPS, setting minimal expiration times, and applying minimum-required privileges. It also notes that SAS isn't always the correct solution.

​
Anatomy of a SAS URL

A typical SAS URL is composed of the following components:
  • Base URL: e.g., medicalrecords.blob.core.windows.net
  • Container Name: e.g., patientimage
  • Blob or Object Name: e.g., a JPEG file
  • SAS Token Parameters: Includes permissions, start and expiry times, API version, storage type, and a cryptographic signature
The image explains the components of a Shared Access Signature (SAS) URL for accessing data, detailing parameters like access rights, start and end times, API version, storage type, and cryptographic signature.
For example:
  • SP: Lists permissions (R for read, W for write, D for delete, etc.)
  • ST/SE: Define the start and expiry times.
  • SV: Specifies the storage API version.
  • SRB: Indicates the type of storage resource (B for blob, F for file, etc.)
  • Signature: A unique cryptographic string that verifies authenticity.

​
Generating SAS Tokens via the Azure Portal

You can generate SAS tokens using the Azure portal before implementing them with SDKs:
  1. Open your storage account and navigate to a container (e.g., “airportcodes”) that holds a file (such as airports.json).
  2. Scroll down to the “Shared Access Signatures” section.
  3. Configure the SAS by choosing the services, resource types, permissions, start/end times, IP restrictions, and the protocol (ensure HTTPS is enforced).
  4. Click to generate the SAS token.
If you rotate the signing key, any previously generated SAS tokens will be revoked.
The image shows a Microsoft Azure portal interface for configuring a Shared Access Signature (SAS) for a storage account, with options for setting permissions, allowed services, and expiration dates.
After generating the SAS token, append it to your resource URL. Without a valid SAS token, trying to access a private container might return an error similar to:
Once the SAS token is appended, your access to the resource is granted.
The image shows a Microsoft Azure portal interface displaying details of a JSON file named "airports.json" within a storage container. It includes properties like URL, size, content type, and encryption status.

​
Accessing Data Using SAS Tokens

By appending the SAS token to the resource URL, you enable access to your resource content. For instance, when accessing an airport codes blob with a valid SAS token, you might receive a JSON response similar to the following:

​
Generating SAS Tokens Using the .NET SDK

Below are examples demonstrating how to generate SAS tokens programmatically using the .NET SDK.

​
1. User Delegation SAS

The following example illustrates how to generate a User Delegation SAS token:
This code initializes a BlobServiceClient using default Azure credentials, retrieves a user delegation key, configures the SAS parameters, and then constructs the full URL required to access the blob resource.

​
2. Account SAS

The following example shows how to generate an Account SAS using the storage account key:
This example uses the storage account key to generate an Account SAS token. Be sure to rotate your storage account key immediately if it is ever compromised, as it grants broad access to your storage resources.

​
Conclusion

Shared Access Signatures (SAS) provide a flexible and secure method to grant temporary access to Azure resources while maintaining strict security controls. By using User Delegation SAS, Service SAS, or Account SAS in accordance with best practices—such as enforcing HTTPS, limiting token lifespans, and applying the principle of least privilege—you can effectively manage secure access to your resources. We encourage you to experiment with these techniques using the Azure portal as well as SDKs like .NET to build a robust understanding of SAS token generation and management. For further details, check out relevant Azure Documentation and additional security best practices.

Watch Video