AZ-104 · Implement and manage storage · Updated August 7, 2026
Shared Access Signatures (SAS) in Azure Storage: Account, Service, and User Delegation SAS Explained
A shared access signature (SAS) is a token appended to the URI of an Azure Storage resource that grants a client time-limited access without handing over the full storage account key. Azure Storage supports three distinct SAS types, account SAS, service SAS, and user delegation SAS, and they differ in what they can scope, how they’re signed, and how securely they can be managed. As an administrator, choosing the wrong one isn’t usually a functional mistake so much as a security one, and it’s exactly the distinction AZ-104 spends the most time probing.
How a SAS is authorized
Every SAS token is a signature computed over a set of parameters (which resource, which permissions, what time window) and signed with a key. That signing key is where the three types actually diverge.
| SAS type | Signed with | Authorization checked against |
|---|---|---|
| Account SAS | Storage account key | Shared Key |
| Service SAS | Storage account key | Shared Key |
| User delegation SAS | User delegation key | Microsoft Entra ID |
A service SAS and an account SAS are both signed with the storage account’s own access key, meaning whoever creates one needs either direct access to that key or the Microsoft.Storage/storageAccounts/listkeys/action permission. A user delegation SAS is signed instead with a temporary user delegation key that Azure Storage issues in exchange for a valid Microsoft Entra ID token, so no account key ever needs to exist in the hands of whoever generates it.
Account SAS
An account SAS is the broadest of the three. It can delegate access across more than one storage service in the same account (Blob, Queue, Table, and File Storage together, rather than one at a time), and it’s the only SAS type that can authorize service-level operations, such as Get/Set Service Properties or Get Service Stats. It also grants read, write, and delete permissions that a service SAS simply doesn’t expose. That breadth is also its liability: an account SAS with generous permissions and a long expiry is close to handing out the account key itself.
Service SAS
A service SAS scopes access to a single Azure Storage service, delegating to one container, blob, queue, table range, or file share at a time rather than the whole account. It’s signed with the account key like an account SAS, but its narrower scope makes it the more common choice for delegating access to one specific resource, and it’s the only SAS type that can be tied to a stored access policy.
User delegation SAS
A user delegation SAS is authorized entirely through Microsoft Entra ID rather than the account key, and it’s supported for Blob Storage (including Data Lake Storage), Queue Storage, Table Storage, and Azure Files. To create one, the requesting security principal needs an Azure role that includes the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action, scoped at the storage account, resource group, or subscription level. Built-in roles like Storage Blob Data Contributor, Storage Blob Data Owner, and Storage Blob Data Reader all include it.
There’s a practical constraint worth remembering here, confirmed in Microsoft’s guidance on creating a user delegation SAS: the underlying user delegation key is valid for a maximum of seven days from its start time, regardless of what expiry you set on the SAS itself. A user delegation SAS configured to expire in thirty days will stop working after seven, because the key that signs it has already expired.
Stored access policies
A stored access policy is defined on a resource container, a blob container, queue, table, or file share, and it lets an administrator centrally manage the start time, expiry, and permissions for one or more SAS tokens without regenerating the storage account key. Revoking access is as simple as modifying or deleting the policy; every SAS token referencing it stops working immediately, rather than requiring a key rotation that would also break every other application relying on that key. A container supports up to five stored access policies at once.
Stored access policies only work with a service SAS. Both the account SAS and the user delegation SAS must be ad hoc, meaning their start time, expiry, and permissions are baked directly into the token itself and can’t be centrally revoked through a policy.
Why user delegation SAS is Microsoft’s recommended approach
Microsoft Learn states plainly that a user delegation SAS should be used whenever possible, and the reasoning holds up under scrutiny. Because it’s tied to Microsoft Entra credentials rather than a shared secret, there’s no account key embedded in application code or configuration for an attacker to extract. Access is scoped through ordinary RBAC role assignment, so removing a user’s Storage Blob Data role revokes their ability to mint new SAS tokens the same way it revokes any other Entra-governed permission, and existing tokens can additionally be invalidated en masse by revoking the account’s delegation keys.
Key-signed SAS tokens don’t offer that isolation. If an account key leaks, every service SAS and account SAS ever signed with it is compromised until the key is rotated, and rotating the key also breaks every other application authenticating with it directly. Organizations that want to enforce user delegation SAS as the only option can pair it with the storage account’s “Disallow Shared Key access” setting, which blocks Shared Key authorization outright, so a key-signed account SAS or service SAS can no longer be created or used against that account at all.
Where this intersects with resource locks
A ReadOnly resource lock on a storage account blocks the List Keys operation, which means nobody can mint a new account SAS or service SAS signed with the account key while that lock is in place, even to replace a token that’s about to expire. A user delegation SAS isn’t affected the same way, since generating one relies on an Entra role assignment rather than a call to List Keys, which is one more practical reason it holds up better under routine governance controls.
How the AZ-104 exam tests this
- A scenario asks which SAS type can grant access across Blob, Queue, and Table Storage in a single token, plus service-level operations. That’s the account SAS, the only type broad enough to span services and expose those operations.
- A scenario wants centralized, immediate revocation of access without rotating the storage account key. That calls for a service SAS backed by a stored access policy, since the account SAS and user delegation SAS can’t reference one.
- A scenario emphasizes avoiding storage account keys in application code as a security requirement. The answer is a user delegation SAS, authorized through Microsoft Entra ID instead of Shared Key.
- A scenario asks for a user delegation SAS valid for more than seven days. That’s a trap. The user delegation key backing it caps out at seven days regardless of the SAS’s own expiry setting.
- A scenario describes an application unable to generate new account-key-signed SAS tokens after a ReadOnly lock was applied to the storage account. This tests the same List Keys dependency covered in the resource locks article, and why user delegation SAS avoids it.
- A scenario compares an account SAS to a service SAS for a single-container delegation use case. The narrower, more auditable choice is the service SAS; reaching for account SAS here grants more than the scenario needs.
SAS tokens sit alongside RBAC and storage keys as one of three ways to authorize access to storage data, and picking between them is a recurring theme across the Implement and manage storage domain. For the rest of what AZ-104 covers in this area, see the AZ-104 study guide.