Azure Storage supports several authorization methods, and choosing the wrong one can create unnecessary risk.

Microsoft currently recommends Microsoft Entra ID for many Azure Storage data-access scenarios because identity-based access is auditable and can use Azure RBAC. Shared access signatures provide delegated, time-bounded access. Storage account keys provide broad Shared Key authorization and should be treated as high-impact secrets.

Choose storage authentication by tracing who needs access, which data-plane operation must be permitted, how long it should remain usable and how credentials can be revoked. An application using an appropriate Microsoft Entra data role has a different recovery and rotation profile from one using a shared account key or an expiring SAS. Test a user who can manage a storage account but cannot read a particular blob, then test a SAS that expires during a long transfer. These are realistic decision points for AZ-104 storage practice scenarios; the correct reasoning distinguishes Azure management roles, Blob data permissions, delegated tokens and downstream application behavior rather than choosing a credential solely because it grants immediate access. The official Microsoft Learn blueprint remains the factual source for what is assessed.

Microsoft Entra ID is identity-based authorization

Microsoft Entra authorization uses an identity rather than a shared account secret.

The identity can be:

• a user
• a group
• a service principal
• a managed identity

Azure RBAC data roles then determine what that principal can do with the storage data.

Examples include roles such as Storage Blob Data Reader or Storage Blob Data Contributor.

This model is attractive because access can be granted at an appropriate scope and revoked without rotating a storage-account-wide secret.

Microsoft recommends Entra-based authorization where practical.

Microsoft Entra authorization gives Azure Storage an identity that can be granted a narrow data role and revoked without rotating a shared account secret. Managed identities make that model practical for Azure-hosted workloads because the application can request a token without storing a client secret in configuration.

The role still has to be a data-plane role for the service being accessed. An administrator who can create a storage account does not automatically have permission to read every blob inside it. Roles such as Storage Blob Data Reader or Storage Blob Data Contributor represent data operations, while general management roles govern the Azure resource itself. Mixing those two planes is a common reason an administrator can configure a storage account but receives a 403 from the data endpoint.

Management-plane roles are not automatically data-plane roles

A frequent Azure Storage misunderstanding is assuming that permission to manage the storage account automatically grants access to blob data.

Azure separates control-plane and data-plane authorization.

A user may be able to configure the storage account while lacking a Storage Blob Data role.

Conversely, an application may have data access without broad permission to change the storage account resource.

That separation supports least privilege.

It also explains why portal behavior can sometimes be confusing: the portal may require management permissions to navigate resources while the actual blob operation uses separate data-plane authorization.

Account keys provide broad Shared Key authorization and should be treated like root-level credentials for the storage account. Any application that receives a key can sign requests within the capabilities of that account, and rotating a key affects every dependency that still uses it.

Azure supports two account keys so an organization can rotate one while clients temporarily use the other, but the stronger long-term design is to reduce the number of clients that need Shared Key at all. Microsoft recommends Entra-based authorization where supported and allows Shared Key authorization to be disabled for storage scenarios that have been migrated.

Storage account keys are powerful shared secrets

A storage account has access keys that can be used for Shared Key authorization.

Anyone who possesses a valid account key can perform operations allowed by Shared Key for that service and account.

That makes the keys operationally convenient but very sensitive.

Microsoft’s current security guidance recommends limiting Shared Key use and moving workloads toward Microsoft Entra authorization where possible.

The key problem is scope.

An account key is not tied to one named user and is not naturally limited to one container or short expiration period.

If it leaks, the blast radius can be large.

SAS delegates limited access

A shared access signature grants access through a signed token.

The SAS can constrain:

• resource
• permissions
• time window
• protocol
• other supported restrictions

That makes SAS useful when an application or user needs limited access without receiving the account key.

There are multiple SAS types.

A user delegation SAS is secured using Microsoft Entra credentials.

A service SAS is signed with the storage account key and grants access to a service resource.

An account SAS is also signed with the account key and can cover broader account-level capabilities.

Microsoft recommends a user delegation SAS when possible for blob scenarios because it is rooted in Entra authorization instead of Shared Key.

The three SAS types have different trust roots. A user delegation SAS is created from Microsoft Entra credentials and is preferred when its supported storage service and scenario fit. A service SAS is signed with the storage account key and delegates access within one storage service. An account SAS is also signed with the account key and can cover broader service-level operations.

