SAS tokens and stored access policies

A shared access signature (SAS) is a signed URL token that gives a client limited access to storage resources: which resource, which permissions, for how long. The token is not stored by Azure Storage; the service only checks the signature. The decision rule for exams: the key that signed the token decides how you can revoke it. An ad hoc service or account SAS dies only when its signing account key is rotated or it expires; a service SAS tied to a stored access policy is revoked by changing or deleting the policy; a user delegation SAS is revoked by revoking the user delegation key or the signer’s role assignments.

The ladder of revocation

Microsoft recommends a user delegation SAS wherever it can be used, because it does not depend on the account key. A user delegation key can be valid for up to seven days, and a user delegation SAS can be used with Blob Storage, Queue Storage, Table Storage and Azure Files according to the current overview page. The SAS overview also warns that you cannot audit SAS creation: anyone who can sign with the key or holds a suitable role can generate tokens unnoticed. A storage account can disallow Shared Key authorization to stop key-signed SAS tokens for blob and queue workloads.

Stored access policy in practice

A stored access policy is defined on a container, file share, queue or table. It holds a start time, an expiry time and permissions, under an identifier you choose (up to 64 characters). A service SAS then references that identifier and inherits the policy’s constraints.

Facts worth memorising:

• Up to five stored access policies per container, share, queue or table. A sixth returns a 400 error.
• A parameter such as expiry can be set in the token or in the policy, never both.
• Changes can take up to 30 seconds to take effect; in that window the SAS may fail with 403.
• Policies do not apply to account SAS or user delegation SAS.
• Microsoft’s guidance is to set the policy expiry far in the future and keep it updated, and to use short expiry on ad hoc tokens.

Worked example: a leaked partner link

A company gives a partner read access to the container exports using three tokens, one per department.

Setup A (ad hoc). Each token is a service SAS signed with key1, expiring in 90 days, with the expiry in the URL. One department’s token leaks. To stop it the team must rotate key1, which also breaks every other app that uses key1. Other departments’ tokens die too. This is the classic painful outcome.

Setup B (stored access policy). The team created three policies on the container: dept-finance, dept-hr, dept-ops, each with read permission and a long expiry, and issued one service SAS per policy. The finance token leaks. The team deletes dept-finance. Within about 30 seconds the finance token returns 403, while HR and Ops tokens and all key-based apps keep working. If the team later needs the finance link again, it creates a new policy with a new identifier.

Setup C (user delegation). The tokens are signed by a managed identity with a role that allows generating a user delegation key. A leak is handled by revoking the user delegation keys of the account, which invalidates all user delegation SAS tokens at once, or by removing the identity’s role assignment. This is coarser than deleting one policy, but it never touches the account keys, and the tokens no longer depend on a key that is shared by every app using it. Using identities well is covered in managed identities vs service principals.

Which exams test this

How exam questions are built around it

• “Revoke immediately without affecting other applications”: if tokens were created from a stored access policy, delete or edit the policy. Rotating account keys is the distractor that breaks other apps.
• “Tokens were not created from a policy”: now rotating the signing key is the only way, so the correct answer changes with one sentence of the scenario. Read it for “stored access policy”.
• “No account key may be used” or “Microsoft Entra credentials”: user delegation SAS.
• “Account SAS” plus “stored access policy”: this combination is impossible; the policy works only for service SAS.
• “Least privilege, time-limited access for an external party without a tenant account”: a short-lived, narrowly scoped SAS, preferably user delegation.
• “Application running in Azure needs storage access”: usually not a SAS at all but a managed identity with an RBAC role. A SAS is for clients that have no identity of their own.

Practice questions

Go deeper

• Grant limited access with shared access signatures (types, best practices)
• Define a stored access policy (limits and revocation)
• Create a user delegation SAS (key lifetime, revocation)
• Related guides: Azure RBAC vs Entra roles, Private endpoint vs service endpoint, Azure Policy vs RBAC vs locks