Microsoft AZ-204: Azure Authentication, Authorization and Security — Study Guide

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Part of the Microsoft Azure Developer Associate AZ-204 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure authentication and authorization hinge on the Microsoft Identity Platform, which issues tokens to identities (users, apps, workloads) and enforces access to APIs and resources. Applications integrate through OAuth 2.0 and OpenID Connect, acquire tokens using MSAL, and request permissions declared in Azure AD app registrations. Workloads running on Azure can eliminate credentials entirely using managed identities and rely on Azure RBAC to reach services like Key Vault, Storage, and Microsoft Graph. Secrets management centers on Azure Key Vault, with clear separation between vault data-plane access and management-plane control, and with strong recovery guarantees through soft delete and purge protection. For storage, Shared Access Signatures (SAS) provide scoped, time-limited delegation to clients without exposing account keys.

Microsoft Identity Platform, OAuth 2.0, MSAL, and App Registrations

The Microsoft Identity Platform supports multiple OAuth 2.0 flows optimized for different application types:

• Authorization code flow: The standard for web apps, SPAs, and native apps. Public clients must use PKCE to protect the authorization code. Apps redirect users to the authorize endpoint, receive an authorization code on the redirect URI, then redeem it at the token endpoint for an access token (and optionally a refresh token). For SPAs, authorization code + PKCE replaces the legacy implicit flow and mitigates token leakage.
• Client credentials flow: Used by daemons and server-to-server services without a user. The application requests tokens using a client assertion (certificate) or a client secret. Only application permissions (app roles) are available here, and most of them require admin consent. This flow uses the /.default scope to request the set of statically configured application permissions.
• Device code flow: Designed for devices or environments without an embedded browser. The app obtains a user code and verification URL from the identity platform, the user authenticates on a separate device, and the app polls the token endpoint. Delegated permissions apply because a user signs in.
• Implicit grant flow: Historically used by SPAs to receive tokens directly from the authorize endpoint. It is now discouraged in favor of authorization code with PKCE. If used, a redirect URI is still required during app registration.

MSAL (Microsoft Authentication Library) provides consistent token acquisition across languages and platforms. Public client applications (desktop, mobile, SPA) use AcquireTokenInteractive and AcquireTokenSilent to obtain and cache tokens; native apps will also use AcquireTokenByDeviceCode for device code flow and AcquireTokenByAuthorizationCode for authorization code redemption in confidential client contexts. Confidential clients (web apps/APIs/daemons) acquire tokens with AcquireTokenForClient when using client credentials and AcquireTokenOnBehalfOf for OBO scenarios where an API calls downstream APIs with a user’s delegated context.

