Shared Access Signature (SAS)
What it is
A Shared Access Signature (SAS) is a delegated, time-limited, scoped token granting access to a specific storage account/service/container/queue/share without exposing the account key. It’s a signed URI with permissions + expiry embedded in query params.
Why it exists
You need to let a client (a script, a partner, a web app) access a slice of storage for a limited time without handing over the master key. SAS is the least-privilege, revocable mechanism.
Types (compare)
- Account SAS — permissions across services (blob/file/table/queue) at account scope.
- Service SAS — scoped to one service/container/queue/share.
- User delegation SAS (blob) — signed with Azure AD, more secure (no key needed), only for blobs.
- Optionally governed by a stored access policy on a container/share for easier revocation.
What params a SAS URI carries
- Permissions (r/w/d/l…), start & expiry times, allowed IPs & protocol, allowed services/resource types (sv, sp, st/se, sig signature).
sigis the HMAC signature proving the token wasn’t tampered with; key/identity used to create it.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: storage/common/storage-sas-overview
Exam notes
- 3 S’s to memorize: Sign (issuer needs permission to sign), Specify (permissions/expiry/scope/IPs), Send (anyone holding the token can use it until expiry).
- Regenerating the account key invalidates SAS created from it; user-delegation SAS is safer.
- Stored access policy gives central control/revocation vs standalone SAS.
- Minimize the blast radius: short expiry, least privilege, restrict IP/protocol.
Related
storage-access-keys · storage-account · storage-network-rule
📘 Source: Microsoft Learn — Sas Token