Microsoft announced general availability of user-bound user delegation SAS for Azure Storage on September 9, 2026. The capability restricts a shared access signature to a specified Microsoft Entra ID identity, which must authenticate before using it.
The announcement covers GPv2 storage accounts in all public Azure regions and lists REST APIs, SDKs, PowerShell, CLI, and the portal as access paths. Microsoft states that there is no additional feature charge beyond the applicable storage transaction costs. Read the Azure Storage GA announcement.
We previously covered the public preview. This update focuses on the GA milestone and the checks needed before changing an application's access flow.
The Recipient Must Prove Its Identity
Ordinary user delegation SAS already uses an Entra-backed delegation key. The user-bound extension adds a check on who is presenting the SAS, not just who created it.
The REST reference documents sduoid, the intended recipient's Entra object ID, for authorization version 2025-07-05 or later. The caller must also send a bearer token whose object ID matches that value.
For cross-tenant use, the documented flow also requires the delegated tenant information, including skdutid and the corresponding delegation-key tenant value. The storage account must explicitly permit cross-tenant delegation through allowCrossTenantDelegationSas. User-bound SAS fields and authorization.
Documentation note: the REST reference reviewed on September 10 still labels this section as preview. The newer September 9 Azure Storage announcement explicitly announces GA. Use the announcement for release status and verify the current client documentation before implementation.
A Shared Link Is No Longer the Complete Client Flow
My implementation recommendation is to inspect the consuming application before changing the token issuer. A client designed only to receive a URL now needs a supported way to acquire and present the recipient's Entra token as well.
Consider an illustrative document-download application. The backend authorizes a user to retrieve one document, then issues a short-lived, identity-bound SAS for that document. The client makes the storage request with both the SAS and the matching identity token.
The application should distinguish “not signed in,” “signed in as the wrong identity,” and “access expired.” A generic download error gives the help desk little evidence and can encourage unsafe workarounds.
This is an example design, not a tested reference deployment. Validate the exact client, token audience, and storage operation you intend to support.
Start With Same-Tenant Access
For an initial pilot, my recommendation is to use two controlled test identities in the same tenant and a non-sensitive object. Prove the intended positive and negative cases before introducing cross-tenant onboarding.
Keep cross-tenant enablement as a deliberate account-level decision. If the application does not need it, leave it disabled.
For a future partner scenario, document which identity and tenant the application expects before creating the SAS. Do not use an email address alone as the authorization contract. Have the identity owner confirm the identifiers and the intended access scope.
A successful test with an internal account does not establish that a guest or partner application will follow the same authentication path.
Test the Denials, Not Only the Download
A useful original acceptance set would include:
The intended recipient, using a valid SAS and valid identity token.
The same SAS without a bearer token.
The same SAS presented by the second test identity.
An expired SAS paired with an otherwise valid identity token.
A read-only SAS used for an attempted write.
A request for an object outside the approved SAS scope.
A client refresh or sign-out while a transfer is being prepared.
Only the intended, authorized operations should succeed. Record which failure the application shows and what an operator can diagnose without seeing credentials.
Use synthetic data for these checks. There is no need to expose a real customer document to demonstrate that identity matching works.
Existing SAS Hygiene Still Matters
Identity binding does not make a SAS safe to paste into a ticket or leave in telemetry. Microsoft's SAS overview continues to recommend HTTPS, narrowly scoped permissions, and a revocation plan. It also notes that user delegation SAS does not support stored access policies. SAS security and operational guidance.
My recommendation is to log the business request identifier, intended recipient reference, resource scope, and outcome while redacting SAS query strings and bearer tokens. Treat authentication failure and issuer failure as separate conditions in the application's support playbook.
Also decide what happens when access legitimately expires halfway through a user workflow. A clear renewal path is preferable to silently replacing a constrained token with a broader one.
Practical Cloud Engineer Takeaway
Inventory one existing SAS-based integration and identify its issuer, recipient, client library, expiry behavior, and recovery owner. Then pilot identity-bound access without changing the permitted resource scope or adding unrelated privileges.
Roll out only after the intended identity succeeds, other identities fail, and the application can explain those outcomes clearly. Keep the earlier integration definition available for comparison, but do not make unrestricted access an automatic fallback.
Who Should Care?
Azure Storage owners, application security teams, and developers distributing temporary access to authenticated users or partner applications.
Bottom Line
The GA milestone adds a useful recipient check to delegated storage access. Its value comes from a complete identity-aware client flow, least-privilege scope, and verified failure handling.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments