CAMPUX Cloud Bootcamp
Field notes · Security
SAS tokens

SAS tokens, explained: a temporary key that lives in a URL

By Victor Thomson16 July 20266 min read

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.

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:

TypeSigned withScope
User delegation SASMicrosoft Entra credentialsBlob / Queue / Table / Files
Service SASThe account keyOne storage service
Account SASThe account keyMultiple 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.

The catch: a SAS is a bearer token

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

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.

Further reading — the Microsoft docs
Drilled in Class 12 — Storage Accounts. Back to all field notes →