Azure Storage Adds Secure User-Bound User Delegation SAS to Lock Tokens to a Single Entra ID Identity

Azure Storage is tightening the screws on how shared access signatures (SAS) can be used, giving cloud teams a new way to make sure powerful tokens do not fall into the wrong hands. With a new public preview announced on the Azure Storage Blog, Microsoft is introducing user-bound user delegation SAS, a feature that lets you bind a SAS token to a single Microsoft Entra ID identity so only that user can use it. For customers that rely heavily on SAS for delegated access, this is a significant security upgrade that keeps the flexibility of SAS while sharply reducing the blast radius of leaked tokens.

In the post, Microsoft explains that this new capability builds on the existing user delegation (UD) SAS model, which already moved SAS away from account keys and onto Entra ID and Azure role-based access control (RBAC). The new user‑bound flavor goes further by making sure that even if a SAS URL is copied or leaked, it cannot be used unless the caller is authenticated as the specific Entra ID identity that the delegator named when creating the token. That means fewer shared secrets floating around and a much stronger tie between storage access and user identity.

The announcement comes in the Azure Storage Blog article “Public Preview: Restrict usage of user delegation SAS to an Entra ID identity,” which lays out how user‑bound UD SAS works, what it costs, and how to get started across REST APIs, SDKs, PowerShell, and the Azure CLI. For organizations already standardizing on Entra ID for data plane access, this is a natural next step toward more granular and auditable storage security.

---

From account keys to Entra ID to user-bound SAS

Historically, many Azure Storage deployments relied on account keys or service-level SAS tokens signed with those keys, which meant a single leaked secret could expose large chunks of a storage account. To address that, Microsoft introduced user delegation SAS, allowing clients to request a user delegation key tied to an Entra ID identity and use it to sign SAS tokens that represent a subset of that user’s access rights.

Key traits of classic UD SAS:

• Signed using a user delegation key obtained via Entra ID, not the storage account key.

• Grants a subset of the delegator’s permissions and can be traced back to that delegator.

• Can only be valid for up to 7 days, which naturally limits exposure if a token leaks.

User-bound user delegation SAS builds on this by adding an explicit end-user identity into the token. When the SAS is used, Azure Storage checks that the caller has authenticated to Entra ID as that exact identity (or a matching security principal), and only then honors the token. If someone else grabs that URL, they cannot use it, because they can’t satisfy the Entra ID identity requirement.

---

How user-bound user delegation SAS works

With user-bound UD SAS, the flow looks like this:

1. A delegator (for example, a service or admin) retrieves a user delegation key tied to their Entra ID account.

2. When constructing the SAS, the delegator specifies the Entra ID security principal (object ID) of the intended end user in the SAS parameters.

3. The end user must authenticate to Entra ID to use the SAS.

4. Azure Storage validates both the SAS signature and that the caller’s identity matches the bound security principal before granting access.

The end user can live in the same tenant or a different tenant as the delegator. For cross‑tenant scenarios—say, a partner or customer accessing your blobs—you must enable the allowCrossTenantDelegationSas setting on the storage account; if you are not doing cross‑tenant delegation, you can leave that setting disabled.

Under the hood, this builds on existing parameters like signedAuthorizedObjectId and signedTenantId in the user delegation SAS model, which allow you to lock SAS usage to a specific Entra security principal and tenant. The new preview turns this into a more formal, supported pattern across all GPv2 storage accounts in public regions, not just blob workloads.

---

Pricing, regions, and tooling support

From a cost perspective, Microsoft is keeping things simple: there is no extra charge for user‑bound user delegation SAS. You pay the usual read/write transaction costs associated with your storage account type, the same as you would for other SAS‑based access.

On day one of the public preview, Microsoft says the feature is:

• Available for all GPv2 storage accounts in all public regions.

• Exposed via:

  • REST APIs for storage services

  • Official SDKs (with updated samples and helpers)

  • Azure PowerShell cmdlets

  • Azure CLI commands

That means dev teams can start experimenting without waiting for portal blades or UI updates, wiring user‑bound UD SAS into existing automation scripts, microservices, or data pipelines.

