Shared Access Signatures (SAS)

What is a SAS Token?

A SAS token is a query string appended to a storage resource URL that contains:

• Which resources can be accessed
• What operations are permitted (read, write, delete, list)
• When access expires
• Which IP addresses can use it (optional)
• A cryptographic signature to prevent tampering

https://mystorageaccount.blob.core.windows.net/images/photo.jpg
  ?sv=2022-11-02
  &ss=b
  &srt=o
  &sp=r
  &se=2026-05-08T18:00:00Z
  &st=2026-05-07T18:00:00Z
  &spr=https
  &sig=abc123xyz...

Anyone with this URL can read photo.jpg until the expiry time — no storage account key needed.

Three Types of SAS

1. Service SAS

Grants access to a specific resource in one storage service (Blob, File, Queue, or Table). Signed with the storage account key.

• Scope: Single service and resource
• Signed by: Storage account key
• Limitation: If account key is rotated, all Service SAS tokens are invalidated

2. Account SAS

Grants access to resources in one or more storage services. Can access service-level operations that Service SAS cannot (e.g., creating containers, listing queues). Also signed with the storage account key.

• Scope: Multiple services and resource types
• Signed by: Storage account key

3. User Delegation SAS (Recommended)

Grants access to Blob Storage only, but is signed with an Azure AD credential (managed identity or service principal) instead of the account key. Most secure option.

• Scope: Blob Storage only
• Signed by: Azure AD credentials
• Advantage: Can be revoked without rotating the storage account key
• Advantage: Auditable via Azure AD audit logs

SAS Parameters

Generating SAS Tokens

Via Azure Portal

1. Go to your Storage Account → Containers → select container or blob
2. Click Generate SAS
3. Configure permissions, start/expiry time, allowed protocols
4. Click Generate SAS token and URL
5. Copy the SAS token or full SAS URL

Via Azure CLI

# Get the expiry time (1 hour from now)
EXPIRY=$(date -u -d "1 hour" '+%Y-%m-%dT%H:%MZ')

# Generate blob SAS token
az storage blob generate-sas \
  --account-name mystorageaccount2026 \
  --container-name images \
  --name photo.jpg \
  --permissions r \
  --expiry $EXPIRY \
  --https-only \
  --output tsv

az storage account generate-sas \
  --account-name mystorageaccount2026 \
  --permissions rwdlac \
  --resource-types sco \
  --services b \
  --expiry 2026-05-08T00:00:00Z \
  --https-only \
  --output tsv

Stored Access Policies

A Stored Access Policy (SAP) is a named policy stored on a container that groups SAS parameters. SAS tokens can reference a SAP instead of embedding permissions directly. This gives you one critical capability: revocation.

# Create a stored access policy
az storage container policy create \
  --container-name images \
  --name readpolicy \
  --permissions r \
  --expiry 2026-12-31 \
  --account-name mystorageaccount2026 \
  --auth-mode login

# Generate SAS using the stored policy
az storage blob generate-sas \
  --container-name images \
  --name photo.jpg \
  --policy-name readpolicy \
  --account-name mystorageaccount2026 \
  --auth-mode login

Revoking a SAS Token

SAS tokens without a stored access policy cannot be revoked — they are valid until expiry. This is the biggest risk. Your options when a SAS is compromised:

Security Best Practices

• Use the shortest possible expiry time — minutes or hours, not days or months
• Grant minimum required permissions — read-only if the user only needs to read
• Use HTTPS only — never allow HTTP-only SAS tokens
• Use Stored Access Policies — enables revocation without rotating account keys
• Prefer User Delegation SAS — signed by Azure AD, auditable, revocable
• Restrict by IP — if you know the client's IP, restrict the SAS to that IP
• Never log SAS tokens — treat them like passwords
• Never embed SAS in client-side code — generate them server-side and pass to clients