Microsoft’s public preview of
user‑bound user delegation SAS marks a pragmatic, identity‑centric tightening of Azure Storage access controls: SAS tokens can now be created so that they are only usable by a specific Microsoft Entra ID (Azure AD) principal, improving traceability, reducing accidental or malicious token use, and preserving the flexibility of delegated, time‑limited access.
Background
Azure Storage has offered Shared Access Signatures (SAS) for years as a way to grant scoped, time‑limited access to objects without sharing account keys. Traditional account SAS and service SAS are signed with storage account keys, which are powerful and hard to revoke quickly. Microsoft introduced
user delegation SAS (UD SAS) to move SAS signing to Microsoft Entra ID credentials, enabling SAS tokens that are tied to the identity that requested the delegation key rather than an account key. This reduces the blast radius of leaked keys and aligns SAS issuance with identity‑based authorization.
The new
user‑bound extension takes that model one step further: when creating a UD SAS token, the delegator now can (optionally) specify the Entra ID object ID (and tenant) of the
end user who is permitted to
use the SAS token. The resulting SAS is valid only if the presenting client authenticates to Entra and its token matches the bound identity, or — in cross‑tenant scenarios — its tid claim matches the tenant specified. Microsoft has published this capability as a public preview across all public regions and via the REST APIs, SDKs, CLI, and PowerShell. There is no additional cost beyond normal storage transactions.
What user‑bound user delegation SAS is — a concise technical summary
- A user delegation SAS (UD SAS) is a SAS signed with a user delegation key that Azure Storage issues after an Entra ID principal requests it using an OAuth token. The UD SAS is therefore rooted in Azure AD identity rather than an account key.
- User‑bound UD SAS is an extension that allows the delegator to embed the authorized end user’s object ID (saoid/suoid) and tenant ID in the SAS such that Storage will require the caller to authenticate to Entra ID and show the matching identity to use the SAS. This validates the use of the SAS to a specific principal — not just its creation by a delegator.
- UD SAS keys and SAS tokens remain short lived: the user delegation key can be requested for up to 7 days, and SAS lifetimes cannot exceed the key lifetime. This enforced maximum narrows the window for token misuse.
Why this matters: security and operational gains
Stronger traceability and accountability
User‑bound UD SAS ties both the creation and the usage of a token to Entra identities: the delegator’s identity issues the token, and the end‑user identity must authenticate to present it. That two‑fold association makes it significantly easier to attribute actions in audit logs and to follow an access trail back to both delegator and end user. This combination reduces the
anonymous bearer nature of traditional SAS tokens where possession alone grants access.
Reduced lateral misuse and accidental exposure
Because the SAS will only work for the specified Entra principal, tokens that are accidentally leaked or mistakenly shared with a different application or user will fail authorization. In multi‑tenant or machine‑user delegation scenarios, this reduces the risk of tokens being reused by unauthorized principals. Microsoft explicitly designs the feature to minimize unintended access while preserving SAS flexibility.
Operational simplicity and no direct pricing change
Microsoft states there is no additional fee for user‑bound UD SAS; customers are charged only standard storage transaction costs. Availability is broad — the preview is supported in all public regions for GPv2 storage accounts and surfaced across REST SDKs, CLI, and PowerShell — enabling existing automation to adopt the new parameters with modest changes.
Technical deep dive: how it works, field by field
User delegation key + SAS signing model
- A principal who has the right RBAC role requests a user delegation key from Azure Storage by presenting an OAuth2 bearer token to the Get User Delegation Key operation. Azure Storage validates the request and returns the delegation key.
- The delegator then constructs a SAS token and signs it with the user delegation key. When creating a user‑bound UD SAS, additional SAS fields specify the allowed end‑user identity (for example, the
saoid/suoid and skdti/sktid parameters in SAS semantics). Azure Storage enforces that the presenting caller authenticate to Entra and match the specified identity/tenant to succeed.
Key fields to understand
- skoid / sktid — the object ID and tenant ID of the delegator (captured when requesting the user delegation key). These are standard UD SAS fields.
- saoid / suoid — optional signed authorized or unauthorized object IDs carried in SAS tokens to specify the end user that is allowed to use the SAS (used for user‑bound scenarios and Hadoop/ADLS integrations). When present, Storage will validate that the user presenting the SAS is the specified Entra principal.
- skdutid / skduti (tenant scoping) — when delegating across tenants, additional tenant fields and checks ensure the presenting token’s tid claim matches the tenant specified in the SAS. Admins must enable the cross‑tenant delegation setting on the storage account for cross‑tenant flows to work.
RBAC, prerequisites, and account settings
Required roles for the delegator
To request a user delegation key, the
delegator must have an RBAC role that includes the GenerateUserDelegationKey action for the target service. Microsoft lists built‑in roles such as:
- Storage Blob Data Contributor and Storage Blob Delegator (or service‑specific equivalents) for Blob service UD SAS.
- Similarly named roles exist for Table, Files, and Queue services: Storage Table Data Contributor / Storage Table Delegator, Storage Files Data Contributor / Storage Files Delegator, Storage Queue Data Contributor / Storage Queue Delegator.
The Storage Delegator roles allow a principal to request the delegation key even when data‑reader roles are scoped at a different level (for example container vs. account). This flexibility matters for least‑privilege RBAC design.
Account type and settings
- GPv2 requirement: User‑bound UD SAS requires a GPv2 storage account. Microsoft explicitly notes that the preview is available on GPv2 accounts in public regions.
- Cross‑tenant delegation: If the SAS’s bound end user is in a different tenant from the storage account, the storage account’s allowCrossTenantDelegationSas setting must be enabled by an administrator. If cross‑tenant use is not required, administrators can keep that flag disabled to reduce exposure.
Deployment scenarios and real‑world use cases
1) Application‑to‑user delegation in multi‑tenant SaaS
A SaaS app in Tenant A wants to let its customers’ users (Tenant B) upload files directly to the SaaS vendor’s storage account while preserving traceability to the individual user. With
user‑bound UD SAS, the SaaS can have a delegator principal create a SAS that is bound to the customer’s user object ID and tenant. The customer user authenticates to Entra and can only use that SAS. Administrators must enable cross‑tenant delegation on the storage account to allow Tenant B identities to be accepted.
2) Multi‑user HPC / analytics clusters
For multi‑user Hadoop/Spark workloads on ADLS Gen2, user‑bound parameters (saoid/suoid) were already useful to integrate with POSIX ACLs and tools like Apache Ranger. The user‑bound UD SAS formalizes that approach for a broader set of workloads, narrowing access per job and attributing file operations to a given end user.
3) Short‑lived third‑party integrations
When an external vendor needs limited, auditable access to a scoped set of blobs, a delegator can mint a SAS that is both time‑bounded and identity‑bound. If the vendor’s identity is compromised elsewhere, the token cannot be used unless the attacker can authenticate as that same Entra principal to the tenant/tenant ID specified.
Implementation checklist — step by step
- Verify the storage account is GPv2 and in a public region.
- Ensure the delegator principal has appropriate RBAC: Storage <Service> Delegator and Storage <Service> Data Contributor (or equivalent). Assign at the right scope to minimize privilege.
- For cross‑tenant scenarios, enable allowCrossTenantDelegationSas on the storage account. If you don’t need cross‑tenant delegation, leave it off.
- Get the delegator’s OAuth token and call Get User Delegation Key for the desired duration (≤ 7 days).
- Collect the target end user’s object ID (OID) and tenant ID (tid) and include them in the SAS construction (saoid/suoid, skduti/skdutid fields as applicable).
- Share the resulting SAS with the intended application or user; prefer secure channels such as Key Vault references or automated app token flows rather than emailing tokens.
Operational guidance: logging, revocation, and monitoring
- Audit logs and diagnostics: Because requests are authorized with Entra credentials, Storage diagnostic logs will include information correlated to Entra principals; include these logs in your SIEM to map SAS usage to identities for incident response and analytics. Microsoft’s UD SAS model improves the fidelity of those logs compared to account key‑based SAS.
- Revocation: Administrators can quickly revoke access by revoking the user delegation key, or by changing RBAC assignments for the delegator. Note that Azure Storage caches delegation keys and RBAC assignments, so propagation to invalidate existing tokens may not be instantaneous; plan for a short delay when revoking.
- Least privilege and short lifetimes: Follow the principle of least privilege when assigning the delegator roles and keep both the user delegation key and resulting SAS expiry short (the platform limits keys to a maximum of 7 days). Shorter lifetimes reduce the risk window for leaked tokens.
Strengths, realistic limitations, and risks
Strengths
- Identity‑anchored usage: Binding SAS usage to a specific Entra principal closes a common gap in SAS security where mere possession equals access. This significantly mitigates unauthorized token reuse.
- Better auditability: Linking both the delegator and end user into the token flow improves forensic trails for compliance and incident investigations.
- No additional transaction pricing: The preview is available without a new pricing tier, lowering the friction to test and adopt.
Limitations and practical risks
- Operational complexity with cross‑tenant flows: Cross‑tenant scenarios require the allowCrossTenantDelegationSas flag and careful tenant/claim validation. Misconfiguration may either prevent legitimate access or inadvertently widen access if account settings are incorrectly enabled. Administrators must treat that flag as a sensitive control.
- RBAC mistakes can undermine protections: The feature relies on correct RBAC assignments for the delegator. Overbroad role assignment (e.g., giving a large group the Delegator role at subscription scope) could enable many principals to mint user‑bound tokens; enforce strict role scoping and use separation of duties.
- Caching and revocation delays: Because user delegation keys and RBAC are cached by Azure Storage, revocation isn’t always instantaneous. For high‑assurance needs, combine short SAS lifetimes with active monitoring and a revocation playbook.
- Not a panacea for compromised credentials: If an attacker has full control of the bound Entra principal (for example through compromised credentials and session tokens), user‑bound SAS offers no extra protection for that principal. Organizations must maintain strong identity hygiene and enforce MFA, conditional access, and privileged access controls.
Practical recommendations and best practices
- Favor UD SAS and user‑bound UD SAS over account keys: Make UD SAS the default for delegation scenarios; reserve account keys for truly privileged operational needs. This aligns with Microsoft’s recommendations.
- Minimize scope of Delegator roles: Assign Storage Delegator roles at the smallest scope necessary (container or resource group) and favor service‑specific delegator roles rather than broad subscription or tenant‑wide assignments. Use custom roles only when you need narrower privileges.
- Implement short durations and automated renewal: Keep delegation keys and SAS tokens short (hours to days), automate generation/renewal via managed identities, and store tokens or SAS URIs in secure services like Key Vault rather than distribution via email or logs that may be broadly accessible.
- Lock down cross‑tenant delegation: Only enable allowCrossTenantDelegationSas when your architecture requires it. Treat that setting as a high‑risk toggle and document the business justification, owners, and periodic reviews.
- Monitor usage and anomaly detection: Feed storage and sign‑in logs into a SIEM and look for unusual SAS usage patterns: repeated failed auths for a bound OID, SAS use from unexpected IP ranges, or SAS use outside expected hours. Combining identity logs and storage diagnostics provides richer detection.
Comparison: user‑bound UD SAS versus alternatives
- Account SAS / Service SAS: Signed with account keys — high risk if keys are exposed; no identity requirement to use the token. User‑bound UD SAS is strictly superior in traceability and limiting usage to a specific Entra principal.
- Standard UD SAS (non‑bound): Signed by a user delegation key and traceable to the delegator, but any client holding the token can use it (bearer semantics). User‑bound UD SAS removes bearer‑style risk by constraining use to an end user identity.
- Managed identities + direct API access: For server‑to‑server scenarios, direct use of managed identities and role‑based access to Storage offers a stronger model because it avoids token dissemination entirely. Use user‑bound UD SAS when the architecture requires client possession of a URI (for example direct browser uploads or third‑party integrations).
A short cautionary note for security practitioners
This preview is an important incremental control but it is not a silver bullet. User‑bound UD SAS reduces many common risks associated with SAS misuse, but it still depends on sound identity protections, proper RBAC scoping, and secure operational practices. Treat it as a layer — one more tool in defense‑in‑depth — rather than an automatic replacement for strong identity governance and access management practices.
Closing analysis — what to do next
For cloud and storage teams responsible for data security, the release of user‑bound user delegation SAS is timely and practical. It answers a common operational pain point: the need to distribute short‑lived storage access while also making that access accountable to a named identity. The recommended immediate actions are:
- Evaluate whether your workloads already use UD SAS or account keys and map candidate flows that would benefit from binding SAS usage to an identity.
- Pilot the preview on a GPv2 test account, exercising same‑tenant and cross‑tenant flows, while validating RBAC scoping and enabling the allowCrossTenantDelegationSas flag only when needed.
- Update automation and token distribution patterns to use secure stores (Key Vault) and managed identity flows for renewal; avoid manual token sharing.
- Integrate audit logs into your SIEM and create alerts for anomalous SAS usage patterns and failed identity validations.
User‑bound UD SAS closes a practical gap between the convenience of SAS tokens and modern identity‑based security expectations. When combined with scoped RBAC, short lifetimes, and strong identity hygiene (MFA, conditional access, and privileged access reviews), it provides a tangible uplift in storage security posture that organizations should evaluate and adopt where appropriate.
Conclusion: user‑bound user delegation SAS is a welcome, pragmatic enhancement to Azure Storage security — not transformative by itself, but highly effective when used as part of an identity‑first, least‑privilege operational model.
Source: Petri IT Knowledgebase
User‑Bound User Delegation SAS Restricts Azure Storage Tokens to Entra ID Identities