Token caching is integral to MSAL: it stores access and refresh tokens keyed by account, client, and scope, enabling AcquireTokenSilent to avoid unnecessary interactive prompts. Web apps and APIs running in multiple instances must persist and protect the token cache using a shared, encrypted store (e.g., distributed cache with proper encryption at rest and in transit). Cache serialization hooks in MSAL enable secure persistence. Scopes identify the permissions an app is requesting. For delegated permissions, request the minimal, resource-specific scopes (e.g., https://graph.microsoft.com/User.Read). For client credentials, request resource-based /.default, which maps to the application permissions statically granted to the app (e.g., scope = https://graph.microsoft.com/.default). Use incremental consent to request scopes progressively and reduce friction.

Azure AD app registrations define application identity, credentials, redirect URIs, and permissions. Delegated permissions require a signed-in user and can often be consented by users themselves for their data; application permissions are granted to the app itself and almost always require an admin to consent because they apply tenant-wide or broadly. Apps that expose APIs declare scopes (for delegated permissions) and app roles (for application permissions) under “Expose an API.” Configure single-tenant or multi-tenant access depending on trust boundaries, and use certificates over client secrets for stronger credentials and easier rotation.

Microsoft Graph uses the same token issuance. Authenticate with MSAL targeting the Graph resource and request least-privilege scopes. Common endpoints include:

• GET https://graph.microsoft.com/v1.0/me for user profile with delegated tokens (e.g., User.Read)
• GET https://graph.microsoft.com/v1.0/users and /groups for directory objects (requires appropriate delegated or application permissions such as User.Read.All or Group.Read.All)
• GET https://graph.microsoft.com/v1.0/sites or /drives for SharePoint/OneDrive operations When using client credentials, request the /.default scope and ensure admin consent exists for the required application permissions. Choose the right authority (tenant-specific versus common/organizations) to control where users can sign in and where tokens can be minted.

Managed Identities and Secure Access to Azure Resources, plus Key Vault References

Managed identities for Azure resources eliminate secrets by allowing Azure to manage service principal credentials. System-assigned managed identities are tied 1:1 with a resource (App Service, Function App, VM, VMSS, Logic App, etc.) and share its lifecycle; when the resource is deleted, the identity is also deleted. User-assigned managed identities are created as standalone Azure resources that can be attached to multiple compute resources and exist independently of any one workload’s lifecycle. This model supports identity reuse and separation of duties.

To access Azure resources with a managed identity, grant it the appropriate Azure RBAC role at the correct scope:

• For Azure Storage data plane with Azure AD, assign roles like Storage Blob Data Reader/Contributor on a storage account, container, or RG/subscription scope.
• For Key Vault (RBAC data-plane model), assign roles such as Key Vault Secrets User or Key Vault Crypto Officer.
• For Microsoft Graph via application permissions, managed identities can call downstream APIs only after an app registration is associated. Use workload identity federation or configure the enterprise app permissions and admin consent as needed.

At runtime, use the Instance Metadata Service (IMDS) on VMs or the App Service-managed endpoint to obtain tokens; SDKs like Azure Identity’s DefaultAzureCredential will automatically use the managed identity endpoint when available. This removes the need to store secrets and supports rotation by the platform.

Key Vault references in App Service and Azure Functions allow secure retrieval of secrets into application settings without code changes. In an app setting value, use the reference syntax @Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{name}/{version}). The platform resolves the reference using the app’s managed identity at startup and periodically refreshes it. Ensure the managed identity has Get permission for secrets via Key Vault access policies or the Key Vault Secrets User role when using the RBAC data-plane model. Key Vault references are ideal for configuration values that should never be stored in plain text within the app configuration store and remove secret-handling logic from application code.

Azure Key Vault: Secrets, Keys, Certificates, and Access Control

Azure Key Vault stores three object types:

• Secrets: Opaque strings such as passwords, connection strings, or API keys. Versioned; clients typically perform Get and Set operations.
• Keys: Cryptographic keys (RSA, EC) used for sign/verify, encrypt/decrypt, and wrap/unwrap operations. The key material is protected by the HSM-backed service; clients call crypto operations through the service rather than exporting private key material.
• Certificates: X.509 objects with lifecycle management, optionally integrated with partner CAs. Certificates are materialized as a certificate plus a corresponding secret (PFX) and, optionally, a managed key.

Soft delete is on by default, preserving deleted objects for a retention window. Enable purge protection to prevent irreversible deletion within the retention period and to enforce recovery guarantees (often a 90-day retention requirement). Combine soft delete and purge protection to meet strict recovery policies. In addition, secure vault network access with private endpoints and disable public network access where possible.

Access control can use the legacy vault access policies or Azure RBAC for the data plane. Access policies are configured per-vault and explicitly grant permissions (Get, List, Set, Sign, Wrap) to principals; they are not inherited and can become operationally heavy at scale. The RBAC data-plane model uses Azure roles (e.g., Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) and supports scoping at subscription, resource group, or vault level with auditing integrated into Azure RBAC. Choose one model; if RBAC is enabled for the data plane, access policies are ignored. Management-plane operations (creating/updating the vault) always use Azure RBAC.

Integrate Key Vault with applications using Azure SDKs (e.g., SecretClient, KeyClient, CertificateClient) and DefaultAzureCredential. Prefer managed identities for authentication, avoid embedding credentials, and implement retry and throttling policies when calling Vault APIs.

Azure Storage SAS and Stored Access Policies

Shared Access Signatures delegate fine-grained, time-limited access to Azure Storage without revealing account keys:

