Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.
4.2.2. Shared Access Signatures (SAS)
💡 First Principle: SAS tokens provide delegated access with granular control over permissions, resources, and time. They're ideal for granting limited access without exposing account keys.
Scenario: An external application needs to upload files to a specific container for a five-day test period. The application runs on-premises and cannot use managed identity.
SAS Types
| Type | Scope | Key Source | Best For |
|---|---|---|---|
| Account SAS | Multiple services | Account key | Broad access |
| Service SAS | Single service (blob, queue, table, file) | Account key | Service-specific access |
| User Delegation SAS | Blob storage only | Microsoft Entra credentials | Most secure for blob |
SAS Parameters
- Signed start (st): When the SAS becomes valid
- Signed expiry (se): When the SAS expires
- Signed permissions (sp): What operations are allowed
- Signed IP (sip): Restrict to specific IP addresses
- Signed protocol (spr): HTTPS only or HTTP/HTTPS
Key Decision Points:
| Scenario | Solution |
|---|---|
| Time-limited access (5 days) | SAS with expiry date |
| Access to single table only | Service SAS (not Account SAS) |
| Restrict to single IP per file (1000+ files) | Service SAS with signedIP field |
⚠️ Exam Trap: Using storage account firewall to restrict SAS access to specific IPs when you need per-file IP restrictions. The firewall is limited to 200 IP rules. For per-file IP restrictions, use the signedIP field in each SAS token.
Revoking SAS Access
- Regenerate storage account keys: Invalidates all SAS tokens created with that key
- Stored access policy: Modify or delete the policy to revoke SAS tokens using it
Written byAlvin Varughese
Founder•15 professional certifications