Skip to main content
Shared Access Signature (SAS) is a secure, time-limited mechanism in Azure Storage that lets you grant granular access to storage resources—blobs, files, queues, and tables—without sharing your account keys. SAS tokens encode permissions, resource scope, time windows, IP restrictions, and protocol constraints in a URL query string so clients can access storage resources directly while you retain control. Key benefits:
  • Fine-grained access control (read, write, delete, list, etc.).
  • Time-limited access to reduce risk.
  • Option to delegate via Azure AD (user-delegated SAS) to avoid using account keys.
Types of SAS
SAS TypeScopeBest use case
Service SASAccess to a specific resource in a service (e.g., a blob or container)Grant access to a particular blob or container for clients or apps.
Account SASAccess across services within a storage account (blob, file, queue, table)Allow cross-service operations (e.g., read from blob and write to queue) across the same storage account.
User-delegated SASDelegated via Microsoft Entra ID (Azure AD) using a user delegation keyUse Azure AD identities to issue SAS without relying on account keys; better for enterprise scenarios and key rotation.
A presentation slide titled "Shared Access Signature" showing two colorful boxes labeled "Fine-tuned access" and "Three types of SAS keys" on the left, and a detailed SAS configuration panel with checkboxes for services, permissions, start/end times, IPs and protocols on the right. The slide also includes a small copyright note "KodeKloud" and a decorative "S" logo.
SAS structure and signing
A SAS URL has two parts: the resource endpoint (the storage resource to access) and the SAS token (query string describing permissions, allowed times, IPs, protocols, and the cryptographic signature). The signature is generated by signing the token with an account key (service/account SAS) or a user delegation key obtained after authenticating with Azure AD (user-delegated SAS).
Understanding a SAS URL
  • Resource endpoint — the base URL of the target resource, for example:
https://kodekloud.blob.core.windows.net
  • SAS token — query parameters specifying permissions, scope, duration, and signature. Common parameters include:
ParameterMeaningExample / Notes
svStorage service version2022-11-02
ssServices the SAS applies to (b = blob, f = file, t = table, q = queue)ss=b
srtResource types (s = service, c = container, o = object)srt=sco
spPermissions (r = read, w = write, d = delete, l = list, a = add, c = create, u = update)sp=r
stStart time (UTC)st=2023-12-10T15:14:50Z
seExpiry time (UTC)se=2023-12-10T23:14:50Z
sipAllowed client IP or rangesip=203.0.113.5-203.0.113.10
sprAllowed protocols (https or https,http)spr=https (use HTTPS-only when possible)
sigHMAC signature computed using the signing keysig=...
Example SAS token (appended to a resource URL): 
?sv=2022-11-02&ss=b&srt=sco&sp=r&st=2023-12-10T15:14:50Z&se=2023-12-10T23:14:50Z&spr=https&sig=P3kV00LVZA66w%2FjwiKVrUDe8X%2BBZQjCAyfpUPf1axZe0%3D
Full SAS URL (resource endpoint + SAS token): 
https://<your-storage-account>.blob.core.windows.net/images/City1.jpg?sv=2022-11-02&ss=b&srt=sco&sp=r&st=2023-12-10T15:14:50Z&se=2023-12-10T23:14:50Z&spr=https&sig=...
If the SAS token is modified or expired, access will be denied. Walkthrough — Generate a SAS in the Azure portal
  1. Change container access level
    • To avoid public exposure, set the container to Private and use SAS for controlled access. In the Azure portal you can also allow anonymous public access (Blob or Container) if that is explicitly required.
A screenshot of the Microsoft Azure portal showing a storage container named "images" with a list of image blobs (City1.jpg, City2.jpg, Colour1.jpg, etc.), sizes, access tiers and other metadata. A notification toast at the top-right says the access level for the container was successfully changed.
  1. Generate a SAS token from the storage account
    • In the Azure portal: Storage account -> Security + networking -> Shared access signature.
    • Select services (e.g., Blob), resource types (service/container/object), and permissions (Read, Write, etc.).
    • Configure start and expiry times, optional allowed IP ranges, and allowed protocols (HTTPS recommended).
    • Choose the signing key (Key1 or Key2) to sign the SAS token. The portal will display the generated SAS token and the full URL(s) for access.
    • For improved security and key-rotation resilience, prefer user-delegated SAS with Azure AD when possible.
  2. Use the SAS URL
    • Append the SAS token to the blob or container URL and access it from a browser or client. The SAS enforces exactly the permissions and constraints you specified.
Operational considerations
  • Key rotation impact: If you regenerate an account access key (Key1 or Key2), any SAS tokens that were signed with that key become invalid.
Regenerating an account key will invalidate SAS tokens signed with that key. User-delegated SAS tokens (issued via Azure AD) are not affected by account key regeneration. Plan key rotation carefully to avoid service interruptions.
  • Security best practices:
    • Use the least privilege: grant only the necessary permissions and the shortest practical time window.
    • Restrict allowed IP ranges when possible.
    • Use HTTPS-only (spr=https) to protect tokens in transit.
    • Prefer user-delegated SAS (Azure AD) for enterprise scenarios and better lifecycle management.
    • Monitor and log SAS usage using Azure Storage analytics and diagnostic logs.
Summary
  • Azure SAS provides flexible, time-bound access to storage without exposing account keys.
  • Choose the SAS type that fits your scenario: Service SAS for resource-level access, Account SAS for cross-service scenarios, or User-delegated SAS for Azure AD-based delegation.
  • Configure permissions, duration, IP ranges, and protocols carefully to minimize risk.
  • Remember: regenerating account keys invalidates SAS tokens signed by those keys; user-delegated SAS follows Azure AD lifecycle rules.
Further reading

Watch Video