Support connecting with user-bound user delegation SAS

The issue describes adding support for user-bound user delegation SAS in Azure Storage Explorer. Start by reviewing the Azure Storage REST documentation linked in the issue, focusing on the sv, sduoid, and skdutid parameters. Examine the existing connection workflow and credential management code, likely in the Azure.Storage or authentication modules. Check how the transfer engine handles credentials and token renewal. The acceptance criteria list specific scenarios to test, such as browsing, uploading, and handling token expiry.

Problem

Azure Storage supports user-bound user delegation SAS (also called principal-bound user delegation SAS). Access requires both the SAS and a Microsoft Entra bearer token identifying the intended recipient.

Storage Explorer needs a connection workflow supporting both credentials. A SAS URL alone is insufficient. Substituting OAuth-only access is not equivalent because it does not preserve the SAS's delegated permissions, resource scope, and validity period.

Desired solution

Support connecting with an existing user-bound user delegation SAS, initially for Blob Storage and ADLS Gen2 container/directory attachments.

• Accept the SAS URL and allow selection or sign-in of the intended Entra account and tenant.
• Acquire and refresh bearer tokens through the existing sign-in experience rather than requiring users to repeatedly paste short-lived tokens.
• Preserve the original SAS and send both credentials on applicable data requests, including background operations and transfers.
• Restore the connection's account/tenant association after restarting.
• Distinguish expired bearer tokens, expired SAS tokens, identity mismatches, insufficient permissions, and cross-tenant policy failures.
• Never silently fall back to OAuth-only access, account keys, or a different SAS.

Creating user-bound SAS tokens and configuring storage-account policies are separate enhancements, not prerequisites for consuming an existing SAS.

Implementation considerations

The public Azure Storage REST documentation describes:

• sv=2025-07-05 or later for user-bound SAS.
• sduoid: the delegated recipient's Entra object ID, corresponding to the bearer token's oid claim. This differs from skoid, which identifies the principal that requested the delegation key, and from the older saoid/suoid fields.
• skdutid: the delegated recipient's tenant ID when applicable, corresponding to the bearer token's tid claim.
• Cross-tenant use requires the storage account's allowCrossTenantDelegationSas setting. Explain policy rejection rather than changing that setting automatically.

Verify request-header requirements, token audience, tenant selection, and SDK support against the service contract. Confirm that the transfer engine supports both credentials and token renewal; successful browsing alone is not sufficient.

Review copy, preview, and open-in-browser operations as well. Passing only a SAS URL to another process or browser cannot supply the required identity token. Clearly identify unsupported operations.

Use existing secure credential storage and redaction. Do not include bearer tokens in URLs or expose either credential in logs, telemetry, or error messages.

Acceptance criteria

• The matching identity can attach, browse, read properties, upload, download, and delete within the SAS's permissions and scope on Blob Storage and ADLS Gen2.
• Delegated access works for a recipient without equivalent direct data access, demonstrating that requests are not relying on OAuth-only authorization.
• Missing/wrong identities and requests outside the SAS's scope, permissions, or validity period fail without credential fallback.
• Bearer-token renewal works during long-running operations. Restart, account removal, reauthentication, and SAS expiry are handled predictably.
• Same-tenant and permitted cross-tenant connections work; prohibited cross-tenant connections produce actionable errors.
• Unsupported transfer, copy, or preview paths explain the limitation instead of dropping a credential.
• Existing ordinary SAS and OAuth connections remain unchanged.
• Automated coverage verifies credential propagation, negative authorization cases, and secret redaction.

Alternatives and workarounds

Use a client that explicitly supports user-bound SAS, or direct Entra access where suitable permissions already exist. Direct Entra access is not equivalent for recipients whose access is granted only through the SAS.

Public reference

https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas#user-bound-user-delegation-sas