Microsoft extends user delegation SAS tokens beyond blobs to Azure Tables, Files, and Queues, enabling finer-grained access control tied to Entra ID identities without additional costs.
Microsoft has significantly expanded the security capabilities of its Azure Storage platform by bringing user delegation shared access signatures (SAS) to Azure Tables, Azure Files, and Azure Queues. Previously exclusive to Azure Blobs, this public preview extension represents a strategic shift toward identity-based access control across Microsoft's entire storage ecosystem. For enterprises navigating multi-cloud environments, this update warrants attention due to its implications for least-privilege security models and delegated access workflows.
The Shift Toward Identity-Centric Security
Traditional SAS tokens (account SAS or service SAS) derive permissions from storage account keys—high-privilege credentials that pose significant security risks if compromised. User delegation SAS (UD SAS) fundamentally changes this model by binding token permissions to an Entra ID (formerly Azure AD) identity. When a user or service principal requests a UD SAS token, Azure first validates their identity via Entra ID and checks their Azure RBAC permissions. Only then does it issue a time-limited delegation key, which the requester uses to generate SAS tokens granting subsets of their own permissions. This process eliminates exposure of account keys while enabling granular, auditable delegation.
Cross-Provider Security Comparisons
When evaluating cloud storage security, Azure's UD SAS approach diverges notably from AWS and GCP:
- AWS S3 Pre-Signed URLs: While functionally similar to SAS tokens, AWS pre-signed URLs rely on AWS Signature Version 4 and IAM credentials. Crucially, AWS lacks equivalent identity-binding for services like SQS (Simple Queue Service) or DynamoDB, where resource access typically requires persistent IAM roles or access keys.
- GCP Signed URLs: Google Cloud's signed URLs for Cloud Storage provide temporary access but operate independently of IAM. Granular delegation requires complex IAM condition bindings or service account impersonation, lacking Azure's direct token-to-identity binding across multiple service types. Azure's uniform UD SAS implementation across Tables, Files, Queues, and Blobs provides consistency unavailable in competing platforms, particularly for scenarios requiring delegated access to non-blob storage.
Business Impact and Migration Considerations
Security Posture Enhancement: By tying tokens to identities, organizations reduce blast radius from compromised credentials. Each UD SAS token's permissions are constrained by the creator's RBAC assignments—a critical improvement over account SAS tokens, which grant broad, key-based access.
Operational Granularity: Teams can now delegate precise actions—such as reading specific queue messages or modifying individual table entities—without provisioning new service principals or managing secondary credentials. This enables scenarios like allowing a frontend application to write directly to a storage queue using tokens scoped solely to queue/message/add permissions.
Cost and Adoption: With no additional pricing beyond standard transaction costs, adoption becomes a security upgrade rather than a budget decision. Migration requires:
- Assigning RBAC roles like Storage Table Data Contributor and Storage Table Delegator (role names vary by service)
- Replacing legacy SAS generation logic with UD SAS flows using delegation keys and token construction
Current Limitations: Note that SDK/CLI support during preview is limited to REST APIs for Tables, requiring interim REST integration for non-Blob services. Full SDK parity is expected post-GA.
Strategic Implications
This extension completes Azure's vision for unified identity-based storage access. For enterprises standardizing on Entra ID, UD SAS enables secure delegation patterns where lower-privileged services or users generate time-bound access tokens—aligning with zero-trust principles. When architecting multi-cloud solutions, this capability differentiates Azure for workflows requiring granular, identity-bound resource delegation across diverse storage services.

Comments
Please log in or register to join the discussion