This chapter covers Shared Access Signatures (SAS) for Azure Storage, a critical security feature for granting delegated access to storage resources without exposing account keys. For the AZ-500 exam, SAS tokens appear in roughly 10-15% of questions related to storage security, often in scenarios involving secure access delegation, time-limited permissions, and compliance with least privilege. You will learn how SAS works, its types, configuration, common pitfalls, and exactly what the exam tests.
Jump to a section
Imagine you own a secure parking garage with 1000 spots. You have a security guard who checks IDs and charges fees. You want to allow a delivery driver to park for 30 minutes without giving them your master key or full access to the garage. You issue a valet ticket that includes: a specific spot (Blob container), a time window (30 minutes), and a permission (park only, no washing). The driver shows the ticket to the guard, who scans the QR code and validates: (1) the ticket is not expired, (2) the driver has not exceeded the allowed spot count, (3) the signature matches the guard's key. The guard then grants access only to that spot for exactly 30 minutes. The driver cannot access any other spots, cannot extend time, and cannot wash the car. If the ticket is lost, the guard cannot help—the driver must get a new ticket from the owner. This mirrors SAS: a token with specific permissions, expiry, and scope, signed by the storage account key, validated by Azure Storage without revealing the key.
What is a Shared Access Signature (SAS)?
A Shared Access Signature (SAS) is a URI token that grants delegated access to Azure Storage resources (Blobs, Files, Queues, Tables). It allows you to grant time-limited, permission-scoped access without sharing the storage account key. The token is signed using the storage account key (or a user delegation key) and includes parameters that define the scope, permissions, expiry, and allowed IP ranges. The exam expects you to understand three types: Service SAS, Account SAS, and User Delegation SAS.
How SAS Works Internally
When a client makes a request to Azure Storage with a SAS token, the following steps occur: 1. Request Reception: Azure Storage receives the request URL with the SAS token appended as query parameters. 2. Signature Validation: Storage extracts the signed parameters (signed permissions, signed expiry, etc.) and recomputes the signature using the same key (account key or user delegation key). It compares the computed signature with the provided 'sig' parameter. 3. Permission Check: Storage checks the 'signed permissions' (e.g., read, write, delete) against the requested operation. 4. Expiry Check: Storage compares the current time with the 'signed expiry' (se) parameter. If current time is past expiry, request is denied. 5. IP Range Check: If 'signed IP' (sip) is specified, Storage verifies the client's IP falls within the allowed range. 6. Protocol Check: If 'signed protocol' (spr) is set to HTTPS only, requests over HTTP are rejected. 7. Authorization: If all checks pass, Storage processes the request with the permissions specified.
Key Components of a SAS Token
A SAS token includes multiple query parameters. The most important ones for the exam:
sig: Signature, HMAC-SHA256 hash of the string-to-sign using the storage account key or user delegation key.
se: Signed expiry (UTC datetime). Example: 2025-12-31T23:59:59Z.
sp: Signed permissions (e.g., r, w, d, l, a, c, u, p). For Blob: r=read, w=write, d=delete, l=list, a=add, c=create, u=update, p=process.
spr: Signed protocol (https or http,https). Default is https,http.
sip: Signed IP range (CIDR format). Example: 168.1.5.0-168.1.5.255.
sst: Signed storage version (e.g., 2020-04-08).
ss: Signed services (b=blob, f=file, q=queue, t=table). Account SAS only.
srt: Signed resource types (s=service, c=container, o=object). Account SAS only.
Default values: If not specified, permissions are empty (no access), expiry is required, protocol defaults to both HTTP and HTTPS, and IP range is unrestricted.
Types of SAS
#### Service SAS
- Delegates access to a specific resource (e.g., a single blob, container, queue).
- Signature uses the storage account key.
- Cannot specify services or resource types; limited to one service.
- Example: https://myaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2020-04-08&se=2025-12-31T23:59:59Z&sr=b&sp=r&sig=...
#### Account SAS
- Delegates access to one or more storage services (blob, file, queue, table).
- Can specify service-level operations like Get Service Properties.
- Signature uses the storage account key.
- Required parameters: signed services (ss), signed resource types (srt), signed permissions (sp), signed expiry (se).
- Example: https://myaccount.blob.core.windows.net/?comp=list&ss=b&srt=c&sp=rl&se=2025-12-31T23:59:59Z&sig=...
#### User Delegation SAS
- Delegates access to Blob storage only.
- Signature uses a user delegation key, which is obtained via Azure AD credentials.
- Provides finer control and does not require the account key.
- Can be revoked by revoking the user delegation key.
- Example: https://myaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2020-04-08&se=2025-12-31T23:59:59Z&sr=b&sp=r&skoid=...&sktid=...&skt=...&ske=...&sks=...&sig=...
SAS Token Generation
You can generate SAS tokens using:
- Azure Portal: Navigate to storage account > Shared access signature. Configure permissions, dates, IPs, protocols, then generate.
- Azure CLI: az storage blob generate-sas --account-name <account> --container-name <container> --name <blob> --permissions r --expiry 2025-12-31T23:59:59Z
- Azure PowerShell: New-AzStorageBlobSASToken -Context $ctx -Container <container> -Blob <blob> -Permission r -ExpiryTime (Get-Date).AddHours(1)
- Azure Storage SDKs: Programmatic generation in .NET, Java, Python, etc.
SAS Best Practices
Always use HTTPS (spr=https).
Set the shortest possible expiry.
Use minimum required permissions.
Use a stored access policy for easier management and revocation.
Regenerate storage account keys periodically to invalidate SAS tokens signed with the old key (except user delegation SAS).
Use user delegation SAS when possible for Blob storage to avoid exposing account keys.
Stored Access Policy
A stored access policy is a server-side policy on a container, queue, table, or share that defines permissions and expiry. You can associate a SAS token with a stored access policy. Benefits:
Centralized management: update policy to change permissions or expiry without regenerating SAS tokens.
Revocation: delete or modify the policy to invalidate all associated SAS tokens.
Limitation: cannot specify IP range or protocol in the policy; must be in the SAS token.
Example: Create a policy named 'readonly' on a container with read permission and expiry 2025-12-31. Then generate a SAS token referencing that policy. If you later delete the policy, all tokens using it become invalid.
SAS and Azure AD Integration
User delegation SAS uses Azure AD to obtain a delegation key. This requires RBAC role 'Storage Blob Data Contributor' or higher. The key is valid for up to 7 days. Revocation is done by revoking the key via Revoke-AzStorageAccountUserDelegationKeys or Azure CLI az storage account revoke-delegation-keys. This is more secure than account SAS because the account key is not exposed.
Common Misconfigurations
Expiry set to far future (e.g., 10 years) – creates long-term risk.
Permissions too broad (e.g., full control instead of read-only).
Protocol set to HTTP – exposes token to interception.
No IP restriction – token can be used from any IP.
Using account SAS when service SAS is sufficient.
Sharing SAS tokens in URLs or logs – tokens are sensitive.
SAS Token Lifetime and Regeneration
Service SAS and Account SAS: if signed with account key, regenerating the account key invalidates all existing SAS tokens signed with that key (both active and future). This is a common exam trap: 'Regenerating the storage account key invalidates all SAS tokens.' True for account key-based SAS, but not for user delegation SAS.
User delegation SAS: revoked by revoking the delegation key, not by regenerating account keys.
SAS and Firewalls/Virtual Networks
SAS tokens can include an IP range (sip) to restrict usage to specific IPs. However, if the storage account has firewall rules that deny public access, SAS tokens from non-allowed IPs will be rejected even if the token's IP range matches. The storage account firewall takes precedence. This is a common exam scenario: 'You have a SAS token with IP range 10.0.0.0/8, but the storage account firewall only allows 192.168.0.0/16. The request fails.'
SAS and Azure Storage Analytics
Storage Analytics logs include SAS token details (permissions, expiry, etc.) for auditing. You can use these logs to detect token misuse. The exam may ask about logging SAS usage.
Identify resource and permissions
Determine the Azure Storage resource (e.g., a specific blob, container, queue) and the required permissions (read, write, delete, list, etc.). For example, you want to allow a client to download a blob but not delete it. The permissions string for a service SAS on a blob would be 'r' (read). For an account SAS, you also specify services (e.g., 'b' for blob) and resource types (e.g., 'o' for object).
Set expiry and start time
Define the validity window. The expiry (se) is mandatory. Start time (st) is optional; if omitted, the token is valid immediately. Use UTC format. For example, se=2025-12-31T23:59:59Z. The exam tests that the expiry must be in the future; otherwise, the token is invalid. Also, the start time cannot be in the future if you want immediate access.
Choose SAS type and generate token
Select Service SAS, Account SAS, or User Delegation SAS. Use Azure Portal, CLI, PowerShell, or SDK to generate the token. The generation process constructs the string-to-sign, computes the HMAC-SHA256 signature using the storage account key (or user delegation key), and appends it as the 'sig' parameter. The resulting URL includes the resource URI and all query parameters.
Distribute SAS token securely
Share the SAS URI with the client via a secure channel (e.g., HTTPS, encrypted email, or application). Do not embed in logs or client-side code that can be inspected. The exam emphasizes that SAS tokens are sensitive and should be treated like passwords. Use short expiry and minimal permissions to limit exposure.
Client makes request with SAS
The client uses the SAS URI to make a request to Azure Storage. For example, an HTTP GET request to the blob URL with the SAS token appended. Azure Storage receives the request, validates the signature, checks permissions, expiry, IP range, and protocol. If all pass, the request is authorized. If any check fails, a 403 (Forbidden) error is returned.
Enterprise Scenario 1: Secure File Sharing for External Partners
A logistics company needs to provide temporary download access to shipping manifests stored in Azure Blob Storage for multiple external partners. Each partner should only see their own files. The company creates a container per partner and generates a Service SAS token with read permissions, expiry set to 24 hours, and protocol restricted to HTTPS. The tokens are embedded in secure partner portals. At scale, they manage thousands of tokens daily. They use stored access policies on each container to centrally revoke all tokens for a partner if needed. A common issue is forgetting to set the expiry, leading to tokens that never expire. They automate token generation via Azure Functions, logging all SAS creation and usage. Performance is not impacted because SAS validation is lightweight and handled by Azure Storage front-end servers.
Enterprise Scenario 2: Time-Limited Upload for Mobile App Users
A photo-sharing app allows users to upload images directly to Azure Blob Storage from their mobile devices. The app backend generates a Service SAS token with write permissions for a specific blob path (e.g., userID/photo.jpg) with a 10-minute expiry. The mobile app uses the SAS URI to upload the photo. This avoids exposing the storage account key to mobile clients. At scale, millions of tokens are generated daily. The backend uses Azure AD authentication to obtain a user delegation key for generating SAS tokens, which adds an extra layer of security. Misconfiguration: if the SAS token allows overwriting, a malicious user could overwrite another user's photo. The solution is to use unique blob names and restrict permissions to create only (c permission) instead of write (w).
Scenario 3: Backup Service Access
A backup service uses Azure File Shares to store backups. The service uses an Account SAS token with read, write, and list permissions for the file service, with expiry set to 1 year. This is a common pattern for long-running services. However, if the storage account key is rotated, all tokens become invalid, potentially causing backup failures. To avoid this, they use user delegation SAS or stored access policies. The exam tests the impact of key rotation on SAS tokens.
AZ-500 Exam Focus: Shared Access Signatures
Objective 2.4: 'Implement and manage shared access signatures (SAS).' The exam tests your ability to choose the correct SAS type, configure permissions, understand expiry, and know revocation methods. Key areas:
SAS Types: You must distinguish between Service SAS, Account SAS, and User Delegation SAS. Common wrong answer: thinking Account SAS can only target a single resource (it can target multiple services). Another trap: confusing User Delegation SAS with Service SAS—User Delegation SAS is only for Blob storage and uses Azure AD.
Stored Access Policy: The exam often asks how to revoke multiple SAS tokens without regenerating keys. The correct answer is to modify or delete the stored access policy. Wrong answer: regenerating the storage account key (which would also work but is more disruptive and not the best practice).
Expiry and Time: The exam includes scenarios where a SAS token is generated but immediately fails. The likely cause: expiry is in the past or start time is in the future. Remember that times are UTC. Another trap: SAS tokens with no expiry set are invalid (expiry is required).
Permissions: Be precise about permission strings. For Blob: r=read, w=write, d=delete, l=list, a=add, c=create, u=update. The exam may ask which permission allows overwriting a blob (w or c? Actually, w allows write which includes overwrite; c only allows create but not overwrite).
Revocation: Regenerating the storage account key revokes all SAS tokens signed with that key (Service and Account SAS). User delegation SAS is revoked by revoking the delegation key. A common wrong answer: 'Regenerating the account key revokes all SAS tokens including user delegation SAS.' False.
IP and Protocol Restrictions: The exam includes scenarios where a SAS token works from one network but not another. Check the IP range (sip) and protocol (spr). Also, storage account firewall settings override SAS IP restrictions.
Edge Cases: SAS tokens can be used with Azure CDN, but the CDN must be configured to pass the SAS token to the origin. Another edge case: SAS tokens for table storage use different permissions (r, a, u, d).
How to Eliminate Wrong Answers:
If the question mentions revoking access for a subset of tokens, think stored access policy, not key regeneration.
If the question involves cross-service access (e.g., Blob and Queue), it must be Account SAS.
If the question emphasizes security and not sharing account keys, choose User Delegation SAS for Blob.
If the question says 'SAS token works but only from certain IPs', check the sip parameter.
If the question says 'SAS token fails after key rotation', it's likely an account key-based SAS.
SAS tokens require an expiry (se) parameter; no default expiry exists.
Regenerating storage account keys invalidates all Service and Account SAS tokens signed with that key.
User Delegation SAS is only for Blob storage and uses Azure AD; revoke by revoking the delegation key.
Stored access policies allow centralized management and revocation of Service SAS tokens.
SAS permissions for Blob: r=read, w=write, d=delete, l=list, a=add, c=create, u=update.
SAS tokens can be restricted by IP (sip) and protocol (spr); HTTPS is recommended.
Account SAS requires signed services (ss) and signed resource types (srt).
User Delegation SAS key is valid for up to 7 days.
SAS tokens are appended as query parameters to the storage resource URI.
Storage account firewall rules override SAS IP restrictions if they conflict.
These come up on the exam all the time. Here's how to tell them apart.
Service SAS
Scoped to a single resource (e.g., one blob, container, queue).
Cannot specify services (ss) or resource types (srt).
Signed with storage account key.
Can be associated with a stored access policy.
Example: access to one blob for read.
Account SAS
Scoped to one or more storage services (blob, file, queue, table).
Must specify signed services (ss) and signed resource types (srt).
Signed with storage account key.
Cannot be associated with a stored access policy.
Example: list containers across blob service.
Account SAS
Uses storage account key for signing.
Applies to blob, file, queue, and table services.
Cannot be revoked individually; key regeneration revokes all.
No Azure AD requirement.
Less secure because account key is used.
User Delegation SAS
Uses a user delegation key obtained via Azure AD.
Only applies to Blob storage.
Can be revoked by revoking the delegation key (individual revocation possible).
Requires Azure AD authentication (RBAC role).
More secure; no account key exposure.
Mistake
SAS tokens never expire if no expiry is set.
Correct
SAS tokens require an expiry parameter (se). If omitted, the token is invalid and requests fail with 403. There is no default expiry; you must specify one.
Mistake
Regenerating storage account keys invalidates all SAS tokens, including user delegation SAS.
Correct
Regenerating account keys invalidates only Service SAS and Account SAS that were signed with those keys. User delegation SAS uses a delegation key obtained via Azure AD and is not affected by account key regeneration.
Mistake
A Service SAS can grant access to multiple services (blob, file, queue, table).
Correct
A Service SAS is scoped to a single resource within a single service (e.g., a specific blob or container). To grant access to multiple services, you need an Account SAS.
Mistake
SAS tokens are secure and can be shared in URLs without risk.
Correct
SAS tokens grant access to storage resources and should be treated like passwords. They should be transmitted over HTTPS and not exposed in logs, client-side code, or URLs that are cached.
Mistake
Stored access policies can be used with any SAS type.
Correct
Stored access policies are only supported for Service SAS (on containers, queues, tables, and file shares). Account SAS and User Delegation SAS cannot be associated with a stored access policy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Service SAS is scoped to a single resource within one storage service (e.g., a specific blob or container). Account SAS can target multiple services (blob, file, queue, table) and supports service-level operations. Service SAS can be associated with a stored access policy; Account SAS cannot. Both are signed with the storage account key. Choose Service SAS for fine-grained access to a specific resource; choose Account SAS for cross-service access or service-level operations.
For Service SAS and Account SAS signed with the account key, you can regenerate the storage account key to invalidate all tokens using that key. Alternatively, if the SAS is associated with a stored access policy, you can modify or delete the policy to revoke tokens. For User Delegation SAS, revoke the user delegation key using `Revoke-AzStorageAccountUserDelegationKeys` or Azure CLI `az storage account revoke-delegation-keys`. Note that regenerating account keys does not affect User Delegation SAS.
Permissions are specified as a string of characters: r (read), w (write), d (delete), l (list), a (add), c (create), u (update). For example, 'r' allows reading a blob; 'rw' allows read and write. The exam often tests that 'c' (create) allows creating new blobs but not overwriting existing ones, while 'w' (write) allows overwriting. For containers, 'l' allows listing blobs.
Yes, but the SAS token's IP range (sip) must be a subset of the firewall's allowed IP ranges. Additionally, the storage account firewall must allow public access from the client's IP. If the firewall denies all public access, even a valid SAS token will be rejected. The firewall rules are evaluated before the SAS token's IP restriction.
A stored access policy is a server-side policy on a container, queue, table, or file share that defines permissions and expiry. You can associate a Service SAS with a policy. Benefits: you can update the policy to change permissions or expiry without regenerating SAS tokens, and you can revoke all tokens by deleting or modifying the policy. This is a best practice for managing many SAS tokens.
Use `az storage blob generate-sas` for a blob, `az storage container generate-sas` for a container, etc. Example: `az storage blob generate-sas --account-name myaccount --container-name mycontainer --name myblob.txt --permissions r --expiry 2025-12-31T23:59:59Z --https-only`. This outputs the SAS token (without the leading '?'). Append it to the blob URL to form the full URI.
For Service SAS and Account SAS signed with the account key, yes, regenerating the key invalidates all existing tokens. For User Delegation SAS, no, because it uses a delegation key obtained via Azure AD. The exam tests this distinction: regenerating account keys affects only account key-based SAS.
You've just covered Shared Access Signatures (SAS) for Storage — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?