A user delegation SAS is a temporary access link for Blob Storage that is backed by Microsoft Entra authentication rather than the storage account key. Someone with the right data-plane role asks Azure for a user delegation key, then creates a SAS with specific permissions and expiry. The result can let another process read or write selected blobs for a short time without sharing permanent credentials or account-wide secrets. Treat the generated URL as a secret until it expires.
Entra-backed SAS, Azure AD SAS, user delegation shared access signature, delegation SAS
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-28
Microsoft Learn
A user delegation SAS is a shared access signature for Azure Blob Storage that is secured with Microsoft Entra credentials instead of the storage account key. It grants limited, time-bound access to blob or container resources using a user delegation key.
In Azure architecture, user delegation SAS sits in the Blob Storage data plane. It depends on Microsoft Entra authentication, Storage Blob data roles, the Get User Delegation Key operation, and SAS parameters such as permissions, start time, expiry, protocol, IP range, container, and blob name. It applies to blob and Data Lake Storage Gen2 blob endpoints, not every storage service. Operators often use it with private endpoints, managed identities, applications, and short-lived export workflows. and audits.
Why it matters
User delegation SAS matters because account-key SAS tokens are powerful and hard to govern. If an account key leaks, every token signed with it becomes suspect and key rotation can break many workloads. A user delegation SAS ties token creation to Microsoft Entra identity and RBAC, giving organizations a better audit and least-privilege story. It is especially useful when external systems need temporary blob access but should never receive storage account keys. The term also teaches a broader lesson: temporary access should be scoped, attributable, short-lived, and easy to revoke from the issuing workflow. That reduces key sprawl and breach impact.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
Azure CLI generate-sas output returns a token containing permissions, start and expiry times, resource scope, and signature fields for the target blob. during controlled sharing
Signal 02
Storage diagnostic logs show SAS-authenticated blob requests, including operation names, authorization failures, client IPs, request IDs, and timestamps for investigations. during post-incident access review evidence
Signal 03
Application code or automation retrieves a user delegation key with Entra credentials, signs a short-lived SAS, and returns a temporary URL for clients. during transfer
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Share one blob or container with a partner for hours without exposing storage account keys.
Generate short-lived upload URLs for browser or mobile clients that cannot hold permanent credentials.
Replace legacy account-key SAS automation with Microsoft Entra-backed issuance and clearer RBAC ownership.
Constrain a data export to read-only access, HTTPS, a tight expiry, and optional client IP restrictions.
Investigate leaked access links by separating user delegation SAS issuance from account-key SAS usage patterns.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Film studio shares dailies without account keys
Film studio shares dailies without account keys: User delegation SAS gives creative workflows temporary access without turning storage account keys into shared secrets. with safer evidence and no emergency account-key rotation
📌Scenario
A film post-production studio needed to share large daily footage files with external color specialists. The old process used long-lived account-key SAS links copied into email threads.
🎯Business/Technical Objectives
Stop exposing storage account keys through sharing workflows.
Limit partner access to specific containers and short review windows.
Reduce failed downloads caused by unclear token settings.
Improve audit evidence for content security reviews.
✅Solution Using User delegation SAS
The platform team moved sharing automation to user delegation SAS. A managed operations group received Storage Blob data roles to issue tokens, and the script generated read-only SAS URLs with HTTPS-only protocol, six-hour expiry, and optional IP restrictions for partner offices. Each token was created for the specific footage path, then placed in a secure portal rather than email. Storage logs were retained for the review window and correlated with the production schedule. The portal displayed expiry and download status to coordinators. Reviewers also tested link expiry and revocation during the launch rehearsal.
📈Results & Business Impact
Long-lived account-key SAS links were eliminated from the footage sharing process within one month.
Partner download failures fell by 47 percent because expiry, permissions, and paths were standardized.
Security review time for a new partner dropped from two days to four hours using issuance and access logs.
💡Key Takeaway for Glossary Readers
User delegation SAS gives creative workflows temporary access without turning storage account keys into shared secrets. with safer evidence and no emergency account-key rotation during audits without key exposure
Case study 02
Insurance claims app accepts secure photo uploads
Insurance claims app accepts secure photo uploads: User delegation SAS is a strong fit when untrusted clients need narrow, temporary Blob Storage access.
📌Scenario
An insurance carrier needed customers to upload accident photos from mobile devices. The application team wanted direct blob uploads but could not place storage account keys in the mobile app.
🎯Business/Technical Objectives
Enable customer uploads without permanent credentials on devices.
Restrict each upload token to one claim path and short lifetime.
Reduce backend load caused by proxying every image through the API.
Keep failed upload troubleshooting visible to support teams.
✅Solution Using User delegation SAS
The claims API authenticated the customer, validated the claim, then used its Azure-hosted identity to request a user delegation SAS for a single blob prefix. The generated token allowed create and write operations only, used HTTPS, and expired after fifteen minutes. The mobile app uploaded directly to Blob Storage, while metadata returned to the claims API. Storage diagnostics and application logs shared a claim correlation ID, so support could tell whether failures were authentication, expiry, network, or blob permission issues.
📈Results & Business Impact
Average image upload time dropped by 55 percent because files no longer passed through the claims API.
No storage account keys were embedded in mobile builds or customer-facing configuration.
Support resolved upload complaints 40 percent faster using correlated SAS issuance and blob request logs.
💡Key Takeaway for Glossary Readers
User delegation SAS is a strong fit when untrusted clients need narrow, temporary Blob Storage access.
Case study 03
Energy analytics exports expire automatically
Energy analytics exports expire automatically: User delegation SAS lets scheduled data exchanges be temporary, attributable, and safer than account-key sharing. reliably
📌Scenario
An energy analytics team exported meter data to a market regulator every night. The previous export account used account-key SAS tokens that remained valid long after each delivery window closed. for compliance
🎯Business/Technical Objectives
Provide read-only access to nightly export files for a fixed window.
Tie token issuance to Microsoft Entra roles instead of account keys.
Detect unusual download volume after the regulator retrieves data.
Reduce manual key rotation after staff changes.
✅Solution Using User delegation SAS
Engineers replaced the export process with a user delegation SAS generated by a controlled automation identity. The token covered only the export container path for that night, allowed read and list permissions, required HTTPS, and expired after twelve hours. The storage account used lifecycle rules for export retention, and diagnostic logs fed an alert if downloads exceeded expected file counts. Account keys were no longer distributed to the data exchange team, reducing the number of emergency rotations after personnel changes.
📈Results & Business Impact
Account-key rotation events tied to export sharing dropped from five per year to zero.
Unexpected post-window access attempts failed automatically after token expiry.
The regulator’s delivery success rate stayed above 99.5 percent while access exposure shrank to a nightly window.
💡Key Takeaway for Glossary Readers
User delegation SAS lets scheduled data exchanges be temporary, attributable, and safer than account-key sharing. reliably safely safely
Why use Azure CLI for this?
Azure CLI is very useful for user delegation SAS because token creation is parameter-heavy and easy to get wrong in a portal workflow or copied code snippet. As an Azure engineer, I use CLI to confirm the signed-in identity, verify data-plane RBAC, generate a short-lived SAS with --as-user, and test exact blob access before handing the URL to another system. CLI also makes expiries, permissions, IP restrictions, and HTTPS-only settings visible in scripts and change records. That repeatability matters when links are created under pressure. It also lets teams record nonsecret parameters while redacting the generated token for audits later safely.
CLI use cases
Generate a short-lived read SAS for a specific blob after confirming Microsoft Entra data-plane access.
Create a container-level listing and read SAS for a controlled partner import window.
Verify the blob exists and the issuing identity has the correct Storage Blob data role.
Audit whether automation still depends on account keys before migrating to user delegation SAS.
Before you run CLI
Confirm tenant, subscription, storage account, container, blob name, and signed-in identity before generating a bearer token.
Use UTC expiry times, allow for clock skew, and keep lifetime only as long as the transfer or workflow needs.
Verify Storage Blob data roles; management-plane contributor access alone may not allow user delegation key creation.
Avoid printing full SAS URLs in shared terminals, logs, tickets, screenshots, or pipeline output.
What output tells you
The SAS token encodes signed permissions, expiry, resource scope, protocol, optional IP range, and cryptographic signature.
A successful generate-sas command proves the identity can request a user delegation key for the targeted account.
Blob show output confirms the object path and properties before a token is issued for the wrong resource.
Role assignment output shows whether access is data-plane capable or only management-plane administration.
Mapped Azure CLI commands
User delegation SAS CLI commands
direct
az storage blob generate-sas --account-name <storage-account> --container-name <container> --name <blob-name> --permissions r --expiry <utc-expiry> --auth-mode login --as-user
az storage blob show --account-name <storage-account> --container-name <container> --name <blob-name> --auth-mode login
az storage blobdiscoverStorage
az role assignment list --assignee <principal-id> --scope <storage-account-scope> --output table
az role assignmentdiscoverStorage
az storage account show --name <storage-account> --resource-group <resource-group>
az storage accountdiscoverStorage
Architecture context
Architecturally, user delegation SAS is a controlled exception path for temporary Blob Storage access. The preferred internal pattern is usually managed identity or direct Microsoft Entra authorization. When a partner, browser upload, tool, or batch process needs a scoped URL, user delegation SAS is safer than account-key SAS because issuance depends on RBAC and tenant identity. A mature design uses short expiries, narrow permissions, HTTPS, optional IP restrictions, private connectivity where possible, logging, and automation that never stores generated tokens in source control. Treat the issuing component as a privileged data export service with approval, monitoring, and revocation procedures. Document ownership.
Security
Security impact is direct. A user delegation SAS is still a bearer token: anyone who has it can use the permissions until it expires or the backing conditions fail. The security improvement is that token issuance uses Microsoft Entra credentials and can avoid exposing storage account keys. Assign only required Storage Blob data roles, use minimal permissions, short expiry, HTTPS-only protocol, narrow resource scope, and IP restrictions where appropriate. Never log full SAS URLs, place them in tickets, or commit them to repositories. Treat token brokers and SAS generation rights like privileged data export permissions. Review token brokers like privileged systems.
Cost
User delegation SAS has no separate charge, but it drives cost through the storage operations and data movement it enables. A broad read SAS can allow unexpected egress, repeated downloads, or partner jobs that scan entire containers. Write SAS tokens can create storage growth if clients upload duplicates or fail cleanup. Logging and analytics used to monitor SAS access also cost money. FinOps controls should pair SAS policy with lifecycle rules, egress awareness, token-expiry standards, and alerts for unusual request volume. Review egress and transaction patterns after every sharing rollout or partner onboarding cycle. Alert on unusual downloads before invoices spike.
Reliability
Reliability depends on expiry design, clock handling, permissions, and network reachability. A token that expires too soon can break a long transfer, while a token that starts in the future may fail because of clock skew. A token with read permission cannot support a write workflow, and private endpoint or firewall rules may still block access. Reliable designs generate SAS tokens just in time, size expiry to the job, retry transient storage failures, and provide a refresh path without falling back to account keys. Test long transfers and renewal behavior before partners depend on the link. Document renewal paths before launch.
Performance
Performance is mostly shaped by the storage account, network path, client concurrency, and SAS scope rather than by the token itself. However, bad SAS parameters can slow work: narrow expiries force restarts, missing permissions cause retries, and overly broad scopes encourage inefficient listing or scanning. Private endpoints, firewall rules, client location, blob tier, and parallel transfer settings still matter. Operators should test throughput with the generated SAS, monitor server latency and throttling, and avoid treating authentication success as performance validation. Match expiry windows to realistic transfer duration and retry behavior. Test large transfers with realistic client locations and retry settings first.
Operations
Operators generate, validate, and investigate SAS usage. They confirm the caller has Storage Blob data permissions, create scoped tokens, test access with the exact client, and review storage logs for requests using SAS authentication. During incidents, they search for exposed URLs, shorten issuance patterns, rotate account keys if account-key SAS was also used, and update automation to prefer --as-user. Documentation should record who can issue tokens, maximum expiry, allowed permissions, and where generated links may be stored. Keep examples sanitized so support can troubleshoot without leaking credentials. Standard forms should capture recipient, purpose, expiry, approval, and validation evidence before generation.
Common mistakes
Using account-key SAS out of habit even when Microsoft Entra-backed user delegation SAS is available.
Granting write, delete, or list permission when the recipient only needs to read one blob.
Setting expiry too long because no one wants to handle token refresh for a predictable transfer window.
Sharing full SAS URLs in email threads, logs, issue trackers, or documentation that many people can read later.