Azure user delegation SAS improves revocation, within cache limits
A shared access signature grants a client limited access to Azure Storage without giving it the account key. The signature is a bearer credential, so its scope, lifetime, and revocation path matter. Azure supports user delegation SAS, service SAS, and account SAS. A user delegation SAS is signed with a Microsoft Entra credential rather than the storage account key, which makes it a better fit for temporary delegated access.
The access model has two layers. The caller needs permission to obtain a user delegation key, and the resulting SAS is also constrained by the permissions encoded in the signature. Microsoft's documentation states that the security principal's RBAC or POSIX ACL permissions must also permit the operation. A SAS does not create access that the delegating identity lacks.
Revoking the user delegation key can invalidate SAS values issued from it. That is a useful containment lever, but the provider caches the key and role assignments. Microsoft documents that a delay may occur between the revocation request and the time an existing SAS becomes invalid. An incident response plan should verify the effective denial rather than assume an immediate cut-off.
Scope the signature tightly
Limit the SAS to the required service, container, directory, or blob. Use the smallest permission set and the shortest practical expiry. Bind the signature to the intended network or client context where the storage service supports that restriction. Keep signed start times explicit so clock skew does not create a longer or shorter window than expected.
Do not hand the account key to an application merely to simplify SAS creation. Grant the application permission to obtain delegation keys only if it must create SAS values, and separate that automation from the service that consumes the SAS. Store the signing credential in a managed identity or another controlled secret store.
Prefer a revocation plan over a fixed lifetime
A long lifetime is not a revocation plan. For container or blob access, define which key or stored access policy can be revoked, who can perform the revocation, and how the team confirms that clients lost access. For a service SAS that references a stored access policy, modifying or deleting the policy can affect the signatures that reference it. For account-key and service SAS, rotating the account key may have broader consequences than intended.
Consider disabling Shared Key authorization at the storage account when the workload can use Microsoft Entra identity or user delegation SAS. Microsoft documents that user delegation SAS remains permitted when AllowSharedKeyAccess is false, while account SAS and Shared Key requests are denied. Test applications and tooling before enforcing the change.
Log the principal and the signature
Record the delegating principal, storage account, resource scope, permissions, start and expiry times, and the identifier of the SAS or policy. Do not log the complete signature. Alert when a SAS with write or delete permissions is created outside the approved automation, when its lifetime exceeds policy, or when the delegating identity gains a broader RBAC assignment.
When revoking a key, check the resource with a known valid request after the documented cache period. Rotate downstream clients and remove old signatures from queues, build logs, browser history, and case-management tools. A revocation that leaves a copy of the bearer credential active elsewhere has not completed containment.
User delegation SAS makes delegation auditable and revocable through a key path, but it does not remove the need to understand RBAC, caching, and credential handling. The signature should be treated as a short-lived delegated identity with a tested retirement path.
Top comments (0)