Build Shared Access Signature token configurations with permissions and expiry settings.
Last verified: May 2026
Build Shared Access Signature token configurations with permissions, IP restrictions, and expiry settings.
Required Fields
storageAccountNamesignedPermissionssignedExpirysignedProtocolOutput will appear here...Shared Access Signatures (SAS) provide delegated access to Azure Storage resources without sharing account keys. There are three types: account SAS (scoped to one or more storage services), service SAS (scoped to a single service like Blob or Queue), and user delegation SAS (signed with Microsoft Entra credentials instead of account keys). Building SAS tokens requires specifying the correct permissions, resource types, protocol restrictions, IP ranges, and expiry times. This builder helps you construct SAS tokens with correct signing parameters, permission combinations, and constraint configurations while following security best practices.
Service and account SAS tokens are signed with the storage account access key, meaning anyone with the key can create unlimited tokens with any permissions. User delegation SAS tokens are signed with Microsoft Entra ID user or service principal credentials, providing better auditability and the ability to revoke access via Entra ID. User delegation SAS also supports more granular permissions and is Microsoft's recommended approach. However, user delegation SAS is only available for Blob Storage and Data Lake Storage.
For service and account SAS tokens, the only direct revocation methods are rotating the storage account key used to sign them (which invalidates all tokens signed with that key) or deleting the stored access policy if one was used. For user delegation SAS, you can revoke the user delegation key. Stored access policies are the recommended approach for revocable SAS tokens — you create a policy on the container, reference it when generating the SAS, and can modify or delete the policy to invalidate all associated tokens.
Always use HTTPS-only SAS tokens (set the protocol to https), set the shortest practical expiry time, grant only the minimum required permissions, restrict to specific IP addresses when possible, and prefer user delegation SAS over account key-signed SAS. Use stored access policies for service SAS to enable revocation. Never embed SAS tokens in client-side code or URLs that could be logged. Monitor storage analytics logs for unexpected SAS usage patterns.
Your team needs to give external contractors temporary access to upload files to a specific blob container. Naive approach: share the storage account key. The builder generates a service SAS via a stored access policy: write-only permission, 24-hour expiry, IP-restricted to the contractor's office, HTTPS-only. When the contract ends, you delete the stored policy — every token issued under it is instantly invalid. Storage account key never leaves your control.
The builder constructs SAS token URLs by computing the canonical signed string from the parameters (permissions, resource type, start/expiry time, IP range, protocol, signed identifier for stored policies, signing key OCID for user delegation), generating the HMAC-SHA256 signature, and assembling the final URL with all SAS query parameters. For user delegation SAS, it generates the prerequisite az storage account get-user-delegation-key command. Output supports all three SAS types (account, service, user delegation).
User delegation SAS is the right answer for any new SAS work in 2026. Service/account SAS tokens signed with the storage account key are a security nightmare — anyone with the key can mint unlimited tokens, and revocation requires rotating the key (which breaks every other consumer). User delegation SAS is signed with Entra credentials and revocable per-identity.
Always use stored access policies for service SAS when possible. Without a stored policy, the only way to revoke a SAS token before expiry is to rotate the storage account key. With a stored policy, you can modify or delete the policy to invalidate all associated tokens.
Set the SHORTEST practical expiry. The default in many SDK examples is days or weeks — that's a leakage risk. Most legitimate SAS use cases need 1 hour or less. If a user genuinely needs longer access, generate a fresh token via your auth backend rather than handing out a long-lived one.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.