Azure Storage has made user-bound user delegation SAS generally available. The feature ties a shared access signature not just to who created it, but to who is allowed to use it. The delegator names a specific Entra ID security principal inside the token, and that principal has to authenticate to Entra ID before the token does anything.
The gap this closes
Regular SAS tokens have always had an awkward property: anyone holding the token can use it, within its time window and permission scope. Leak one into a log file, a client-side bundle, or a chat thread, and whoever finds it has access until expiry. User delegation SAS already improved on account-key SAS by tying token creation to an Entra-authenticated user instead of a storage account key. User-bound SAS closes the remaining hole by tying token use to an identity, not just possession of the string.
Microsoft describes it as an extension of user delegation SAS: the delegator specifies the end user’s Entra identity in the token, the end user authenticates to Entra ID to use it, and that user can sit in the same tenant or a different one. Tokens last at most 7 days and always link back to the delegator’s identity, which is what makes the audit trail meaningful. You can finally answer both who minted this token and who used it.
What setup looks like
The delegator needs the usual RBAC assignments for creating a user delegation key, typically Storage Data Contributor plus the Storage Delegator role. Cross-tenant use requires flipping the allowCrossTenantDelegationSas setting on the storage account, which is the knob to check first if a partner-tenant token mysteriously fails. Beyond that, the creation flow matches the existing user delegation SAS workflow, exposed through REST APIs, SDKs, CLI, and PowerShell, and it needs a GPv2 storage account. Microsoft lists no additional cost for commercial customers.
Where this fits
If you generate SAS tokens for clients today, this changes the calculus on a common pattern: minting long-lived tokens and shipping them out, then hoping the window and scope are narrow enough. With identity binding, a leaked token is inert for anyone who is not the named principal, and the principal’s own Entra authentication becomes an additional control and an audit event. That converts a token from a bearer credential into something closer to a scoped, attributable grant.
There is a tradeoff to plan for. The consuming client now needs line of sight to Entra ID to use the token, so pure anonymous-download scenarios, public blob sharing, or embedded devices without identity keep using classic SAS or other mechanisms. For internal service-to-service and cross-tenant partner flows, though, this is the stricter option worth defaulting to. Given that leaked SAS strings are a recurring incident category, tokens that authenticate their holder before working remove a whole class of them.
Practical guidance
For teams adopting this, a reasonable rollout looks like: inventory where SAS tokens are minted and consumed today, move internal service-to-service delegation first since both ends already have Entra identity, and hold classic SAS only for genuinely anonymous access. Cross-tenant partner integrations are the sweet spot for the new token type, since they combine the audit problem, the leak risk, and the identity availability all at once. Watch the 7-day maximum validity: workloads that previously minted 30 or 90-day tokens will need a refresh mechanism, which is a feature in disguise but still a code change.
It also pairs naturally with the broader shift away from account keys. Account-key SAS inherits the blast radius of the storage account key itself, and every step that moves authorization toward named, authenticated principals shrinks what a leaked credential is worth. User-bound user delegation SAS is the most restrictive point on that spectrum so far, and now that it is generally available rather than in preview, it is a reasonable default for new designs.
How it compares to the alternatives
The token landscape on Azure Storage now spans three levels. Account-key SAS is the legacy option: maximum flexibility, weakest traceability, and a shared secret that everything inherits. User delegation SAS, introduced earlier, scopes token creation to an Entra identity but leaves the issued token usable by whoever carries it. User-bound user delegation SAS adds the final constraint on use. Each step up costs a little flexibility and buys a lot of attribution. The model to keep in mind is OAuth-style audience binding, where a token names its intended consumer and the consumer proves its identity, brought to storage URLs. Anyone who has debugged a leaked-credential incident in a storage account will recognize why that shape is worth the extra authentication hop.