Skip to main content
Microsoft Entra ID (formerly Azure AD) is the recommended, secure method to authenticate to Azure Storage (Blobs, Queues, Tables). It replaces sharing storage account keys or long-lived SAS tokens, which can be leaked via logs or source control and grant broad access if exposed. Entra ID enables stronger controls such as multi-factor authentication (MFA) and Conditional Access policies (for example, restricting access to specific networks or countries). Entra ID provides authentication (proving the identity). Authorization to storage data is managed separately with storage-specific RBAC roles (for example, Storage Blob Data Owner, Storage Blob Data Contributor, Storage Blob Data Reader, Queue Data Contributor). These roles can be assigned at subscription, resource group, or storage account scope — access is inherited from the assigned scope.

​
Authentication + Authorization workflow

  1. A user or service principal proves identity to Entra ID (interactive sign-in or a token request). Entra ID authenticates the identity and issues a bearer token.
  2. The client presents the bearer token to the Azure Storage REST API.
  3. Storage validates the token and evaluates storage RBAC to determine whether the caller is authorized for the requested resource.
  4. If authorized, Storage returns the requested object or data.
Below is a practical example using a service principal (app registration) and client secret to authenticate, obtain a token, and access a blob.

​
1. Create an app registration (service principal) and client secret

  1. In Microsoft Entra ID, create a new app registration (single-tenant), e.g., “Storage SPN”.
  2. Copy the Application (client) ID and the Tenant ID.
  3. Create a client secret and save its value immediately — it is shown only once.
A screenshot of the Microsoft Azure portal showing the App registrations "storage-spn" overview page, with the left navigation menu and the Essentials (application/client ID, object ID, tenant ID) details in the center. The top shows the Azure header and a search bar, and the page includes links for certificates, secrets, and API permissions.
When you create a client secret, copy the secret value immediately — it is visible only at creation. Store it securely (secrets vault, Key Vault, or a secure password manager).
A screenshot of the Microsoft Azure portal showing the "storage-spn" App registration's Certificates & secrets page, with the left-hand navigation menu visible. A client secret is listed (partially visible) and appears to have been copied.
Also note the OAuth endpoints and Tenant ID presented on the app registration or Entra ID overview. Example endpoints (tenant ID shown as an example):

​
2. Assign a storage-specific RBAC role to the service principal

  1. Open the Storage account you want the service principal to access.
  2. Go to Access Control (IAM) → Add role assignment.
  3. Choose the appropriate storage data role (least privilege principle). For read-only blob access, select “Storage Blob Data Reader”.
A screenshot of the Microsoft Azure portal showing the Storage accounts page with the storage account "cnstsec009" selected and its overview/details (essentials, properties, and security) visible. The left pane lists other storage accounts and navigation options like Containers, Access Control (IAM), and Activity log.
Search for and select the role “Storage Blob Data Reader” (or another role suited to your scenario), then click Next to choose members.
Screenshot of the Microsoft Azure "Add role assignment" (Access Control IAM) page showing job function roles filtered for "Storage Blob Data", with entries like "Storage Blob Data Reader", "Contributor" and "Owner" listed and the Reader role highlighted.
Search for the service principal by name (for example, “Storage SPN”), select it, and complete the assignment.
A screenshot of the Microsoft Azure portal on the "Add role assignment" page, showing the Members tab where the "Storage Blob Data Reader" role is being assigned. The right-hand pane displays a "Select members" list for choosing user accounts.

​
Common storage data roles

Always assign the least privileged storage role required for the task. Do not give owner-level data permissions unless necessary.

​
3. Request a token using the client credentials flow

Use the service principal (client ID), client secret, and the tenant token endpoint to request an access token for the Azure Storage resource. For the v1 endpoint you may see examples that use the resource parameter. For v2 endpoints and modern apps, use the scope https://storage.azure.com/.default with the /oauth2/v2.0/token path. Example POST (v1 style, application/x-www-form-urlencoded):
Example (truncated) JSON response:
Notes:
  • For v2.0 token endpoints, POST to /oauth2/v2.0/token and use scope=https://storage.azure.com/.default.
  • The client credentials flow does not return refresh tokens. When the access token expires, request a new token using the same client credentials flow.

​
4. Access a blob with the bearer token

First, you can test an unauthenticated GET to confirm the blob is private (or to validate public blob access):
If the blob is private and you do not provide SAS or Authorization, the response will indicate the resource is not accessible. Example error:
Next, issue the same GET with the required headers including x-ms-version and the Authorization: Bearer <access_token> header:
If the bearer token is valid and the service principal has the appropriate storage RBAC role (for example, Storage Blob Data Reader), the request succeeds and the blob content is returned. When the token expires, request a new access token using the same client credentials flow.
A slide titled "Microsoft Entra ID Authentication" showing a flow where a Storage Blob Data Contributor posts a login to Azure Entra/AD and receives a bearer token. The token is then used with the Storage API to access a Storage Blob Container; the slide also notes "Secure way of authenticating" and "Requires dedicated RBAC roles."

​
Summary

  • Use Microsoft Entra ID for stronger authentication and to enable Conditional Access and MFA.
  • Entra ID handles authentication (who you are); storage-specific RBAC grants authorization to storage data.
  • Service principals (app registrations) with client credentials are a common pattern for non-interactive service-to-service access.
  • Follow the least privilege principle — assign the minimum storage data role required for the workload.
This concludes the Administer Azure Storage section of this lesson.

Watch Video