Shared Access Signature (SAS)
What it is
A shared access signature (SAS) is a signed token appended to an Azure Storage URL. It delegates only the resource, permissions, and time period encoded in the token, without giving the recipient the storage account key.
Why it exists
Use a SAS when a client needs direct, limited access to storage but does not otherwise have that permission. A SAS is a bearer token: anyone who obtains a valid URL can use it as allowed until it expires or is otherwise invalidated.
Types (compare)
- User delegation SAS — supported for Blob Storage (including Data Lake Storage endpoints), and signed using a Microsoft Entra user delegation key. Microsoft recommends it when possible because code need not hold an account key.
- Service SAS — signed with a storage account key and delegates access to a resource in one storage service: Blob, Queue, Table, or Azure Files.
- Account SAS — also signed with an account key, and can cover resources in one or more storage services and some service-level operations.
- Stored access policy — a reusable constraint set on a container, table, queue, or file share for a service SAS. It is not available for user delegation or account SAS.
What params a SAS URI carries
- Permissions, resource scope, start and expiry time, and optionally allowed IP address and protocol.
- A signature created from the issuing identity or account key. Azure Storage checks the parameters and signature on each request.
Revocation and containment
Azure Storage does not track every SAS token that has been generated, so an ad hoc SAS cannot simply be looked up and individually revoked. Plan for a leak before issuing one:
- Give the least possible permission to the fewest resources, require HTTPS, and use a short lifetime.
- A service SAS that uses a stored access policy can have that policy changed or removed to revoke its permissions.
- Regenerating the relevant storage account key invalidates service SAS and account SAS signed with that key, but may disrupt other clients. It does not invalidate a user delegation SAS.
- Monitor failures and unexpected access. For higher-risk operations, use an application service that authenticates, validates, and audits the request instead of handing out a SAS.
Northwind example
Northwind’s customer app asks its API for permission to upload one receipt. After authenticating the customer, the API issues a short-lived, HTTPS-only user delegation SAS allowing upload to that customer’s specific blob path. It does not issue read, delete, or account-wide permission. If the URL leaks, the recipient can upload during its lifetime, so Northwind investigates and replaces the token rather than assuming it can discover every copy of the URL.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: storage/common/storage-sas-overview
Exam notes
- A SAS is delegated, scoped access — and a bearer token.
- Prefer user delegation SAS when possible; it uses Entra credentials rather than an account key.
- Stored access policies can control service SAS only. Do not promise individual revocation for an ad hoc SAS.
- Short expiry, HTTPS, narrow scope, and least privilege reduce the damage from a leak.
Related
storage-access-keys · storage-account · storage-network-rule
📘 Source: Microsoft Learn — Sas Token