The token itself is a bearer credential: anyone who obtains a valid SAS URI can use the permissions encoded in it until the token expires or its authorization is otherwise invalidated. That makes scope, protocol restriction, permissions, start time, expiry, and secure distribution part of the security design rather than optional cleanup.

SAS is a bearer credential

A SAS token is effectively a bearer credential.

Anyone who gets the token can use the permissions encoded in it until the token expires or otherwise becomes invalid.

That means the token itself must be protected.

Do not place SAS tokens in source code, logs, screenshots, tickets, or other places where they can be copied unintentionally.

Use short expiration times and narrow permissions appropriate to the task.

A SAS should still be treated as a secret even when the application that generated it used strong identity controls.

Stored access policies apply to service SAS

A stored access policy lets an administrator define permissions, start time, and expiry information on the storage resource and associate a service SAS with that policy.

This provides more management flexibility than embedding every constraint only in the SAS URI.

Microsoft documents stored access policies for service SAS scenarios.

They are not supported for account SAS or user delegation SAS.

This distinction matters because administrators sometimes assume a stored access policy can centrally manage every SAS type.

It cannot.

Stored access policies apply to service SAS only. They are not supported for account SAS or user delegation SAS. A service SAS associated with a stored access policy can inherit permissions and time constraints from the server-side policy, which gives the administrator a way to change or revoke those constraints without rotating the storage account key.

That does not make every service SAS centrally tracked. Ad hoc SAS tokens remain client-generated, and Azure Storage does not maintain an inventory of every token that was issued. A secure design therefore needs both short lifetimes and a revocation strategy rather than assuming a portal page can enumerate and cancel any leaked SAS individually.

Stored access policies improve revocation options

A SAS created only with parameters inside the token is difficult to revoke individually before expiry without changing the key that signed it or using other service-specific controls.

A service SAS associated with a stored access policy can be affected by changing or removing that policy.

That gives the administrator a more manageable revocation point for groups of service SAS tokens tied to the policy.

The tradeoff is that stored access policies themselves require careful management and are only available for supported service resources.

Shared Key can be disabled.

Azure Storage supports disabling Shared Key authorization on supported accounts and scenarios.

That can force clients away from account-key-signed requests and toward Entra ID or supported user delegation SAS access.

This is a strong hardening step when the workloads have already been migrated to identity-based authorization.

Do not disable Shared Key blindly.

First inventory applications, scripts, legacy tools, and SAS generation patterns that may still rely on the account keys.

Choose the least-powerful credential that fits

A useful selection model is:

Microsoft Entra ID — best when a known identity can authenticate directly and Azure RBAC can express the required data access.

User delegation SAS — useful for temporary delegated blob access rooted in Entra identity.

Service SAS — useful for limited access to one storage service; can be associated with a stored access policy.

Account SAS — broader delegated account access; signed with Shared Key.

Account key / Shared Key — broad shared-secret access; use only when necessary and protect aggressively.

The correct choice depends on whether the caller can authenticate with Entra, how long access is required, and how narrow the permission can be.

Authorization and network reachability should be tested separately. A correctly signed request can still be rejected because the storage firewall, private endpoint design, or network perimeter does not allow the client path. Conversely, an allowed network path does not compensate for an expired SAS or a principal that lacks the correct data role.

For a 403 response, capture the authentication method first. Entra failures point toward token audience, identity, role, and scope. SAS failures point toward signature, permissions, time window, resource type, and stored access policy where applicable. Shared Key failures point toward the active key and whether Shared Key authorization is permitted on the account. Only after that should the investigation move to network restrictions and service-specific ACLs.

Troubleshoot authentication by identifying the credential path

When a storage request returns authorization errors:

1. Identify whether the client is using Entra ID, SAS, or Shared Key.
2. For Entra, verify the correct data-plane RBAC role and scope.
3. Check token audience and identity when using SDKs or CLI.
4. For SAS, inspect start/expiry time, permission letters, resource scope, and protocol.
5. Determine whether the SAS type is user delegation, service, or account.
6. For service SAS using a stored access policy, verify the policy still exists and permits the request.
7. For Shared Key, confirm the correct current account key is being used.
8. Check storage firewall and network rules after authorization is confirmed.

Choose the credential by minimizing standing privilege and operational blast radius. Prefer an Entra identity for long-lived workload access, use a tightly scoped SAS for delegated temporary access, and keep account keys for cases that genuinely require Shared Key. During troubleshooting, identify what signed the request before changing storage networking or regenerating secrets; the authentication path determines the evidence that matters.