Azure Storage gives administrators several ways to authorize data access, and the most important design choice is whether the caller should authenticate as an identity or receive a delegated token. Microsoft recommends Microsoft Entra ID for identity-based access whenever possible and recommends user delegation SAS when a shared access signature is appropriate for Blob Storage. Shared Key remains available in many scenarios, but it is a broad secret and should not be the default for modern production workloads.
For AZ-104, it is useful to separate authentication, authorization, and delegation. Microsoft Entra authenticates the principal. Azure RBAC determines what that principal may do. A SAS delegates a limited set of storage permissions for a defined period and scope. Once those roles are clear, storage access stops looking like a collection of connection-string tricks and becomes a manageable security model.
Prefer identity-based authorization for long-lived workloads
A Microsoft Entra user, service principal, or managed identity can obtain an OAuth token and use it to access supported Azure Storage data services. The identity receives an Azure Storage data role at an appropriate scope, such as a storage account or container. This creates access that is attributable to a principal, auditable through identity and Azure logs, and revocable by changing the role assignment.
That is fundamentally different from distributing an account key. A storage account key is a symmetric secret with broad power over the account. Anyone who obtains it can use Shared Key authorization until the key is rotated or Shared Key access is disabled. The key does not express which application, user, or workload is making the request in the same way an Entra token does.
For Azure-hosted applications, managed identities make the identity model even stronger because the platform manages credentials instead of requiring secrets in configuration. The workload gets a token for Storage at runtime and Azure Storage evaluates its data role. This reduces secret handling and aligns access with the same RBAC model administrators use elsewhere in Azure.
Identity-based access also improves incident response. If one workload is suspected of compromise, its role assignment can be removed or narrowed without rotating a key used by unrelated applications. With Shared Key, rotation can become a coordinated outage risk because every consumer of that key must update. Reducing the number of shared secrets therefore improves both prevention and containment.
Management roles and data roles are not the same permission
An administrator can have permission to configure a storage account and still be unable to read its blobs by using Microsoft Entra authorization. Azure Storage defines data-plane roles such as Storage Blob Data Reader, Storage Blob Data Contributor, and Storage Blob Data Owner. Those roles contain data actions that authorize access to content.
Roles such as Owner or Contributor primarily grant management-plane permissions. Some management roles can also list account keys, which may let a user access data through Shared Key, but that is not the same as having an Entra data role. This distinction explains why a portal user sometimes sees the storage account but receives an authorization error when opening a container with Entra authentication.
The identity depth associated with SC-300 is useful here. Azure RBAC data roles govern what an identity can do to storage data, while Microsoft Entra governs the identity itself. An editorial overview of the identity and access administrator role shows the broader context in which those principals, groups, and application identities are managed.
The portal’s authentication selector is a useful diagnostic clue. If a user can browse data only when the portal switches to the account key, that does not prove Entra data access is configured correctly. Administrators should test the intended authorization mode explicitly. Otherwise a permissive management role with key-list permission can hide the absence of the data-plane role the production application will actually use.
SAS is delegation, not a replacement identity system
A shared access signature is a URI token that grants limited access to Azure Storage resources according to the permissions, resource scope, and validity period encoded or referenced by the signature. It is useful when a client needs temporary access but should not receive the storage account key and may not have a Microsoft Entra identity that can be used directly.
The key word is delegated. A SAS should be issued for the smallest practical resource scope, permissions, and time window. A client that only needs to upload one blob should not receive list, read, delete, and write access across an entire account for a month. SAS makes narrow delegation possible, but it remains a bearer token: possession of the token is sufficient to use its granted rights while it is valid.
SAS URLs should therefore be handled like secrets. Avoid placing them in source code, long-lived logs, public tickets, analytics events, or browser history where possible. Use TLS, keep expirations short, and design applications so a leaked SAS can be replaced without redesigning the entire access model.
Design the service that issues SAS tokens as a privileged component. It decides which client receives which access, so its authorization logic becomes part of the storage security boundary. A token issuer should authenticate the caller, validate the requested object and permissions, create the shortest practical token, and avoid returning broader scope simply because the signing process makes it easy.
User delegation SAS is the preferred SAS model for Blob Storage
A user delegation SAS is secured with Microsoft Entra credentials rather than directly with the storage account key. An authorized principal requests a user delegation key and uses it to sign the SAS. Microsoft recommends this approach for Blob Storage because it keeps SAS issuance within the identity and RBAC model instead of depending on a shared account secret.
The principal that creates the user delegation SAS still needs permission to request the delegation key and must have the relevant data permissions. That provides an administrative chain that can be audited and revoked. It also fits applications that already use managed identities: the Azure-hosted workload can authenticate with its managed identity, obtain the delegation capability it is permitted to use, and issue short-lived SAS tokens to clients.
This approach does not make the resulting SAS non-sensitive. The client still receives a bearer token and should protect it. The security improvement is in how the token is authorized and signed, and in reducing dependency on a high-value account key.
User delegation also makes revocation strategy clearer. Removing or changing the issuer’s permissions stops new delegation, but already issued SAS tokens remain usable until their own expiry unless another control invalidates access. Short token lifetimes are therefore important. The architecture should assume that a token already delivered to a client cannot be recalled like a normal interactive user session.
Service SAS and account SAS depend on Shared Key
A service SAS delegates access to resources in one Azure Storage service and is signed with an account key. An account SAS can delegate operations across one or more storage services and is also signed with an account key. Both can be valid designs for legacy or specific compatibility scenarios, but their security ultimately depends on protecting Shared Key.
If an organization is trying to eliminate Shared Key, those SAS types become important migration considerations. Disabling Shared Key authorization can break workloads that still use account-key-signed SAS tokens. The migration should therefore inventory access patterns, move long-lived workloads to Entra ID, move compatible Blob delegation to user delegation SAS, and test before the account setting is changed.
A broader explanation of Azure data storage and processing helps place authorization in context: storage services have different access patterns, and security controls should follow the actual data operation rather than a one-size-fits-all connection string.
Stored access policies can help with certain service-SAS scenarios by associating permissions and expiry with a server-side policy that can later be changed. That capability does not turn Shared Key into the preferred model, but it can provide more control for legacy delegation designs. Know which SAS type and storage service support the feature before relying on it as a revocation mechanism.
Scope and expiry are the core controls inside a SAS
A secure SAS is intentionally constrained. Specify only the permissions the client needs, such as read or write. Limit the signed resource to the required container, blob, queue, table, or service scope. Use a short expiry that matches the business operation. Where supported and appropriate, additional restrictions such as protocol and network-related constraints can reduce exposure further.
Start time deserves care. Clock skew between systems can cause a SAS that begins “now” to appear not yet valid to another system. For immediate-use tokens, designs often omit a start time or allow a small buffer rather than making the validity window start at the exact issuing timestamp. Expiry should still remain as short as practical.
Delegation should also reflect storage type. Blob, file, queue, and table workloads have different authorization features and client behavior. The fundamentals in block, file, and object storage help explain why the same application pattern does not fit every data service.
Permission order and service semantics should be validated with the exact client operation. A token that includes read but not list might open a known blob while failing a directory-like browse operation. That can be intentional least privilege rather than a defect. Define the minimum API actions the client performs and issue the SAS for those operations instead of copying a broad example from documentation.
Disallowing Shared Key changes the security posture
Azure Storage can be configured to reject requests authorized with Shared Key. Microsoft recommends moving workloads to Microsoft Entra ID wherever possible and treating Shared Key as a legacy fallback. When Shared Key is disallowed, account-key-based access stops working, including compatible workflows that depend on account keys.
This is a powerful hardening control because stealing the account key no longer grants data access through Shared Key. It also forces teams to make identity explicit. However, enabling the setting without discovery can create an outage. Applications, scripts, third-party tools, and SAS issuance patterns must be reviewed first.
Key management still matters during transition. If account keys remain enabled, store them in a protected secret-management system, avoid embedding them in code, and rotate them according to a documented process. The long-term goal should be to reduce how many components need the key at all.
Migration telemetry helps identify hidden Shared Key consumers. Storage logging, application configuration review, and controlled testing can reveal scripts or tools that were never included in the application inventory. Treat the hardening change like an authentication migration: measure usage, move clients, stage the enforcement, and keep a rollback plan that does not involve publishing account keys to more people.
Troubleshoot the authorization path in the right order
When a request fails, first identify the authorization method the client is actually using. The Azure portal, CLI, SDK, and application code can use different methods depending on configuration. Confirm whether the request carries an Entra token, Shared Key signature, or SAS before changing roles or regenerating secrets.
For Entra access, verify the principal, its storage data role, and the role-assignment scope. Remember that role assignments can take time to propagate. For SAS, inspect the service, resource, permissions, start and expiry times, protocol requirements, and signature source. For network-restricted storage, verify that the caller can reach the account through the allowed public or private network path as well.
A failed authorization is not always an identity failure. A network rule can block a correctly authorized principal, and a valid private endpoint can deliver traffic for a principal that lacks data rights. Separating network reachability from authentication and authorization makes diagnosis much faster.
Capture the failing request time and storage endpoint before changing anything. That gives logs and diagnostics a precise window and prevents a successful retry after a role change from erasing the original evidence.
Design storage access so every credential has a clear purpose
A good Azure Storage design can explain why each access mechanism exists. Human administrators use Microsoft Entra identities and narrow data roles. Azure workloads use managed identities where supported. External or temporary clients receive short-lived SAS tokens with minimal permissions. Account keys are avoided or tightly controlled, and Shared Key is disabled when compatibility permits.
Review access regularly. Direct user assignments can often move to groups. Long-lived SAS tokens can often be replaced with a token service that issues short-lived delegation. Legacy connection strings can often move to managed identity. The security improvement comes from removing unnecessary secrets and shrinking the lifetime and scope of the credentials that remain.
Azure Storage supports several authorization mechanisms because workloads differ, not because every application should use all of them. Use Entra ID as the durable identity foundation, SAS as controlled delegation, and Shared Key only where a verified requirement still exists. That model is easier to audit, rotate, and defend.
The approved Microsoft certification ecosystem includes storage, identity, and administration paths because these concerns intersect in practice. A secure storage design depends on all three: the storage service must expose the right data boundary, the identity platform must authenticate the caller, and the administrator must assign the narrow permission. Treating authorization as a storage-only setting misses the cross-service nature of the control.