• User Delegation SAS (Blob only): Backed by Azure AD. The app obtains a user delegation key from the Blob service using Azure AD credentials, then creates SAS tokens for clients. This is the most secure approach for user-centric scenarios because it avoids using account keys and aligns with role-based authorization.
• Service SAS: Scoped to a specific resource (blob, container, queue message, table entity, file). Signed with an account key. Supports permissions like read, write, add, create, delete, list, set immutability, and tags depending on service.
• Account SAS: Broadest scope over multiple services (Blob, Queue, Table, File) and resource types. Use sparingly due to wide blast radius.

SAS tokens include constraints such as expiry time (se), start time (st), permissions (sp), IP ranges (sip), allowed protocols (spr), signed resource (sr), and, when bound to a stored access policy, a signed identifier (si). Follow least privilege by granting only the necessary permissions, keeping expirations short, and enforcing HTTPS (spr=https). Prefer user delegation SAS where possible; otherwise, use service SAS with a stored access policy for revocation.

Stored access policies live on containers, file shares, queues, or tables and define a reusable set of constraints (permissions, start, expiry). When creating a SAS, reference the policy by its identifier. This enables central revocation or scope tightening without having to reissue all SAS tokens; updating or deleting the policy immediately affects all SAS tokens linked to it. Rotate account keys regularly if service or account SAS are used, and monitor usage through diagnostic settings and Azure Monitor logs.

Practical Problem Scenario

Adobe is rolling out a multi-tenant media processing portal on Azure. Customers sign in with their own Microsoft Entra ID tenants, upload large media files directly to Blob storage, and track processing status. The solution must avoid storing secrets, centralize permissions, and ensure recoverability of secrets for at least 90 days.

1. Register applications in Microsoft Entra ID:

   • Create a SPA for the portal UI and a confidential client for the backend API. Expose API scopes for delegated access and define app roles for background jobs. Configure SPA to use authorization code + PKCE with exact redirect URIs. This aligns each client with the correct OAuth flow and enforces least-privilege consent boundaries.

2. Implement MSAL in the SPA and backend:

   • The SPA acquires tokens for the backend API using AcquireTokenInteractive/AcquireTokenSilent with incremental consent. The backend uses AcquireTokenOnBehalfOf to call Microsoft Graph to read the signed-in user’s basic profile. This preserves user context end-to-end and minimizes prompts via token caching.

3. Enable system-assigned managed identities on App Service (API) and Azure Functions (media processors):

   • Assign Storage Blob Data Contributor on the media container and Key Vault Secrets User on the vault. Managed identities remove secret sprawl and allow the platform to rotate credentials automatically while enabling secure access to Storage and Key Vault via Azure RBAC.

4. Configure Azure Key Vault with RBAC data-plane, soft delete, and purge protection:

   • Store signing certificates for backend assertion, third-party API keys, and any connection secrets that cannot be replaced with AAD. Enforce purge protection plus soft delete to guarantee recovery for 90 days. RBAC simplifies audit and scales across environments compared to per-vault access policies.

5. Use Key Vault references for configuration:

   • Reference secrets in App Service and Functions app settings using @Microsoft.KeyVault(SecretUri=…). The platform resolves and refreshes values with the managed identity, eliminating code changes and preventing secrets from being stored in plaintext configuration.

6. Delegate direct browser uploads with SAS:

   • The backend issues user delegation SAS tokens for short-lived, write-only access to a specific blob path, scoped by IP and HTTPS. For operational batch tools, create service SAS tied to a stored access policy on the container so tokens can be revoked centrally by updating or deleting the policy. This enables high-throughput client uploads without exposing account keys and supports emergency revocation.

7. Integrate Microsoft Graph minimally:

   • Request https://graph.microsoft.com/User.Read in the SPA for profile display and use https://graph.microsoft.com/.default in the backend if any application permissions are required (with prior admin consent). Using /.default ensures the backend honors centrally granted application permissions and avoids over-requesting scopes at runtime.

This design uses authorization code + PKCE to secure the SPA, OBO to preserve user context downstream, managed identities and RBAC to eliminate secrets, Key Vault with strong recovery guarantees, Key Vault references for configuration hygiene, Graph with least-privilege scopes, and SAS with stored access policies for safe, revocable client uploads.

← Azure Container Solutions · All domains · Azure API Management →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →