Glossary

| min

SAS Token

What Is a SAS Token?

A Shared Access Signature (SAS) token is Azure’s way of giving temporary, fine-grained access to your storage resources. Instead of handing over your master storage account keys, you generate a signed URL with a SAS token attached. This lets users or applications perform specific tasks without ever seeing your main credentials.

A SAS token defines exactly three things: what resource can be accessed, what actions are allowed, and when the permission expires. Depending on how you set it up, the token is signed using either your storage account key or a user delegation key tied to Microsoft Entra ID.

How a SAS Token Authenticates a Request

When a client sends a request with a SAS token, Azure Storage checks the signed parameters embedded in the URL, including the permissions, timeframe, and signature. If the signature matches and all conditions are met, Azure allows the operation to proceed.

Consider this deliberately synthetic example of a SAS URL:

https://examplestorage.blob.core.windows.net/reports/sample.pdf

?sv=FAKE

&sp=r

&st=2026-10-13T09:00:00Z

&se=2026-10-13T10:00:00Z

&sr=b

&sig=NOT_A_REAL_SIGNATURE

‍

The parameters illustrate how a SAS URL is structured:

sp=r — Permissions: Illustrates read-only access.
st — Start time: The time from which access is intended to be valid.
se — Expiry time: The time after which the token expires.
sr=b — Resource: Indicates a blob resource.
sig — Signature: Represents the signature Azure Storage validates against the SAS parameters.

The values above are illustrative placeholders, not a working credential. Actual SAS parameters depend on the token type and the resource being accessed.

For Service SAS and Account SAS, the signature is generated using the storage account key. Anyone with access to that key may be able to generate additional SAS tokens, which makes protecting the signing key essential. A User Delegation SAS instead uses a user delegation key obtained through Microsoft Entra credentials.

SAS Token vs SAS URL vs SAS Key

A SAS token, a SAS URL, and a storage account key serve different purposes. Understanding the distinction helps teams identify what has been exposed and which security controls are needed.

Aspect	SAS token	SAS URL	Storage account key
What it is	A signed set of query parameters	A resource URL combined with a SAS token	A long-lived secret used to authorize access and sign certain SAS types
What it contains	Permissions, validity parameters, signature	Resource address and SAS query string	The secret key itself
What it grants	Scoped access defined by the token	Access to the specified resource under the token's conditions	Broad account-level capabilities, depending on the authorization mechanism
How it is revoked	Depends on the SAS type and signing method; individual revocation is generally unavailable for ad hoc SAS tokens	Depends on the SAS token embedded in the URL	The key can be rotated, invalidating credentials that depend on it

A SAS URL is the complete address shared with a client, and the SAS token is the authorization information appended to that address. The account key, on the other hand, is a sensitive credential that can be used to sign Service SAS and Account SAS tokens.

Types of SAS: User Delegation, Service, and Account

Azure Storage supports three types of SAS. They differ in how they are signed, the resources they cover, and the controls available for managing access. Microsoft recommends User Delegation SAS whenever possible.

User Delegation SAS: Secured using a user delegation key obtained through Microsoft Entra credentials. It grants access according to the permissions specified in the SAS and is Microsoft's recommended option for supported scenarios. It avoids signing the SAS directly with the storage account key.
Service SAS: Signed using the storage account key and grants access to a resource within a single Azure Storage service. It can be associated with a stored access policy, allowing its constraints to be managed and its permissions to be revoked through that policy.
Account SAS: Also signed using the storage account key, but can delegate access across one or more storage services and authorize certain service-level operations. It offers broader scope and does not support stored access policies.

For security teams, User Delegation SAS is generally the preferred choice when supported by the workload. Service SAS may be appropriate where stored access policies are useful for managing revocation. Account SAS should be restricted to cases that genuinely require its broader capabilities.

The SAS Token Revocation Problem

An Azure SAS token generally cannot be revoked individually once issued as an ad hoc token. Azure Storage does not maintain a central inventory of generated SAS tokens, so security teams may not know which tokens remain active or where they have been shared.

This creates a practical challenge when a token leaks into a repository, log, application, or public URL. Deleting the exposed copy does not invalidate copies that someone else may already have obtained.

Azure provides different options depending on how the SAS was signed and configured:

