SAS tokens, explained: a temporary key that lives in a URL
You need to let one client read one blob for one hour — without handing over the master key to your whole storage account. A shared access signature is exactly that: scoped, time-limited access baked into a URL.
New to cloud? CAMPUX is a free, build-first course. Start here →
A storage account key is the master key to the building — anyone holding it can do anything to everything. So when a client just needs to download a single file, or upload to one container for the next ten minutes, sharing the account key is wildly over-granting. A shared access signature (SAS) is the answer. Microsoft's definition is exactly right: a SAS "provides secure delegated access to resources in your storage account," with granular control over what resources, which permissions, and how long. It is a temporary, scoped key that lives inside a URL.
What a SAS actually is
Mechanically, a SAS is a set of query parameters — permissions, a start and expiry time, the allowed resources — appended to a storage URL and cryptographically signed. Azure checks the signature and the parameters on each request; if they are valid, access is granted, otherwise it returns 403 Forbidden. So the URL itself carries both the grant and its proof. Hand someone https://acct.blob.core.windows.net/pics/cat.jpg?sv=...&sp=r&se=...&sig=... and they can read that one blob until the expiry — and nothing else.
The three types — and the one you should prefer
Not all SAS are equally safe, because they differ in what signs them:
| Type | Signed with | Scope |
|---|---|---|
| User delegation SAS | Microsoft Entra credentials | Blob / Queue / Table / Files |
| Service SAS | The account key | One storage service |
| Account SAS | The account key | Multiple services |
The distinction that matters: a service or account SAS is signed with the account key, so generating one means your code must hold that master key. A user delegation SAS is signed with Entra credentials instead — Microsoft explicitly recommends it "for superior security," because "you do not need to store your account key with your code." Same scoped, time-limited URL, but nobody had to keep the crown jewels lying around to mint it. When you can, that is the one to use.
The account key is the master key. A SAS is a day-pass with an expiry — and a user delegation SAS is one you can issue without touching the master key at all.
Whoever holds a valid SAS can use it — there is no further check of who they are. So if it leaks, it works for the attacker exactly as it would for you, until it expires. And Azure does not track or audit SAS generation. That is why the safety rules below are not optional niceties; they are how you keep a leak from becoming a breach.
The rules that keep a SAS safe
- Short expiry. Near-term expiration means a leaked SAS is useful to an attacker for minutes, not months. Do not issue year-long tokens.
- Least privilege. Read-only if read is all they need; one blob if one blob is all they touch. A SAS in an attacker's hands is only as dangerous as the permissions you baked in.
- Always HTTPS. Over plain HTTP a SAS can be intercepted and replayed. Distribute and use it only over TLS.
- Prefer user delegation SAS so the account key never enters your codebase.
- Have a revocation plan. A stored access policy lets you revoke a service SAS without rotating the whole account key — and setting a SAS expiration policy on the account warns when someone issues a too-long token.
The takeaway
A SAS is the right tool whenever a client needs some access to storage but should never hold the account key: a user uploading their own file, a partner pulling one report, a copy operation across accounts. Reach for a user delegation SAS, scope it to the least it needs, give it a short expiry, and keep it on HTTPS. Get that shape right and you have replaced "here is the master key, please be careful" with "here is a day-pass that expires this afternoon" — which is the difference between hoping and controlling. Say "a short-lived, least-privilege user delegation SAS" in an interview and you sound like someone who has secured storage, not just opened it.
Questions people also ask
What is a SAS token used for in Azure?
It grants a client scoped, time-limited access to a storage resource without handing over the account key. You set which resource, which permissions, and how long the access lasts, then sign those parameters into a URL. Anyone holding that URL gets exactly that access, and nothing more, until it expires.
How long does a SAS token last?
As long as you set it to, using a start and expiry time you choose when you generate it. There is no fixed default, so the discipline is yours: keep it near-term, minutes to hours for most client-facing links, so a leaked token stops being useful quickly.
Is a SAS token safe to share?
Only within its intended scope and lifetime, because a SAS is a bearer token: whoever holds it can use it, with no further identity check. Share it only over HTTPS, scope it to the least access needed, and give it a short expiry so a leak is contained instead of catastrophic.
What is the difference between a SAS token and an access key?
An account key is the master key to the entire storage account, full control, no expiry, no scoping. A SAS is a signed, temporary key derived from that trust, limited to specific resources, specific permissions, and a specific time window. A user delegation SAS goes further, signed with Entra credentials instead of the account key.
How do you revoke a SAS token?
A service SAS tied to a stored access policy can be revoked by changing or deleting that policy, no key rotation required. A SAS without a stored access policy cannot be revoked individually before it expires; your only lever is rotating the account key, which invalidates every SAS signed with it. This is another reason to keep expiries short.