---

How to get started with user-bound UD SAS

The Azure Storage Blog outlines a straightforward getting-started path for teams that want to try user‑bound UD SAS in preview.

1. Check your account type

   • Make sure you are using a GPv2 storage account in a public region, which is required for this preview.

2. Decide on cross‑tenant usage

   • If the end user of the SAS token is in a different tenant, enable the allowCrossTenantDelegationSas setting on the storage account.

   • If you are only delegating within the same tenant, you can leave this setting disabled.

3. Assign the right RBAC roles to the delegator
   The identity that requests the user delegation key needs appropriate data-plane RBAC roles that match the storage service you are using:

   Service	Data Contributor role	Delegator role
   Azure Blob	Storage Blob Data Contributor	Storage Blob Delegator
   Azure Table	Storage Table Data Contributor	Storage Table Delegator
   Azure Files	Storage Files Data Contributor	Storage Files Delegator
   Azure Queue	Storage Queue Data Contributor	Storage Queue Delegator

   These roles let the delegator both access data and request the user delegation key needed to sign SAS tokens.

4. Request a user delegation key

   • Use the Get User Delegation Key operation as documented in the “Create a user delegation SAS” article.

   • This returns a time‑bound key (up to 7 days) that you will use to sign your user‑bound SAS tokens.

5. Collect the end user’s object ID and tenant ID

   • Ask your end user to provide their Entra ID object ID and tenant ID.

   • Microsoft’s documentation shows how users can find these values in the Azure portal or Partner Center account settings.

6. Construct the user-bound UD SAS token

   • Follow the standard user delegation SAS construction steps, but include the end user’s object ID and tenant ID in the appropriate fields.

   • The steps are effectively the same as a normal UD SAS; you are just binding the token to a specific end user identity.

7. Distribute the SAS securely

   • Share the SAS token only with the intended application or user.

   • Microsoft recommends passing tokens within applications programmatically and, where possible, storing them in Azure Key Vault instead of hard‑coding them or sending them over email.

Once this is in place, any attempt to use the SAS will require the caller to authenticate as the specified Entra ID security principal, reducing the risk that the URL alone can be misused.

---

Why this matters for Azure security teams

For security-conscious organizations, user‑bound user delegation SAS addresses one of the long‑standing concerns with SAS: the fact that a token, once created, acts as a bearer credential that anyone can use if they obtain it. By tying SAS usage directly to an Entra ID identity, Microsoft gives you:

• Reduced risk of unintended access if URLs are logged, forwarded, or intercepted.

• Stronger auditing and traceability, since access is associated with a specific user or service principal.

• A smoother path to least-privilege designs in multi-user and multi-tenant scenarios, such as analytics clusters, partner integrations, or SaaS workloads.

This preview also aligns with Microsoft’s broader push to make identity-based access the default for Azure Storage—extending user delegation SAS beyond blobs to tables, files, and queues earlier this year, and now adding user‑bound constraints on top.

If you are already using SAS heavily, especially in environments where URLs are shared across teams or tenants, user‑bound UD SAS is worth testing now while it is in preview. Microsoft is actively soliciting feedback through a dedicated feedback form and encourages customers to open support requests if they run into issues. That suggests this feature is likely to evolve quickly based on real‑world usage before it becomes generally available.

Here are a few links to help you get started:

Create a user delegation SAS for a container or blob with .NET

Construct a user delegation SAS

Get the OAuth object ID and tenant ID from your end user. They will have to get these IDs (instructions here) 

Recent Posts You Might Like

• • MWC 2026: Microsoft Supercharges Telecom AI with Powerful Azure Local and Sovereign Edge
  • Japan Raids Microsoft Japan Over Massive Alleged Azure Anti‑Monopoly Violations
  • The Microsoft Japan Azure Antitrust Probe Puts Global 2026 Cloud Licensing Under Intense Pressure
  • Azure Storage Adds Secure User-Bound User Delegation SAS to Lock Tokens to a Single Entra ID Identity
  • Copilot Tasks unlocks powerful and seamless real-world action from Microsoft’s AI