Rotate the storage account key: Service SAS and Account SAS tokens signed with that key become invalid. However, other applications and credentials that depend on the same key may also be disrupted, so rotation requires impact assessment and coordinated updates. See Token Security's guide to token rotation.
Use a stored access policy: A Service SAS associated with a stored access policy can have its permissions revoked by changing or deleting the policy. This avoids rotating the account key but can affect every SAS token associated with that policy. Stored access policies are not supported for User Delegation SAS or Account SAS.
Prefer User Delegation SAS: These tokens use a user delegation key rather than the storage account key. Azure supports revoking user delegation keys, which invalidates SAS tokens signed with the affected key. This is not the same as individually revoking a single token, and other tokens using that key may also be affected.
Set short validity periods: Expiration limits how long an exposed token remains usable. Azure Storage expiration policies can help enforce or monitor validity intervals, but they do not provide individual revocation of an otherwise valid token.

This is also where non-human identity management becomes relevant. Token Security's non-human identity management platform helps organizations discover non-human identities and credentials across their environments, including credentials that may otherwise remain outside a centralized inventory.

Why SAS Tokens Matter in Security

SAS tokens allow organizations to grant temporary access without distributing permanent account credentials. When configured correctly, they support least-privilege access by limiting the resources, operations, and period for which a client is authorized.

Common applications include:

IoT device authentication: Azure IoT Hub supports SAS-based device authentication.
Service-to-service messaging: Azure Event Hubs supports SAS authentication for authorized access.
Temporary file access: Storage accounts can issue scoped permissions for partners, applications, and batch-processing workloads to upload or download data.

For these use cases, SAS tokens can reduce the need to distribute account keys or route every data transfer through an application server. However, a token remains a bearer credential: anyone who obtains it may be able to use it within its permitted scope and validity period.

Organizations should therefore treat SAS URLs as sensitive credentials, not ordinary links. Their security depends on careful issuance, limited permissions, appropriate expiration, and a clear response plan for exposed tokens.

Common Use Cases of SAS Tokens

Azure services rely on SAS authentication for several scenarios. IoT Hub uses SAS tokens for device authentication, allowing devices to authenticate without embedding storage account keys. Event Hubs employs SAS for service-to-service messaging authorization. Storage accounts can issue SAS tokens to grant temporary upload or download permissions to external partners, mobile clients, or batch-processing jobs. Developers can generate SAS URLs to provide time-limited access to blobs, queues, tables, or files without distributing the underlying account key.

Best Practices for SAS Token Security

Effective SAS token security requires controls over issuance, scope, expiration, monitoring, and incident response. The following practices help reduce the risk of exposed or overprivileged tokens.

Prefer User Delegation SAS: Use Microsoft Entra credentials instead of storage account keys when supported by the workload.
Apply least privilege: Grant only the permissions and resource access required for the task. Prefer read-only access when write operations are unnecessary.
Set short expiration periods: Choose a validity window that matches the use case and configure an appropriate SAS expiration policy.
Require HTTPS: Protect SAS URLs in transit and avoid exposing them in public links, client-side code, logs, or repositories.
Generate tokens through trusted services: Issue SAS tokens through authenticated backend services rather than embedding signing credentials in client applications.
Restrict token-generation privileges: Limit who can generate SAS tokens and review access to storage account keys and user delegation key permissions.
Monitor access and scan for exposure: Use repository scanning and available Azure Storage logs to identify suspicious usage and exposed SAS URLs. Remember that Azure Storage does not centrally track every SAS token generated.
Prepare a revocation plan: Know whether the affected token requires key rotation, stored access policy changes, or user delegation key revocation, and assess the impact before taking action.

Related Terms

User Delegation Key
Account Key Rotation
Token Broker Pattern
Signed URI
Managed Identity
Least Privilege Access
API token

‍

FAQ

What does SAS stand for?

SAS stands for Shared Access Signature. In Azure, a SAS token is a signed set of query parameters that grants time-limited, scoped access to a resource without requiring the recipient to hold the storage account key.

Can you revoke a SAS token?

An ad hoc SAS token generally cannot be revoked individually. Depending on its type, you may need to rotate the signing account key, modify or delete an associated stored access policy for a Service SAS, or revoke the user delegation key used to sign a User Delegation SAS. These actions can affect other tokens or applications, so assess the impact before proceeding.

How long should a SAS token last?

A SAS token should remain valid only as long as the intended task requires. Set the shortest practical validity period, account for application needs and clock differences, and configure an Azure Storage SAS expiration policy where appropriate. Short expiration reduces the window in which a leaked token can be used, but does not replace least-privilege permissions or a revocation plan.