(+351) 21 24 10006  ·  info@bconcepts.pt
Carnaxide, Lisbon

How to generate a SAS token for a blob in Azure with the CLI

João Barros 11 de July de 2026 4 min read

A SAS token (Shared Access Signature) grants temporary access to a file stored in Azure Storage without sharing the account key or making the blob public. With the Azure CLI you can generate a SAS token for a blob in just a few seconds, choosing the permissions and the expiry date. It is the safest way to share a report, an image or a backup for a limited time, and below you will learn how to do it step by step.

Prerequisites

  • Access to Azure Cloud Shell (Bash) in the portal — no installation needed — or the Azure CLI installed locally.
  • A Storage Account with a container and a blob (file) already uploaded.
  • The Storage Blob Data Reader (or Contributor) role assigned to your account, so you can generate the SAS without using the account key.

Step 1: Open Cloud Shell and confirm the blob

In the Azure portal, open Cloud Shell and choose the Bash environment. A big advantage of Cloud Shell is that you are already signed in, so you do not need to run az login. List the files in the container to confirm the exact name of the blob you want to share:

az storage blob list \
  --account-name aminhaconta \
  --container-name documentos \
  --auth-mode login \
  --output table

If your file appears in the table, you are ready to continue. Note the exact name, because you will need it right away.

Step 2: Store the names in variables

To keep the final command clean and easy to reuse, store the account, container and blob names in variables. Replace the example values with your own:

conta="aminhaconta"
contentor="documentos"
blob="relatorio-2026.pdf"

This way, if you later want to generate another SAS token, you only need to change these three values and repeat the final command.

Step 3: Set the expiry date

A good SAS token always has a short lifetime: the smaller the time window, the lower the risk. You can provide a fixed date in ISO 8601 format in UTC (for example 2026-07-12T18:00Z) or calculate it automatically. The command below creates an expiry two hours from now and prints the value:

expiry=$(date -u -d "+2 hours" '+%Y-%m-%dT%H:%MZ')
echo "$expiry"

Check on screen that the date makes sense before moving on. Remember that a user delegation SAS can be valid for a maximum of 7 days.

Step 4: Generate the SAS token

We have reached the main step: generating the SAS token for the blob. The recommended method uses your Microsoft Entra identity via --auth-mode login --as-user, so it does not expose the account key:

az storage blob generate-sas \
  --account-name "$conta" \
  --container-name "$contentor" \
  --name "$blob" \
  --permissions r \
  --expiry "$expiry" \
  --auth-mode login \
  --as-user \
  --full-uri \
  --output tsv

It is worth understanding each option: --permissions r grants read only (you could use w for write or d to delete); --as-user creates a user delegation SAS, signed by your identity and not by the account key; and --full-uri returns the complete URL, ready to use. The result is printed in the terminal thanks to --output tsv.

Verify the result

The command returns an address similar to this one (shortened here):

https://aminhaconta.blob.core.windows.net/documentos/relatorio-2026.pdf?sv=2024-11-04&se=2026-07-12T18:00Z&sr=b&sp=r&sig=...

Open that URL in an incognito browser window or test it with curl to confirm that the download works:

curl -o teste.pdf "PASTE_THE_SAS_URL_HERE"

Once the expiry date has passed, the same URL stops working and returns an authentication error. That behaviour is exactly what you want, and it proves that the access is truly temporary.

Conclusion

With a SAS token you control exactly who accesses a file and for how long, without revealing secrets or making anything public. From here you can explore other permissions, generate a container-level SAS to share several files at once, or automate this command inside a script. What will be the first file you share securely with a SAS token?