Azure Blob SAS: check start and expiry times

Separate the validity window from the permissions

Record the service error and inspect the intended start and expiry values without exposing the complete token. Do not repeatedly add permissions when the reported failure is temporal rather than an operation grant.

The lab first set the start one hour ahead and expiry two hours ahead. Reading the existing blob failed with 403. A separate SAS whose expiry was already past also failed. The endpoint, resource, and read operation were otherwise unchanged.

Use timezone-aware UTC values

Generate timestamps in UTC with an explicit timezone. Local wall-clock assumptions can produce an unintended future start or a shorter lifetime than expected. Confirm that the signing machine’s time is synchronized before investigating small timing differences.

For immediate access, do not add an unnecessary future start. Where a start time is required by policy or workflow, choose it deliberately and account for clock skew using the relevant service guidance. Keep the allowed duration appropriate to the task.

python · EXAMPLE

from datetime import datetime, timedelta, timezone

now = datetime.now(timezone.utc)
expiry = now + timedelta(minutes=10)
# These are aware UTC values. Do not substitute a naive local timestamp.

Regenerate a token for the intended window

For the lab’s immediate read, we omitted an explicit start and supplied a near-term expiry. The following function illustrates that service-SAS contract with an authorized signing key. It is not a recommendation to distribute account keys or bypass the production signing service.

Generate a new signature rather than editing st or se in a copied URL. Those query values are part of the signed grant; manually changing them does not create a valid extension.

python · EXAMPLE

from azure.storage.blob import BlobSasPermissions, generate_blob_sas

def make_test_read_sas(account, container, blob, signing_key, expiry):
    return generate_blob_sas(
        account_name=account, container_name=container, blob_name=blob,
        account_key=signing_key, permission=BlobSasPermissions(read=True),
        expiry=expiry,
    )

Verify the window with the same operation

Request the same intended blob through the regenerated token and confirm the expected result. Keep method, resource, and permissions fixed while checking the time change so a different variable does not hide the explanation.

Our currently valid read returned the seeded content after both invalid windows had been rejected. This establishes the emulator’s validity checks for the tested SAS, rather than proving that a particular production token or signing identity is correct.

Check the grant’s other lifetime limits

A stored access policy, user-delegation key, revoked signing key, or other relevant configuration can affect access beyond the displayed query timestamps. Investigate those through the actual signing mechanism and service evidence when the simple window comparison is insufficient.

Keep signed URLs out of public diagnostics. Record only the necessary UTC times, operation, service code, and verification outcome. A bounded, explained repair is more useful than making tokens increasingly long-lived until a test happens to pass.

Know the limits

Validated with Azurite and azure-storage-blob 12.31.0 using API version 2023-11-03. A future-start SAS and an expired SAS were rejected; a currently valid token without an explicit future start could read the blob. Cloud user-delegation key lifetime and stored-policy changes were not tested.

Sources & further reading

A technical publication by CoreTrailKit.

Browse all articles