Authentication and Authorization with Microsoft Entra ID

Authenticate and authorize users by using the Microsoft Identity platform

Authorization determines what an authenticated user or application can do. The Microsoft Identity Platform controls this through permissions, roles, and policies. Applications request delegated permissions when acting on behalf of a signed-in user, or application permissions when running without a user, such as background services. You configure these in the Azure portal, always following the principle of least privilege. Role-Based Access Control (RBAC) assigns permissions based on organizational roles like "Reader" or "Contributor", and you can use built-in or custom roles. The consent framework governs how users or administrators grant an application permission to access resources; high-risk permissions require admin consent. Conditional Access policies add security by requiring conditions like multifactor authentication (MFA) or trusted locations before granting access. Managed identities provide an automatically managed identity for Azure resources, eliminating the need to store credentials in code. System-assigned identities are tied to a specific resource, while user-assigned identities can be shared across services.

Authentication flows verify a user’s identity and obtain security tokens. The Microsoft Identity Platform supports standard OAuth 2.0 and OpenID Connect (OIDC) flows. The authorization code flow is the most secure and recommended for most apps, including single-page applications (SPAs) when combined with PKCE. The implicit grant flow is less secure and should be avoided. The client credentials flow is for server-to-server scenarios, like daemon apps. Security tokens include access tokens, ID tokens, and refresh tokens. Configure token lifetimes so access tokens are short-lived while refresh tokens can obtain new ones without user interaction. Always validate tokens on the resource server, never on the client side. Use the Microsoft Authentication Library (MSAL) instead of raw HTTP calls, as it handles token acquisition, caching, and renewal. For daemon apps, prefer certificate-based authentication over client secrets, and rotate credentials regularly. Design applications to handle authentication outages gracefully by using a backup authentication system and single sign-on (SSO) with rolling sessions.

MSAL simplifies acquiring, managing, and validating tokens. It uses a silent token acquisition pattern that checks its token cache before making network calls, reducing overhead and improving resilience. MSAL automatically handles token refreshing using long-lived tokens and exponential back-off retries. Tokens acquired via MSAL contain standard claims; applications should validate claims instead of making extra network calls. MSAL supports optional claims and app roles for fine-grained authorization. Avoid decoding access tokens on the client side; use ID tokens for user information instead. MSAL integrates with Azure services and supports broker authentication on mobile devices and Continuous Access Evaluation (CAE) for real-time token revocation.

Authenticate and authorize users and apps by using Microsoft Entra ID

Microsoft Entra ID is a cloud-based identity service where organizations store user, group, and application objects. Applications request tokens from a tenant endpoint to identify users or authorize access. Each application has its own application identity that securely requests tokens. Entra ID supports industry-standard protocols: OAuth 2.0 for access tokens, OpenID Connect (OIDC) for ID tokens, and SAML 2.0 for assertions. The Microsoft Authentication Libraries (MSAL) simplify token handling, caching, and single sign-on. When an app requests a token, Conditional Access evaluates signals like device health, user location, and risk. If policies pass, tokens are issued; otherwise access is blocked or MFA is required. To integrate an app, register it in the Microsoft Entra admin center by configuring redirect URIs, scopes, and credentials such as client secrets or certificates. Use managed identities for Azure resources to avoid storing secrets. Use system browsers or MSAL brokers, avoid embedded web views, and grant only necessary scopes and roles.

Permissions come in two types. Delegated permissions allow an app to act for a signed-in user, using scopes like User.Read. Application permissions allow an app to run without a user, using a static scope called .default. Application permissions always require admin consent because they can access data across the entire organization. Consent is the process where a user or administrator grants an app access. Users can consent to basic permissions, but an admin consent workflow is needed for sensitive data. Administrators can review and approve permissions before any user can access the app.

Conditional Access policies function as "if-then" statements. For example, if a user tries to access a sensitive app from an unmanaged device, the policy can require MFA. These policies rely on user risk, device compliance, and location signals. Microsoft Entra ID Protection uses machine learning to detect identity threats like suspicious sign-ins and leaked credentials, and can automatically block access or force a password reset. Developers integrate these features using MSAL, which handles conditional access requirements. Privileged Identity Management (PIM) provides just-in-time access for administrative roles, limiting powerful permissions to a specific task. Combined with Azure RBAC, this creates a Zero Trust environment.

Application permissions and Microsoft Graph scopes control what an application can access. Define them during app registration in the Microsoft Entra admin center. For Microsoft Graph, select API permissions that define operations like reading user data. When a user signs in, they are asked to consent. Higher-risk permissions require admin consent. The OAuth 2.0 protocol is used to request access tokens with specific scopes like Files.Read. Regularly review and audit permissions. For application permissions, use certificates instead of client secrets, and use MSAL to simplify flows.

Managed identities provide an automatically managed identity in Microsoft Entra ID. A system-assigned managed identity is tied to a single Azure resource and deleted with it, making it ideal for independent workloads. A user-assigned managed identity is a standalone resource that can be assigned to multiple services and has an independent lifecycle. The source resource requests an access token from Microsoft Entra ID, then presents it to a target service like Azure SQL or Storage, which uses Azure RBAC to authorize actions. Managed identities keep credentials out of code and are available at no extra cost.

Create and implement shared access signatures

A Shared Access Signature (SAS) is a signed URL that provides limited, delegated access to Azure Storage resources. Clients must always use HTTPS to distribute tokens. Grant only the minimum necessary permissions for the shortest duration. There are three main types: User Delegation SAS, Service SAS, and Account SAS. Microsoft recommends a User Delegation SAS for blob data because it is secured using Microsoft Entra ID credentials instead of storage account keys, reducing risk. Setting short expiration times, such as one hour or less, mitigates the risk of leaked tokens. For better control, use a stored access policy to manage service-level signatures. A stored access policy is defined on a container and can be modified or deleted to revoke all linked signatures instantly. Store storage account keys in Azure Key Vault and rotate them periodically. For maximum security, disable shared key authorization and force all clients to authenticate with Microsoft Entra ID.

A stored access policy acts as a server-side management layer for Service SAS. Policies are defined on containers like blob containers or queues. They allow you to centrally manage start times, expiration dates, and permissions. If a signature is compromised, you can change the policy's expiration to a past time, delete the policy, or rename it to invalidate all tokens. When a Service SAS is associated with a policy, it inherits all constraints. Only five stored access policies are allowed per container, so use them for long-term access needs. Stored access policies are only supported for Service SAS, not Account or User Delegation SAS.

You can generate a Service SAS or Account SAS using Azure SDKs or tools. A Service SAS delegates access to a single storage service like Blob Storage or Queue Storage. An Account SAS can delegate access to multiple services and supports service-level operations. Microsoft recommends using a User Delegation SAS whenever possible because it uses Entra ID credentials. When constructing a SAS, specify resource types, permissions (read, write, delete), IP address restrictions, HTTPS-only protocol, and a short expiration. For Service SAS, use a stored access policy to manage revocation. For other types, rely on near-term expiration.

Understanding the types is essential. An Account SAS is signed with the storage account key and applies across blob, queue, table, and file services. It is less restrictive and best for broad management tasks. A Service SAS is scoped to a specific resource like a container or queue, providing granular access. A User Delegation SAS is signed with Entra ID credentials and applies only to Blob Storage. It can be revoked by removing the user's role assignment, making it the recommended type for security-critical scenarios.

To enhance security, enforce HTTPS-only communication and restrict access to specific IP address ranges. Use short validity periods. Avoid Shared Key authorization; rely on Azure RBAC with managed identities. Protect storage account keys in Azure Key Vault and rotate them regularly. Use firewalls, virtual networks, and private endpoints to restrict network access. Disable public access when not needed. Continuously monitor access patterns using Azure Storage logs and Azure Monitor.

Implement solutions that interact with Microsoft Graph

To interact with Microsoft Graph, register your application in Microsoft Entra ID. This gives the app an Application (Client) ID. The app needs permissions: delegated permissions let it act on behalf of a signed-in user, while application permissions allow it to run as its own identity. Always request the least privilege. Consent is the process where users or administrators grant access. Users can consent to simple requests; admin consent is required for high-level permissions. The admin consent workflow allows users to request access through the portal. Use credentials like client secrets or certificates; for highest security, use managed identities and store secrets in Azure Key Vault.

Microsoft Graph is the unified gateway to data across Microsoft 365 services like Outlook, Teams, and SharePoint. The single endpoint https://graph.microsoft.com supports CRUD operations—Create, Read, Update, Delete—on resources such as users, groups, and files. Use OData query parameters like $filter, $select, and $expand to retrieve only the data you need, reducing network overhead. Authenticate and authorize using MSAL and the principle of least privilege.

Optimize performance with request batching to combine multiple API calls into one HTTP request, reducing round trips. Delta queries track incremental changes using a special token called a delta link, so you only fetch what changed. Pagination breaks large datasets into smaller pages; the response includes a nextLink to get the next set of results. These features work securely with MSAL and managed identities.

Construct queries using HTTP methods like GET, POST, PATCH, DELETE. Include authentication tokens. Use $filter, $select, $orderby to narrow results. Secure access using OAuth 2.0 and OpenID Connect with MSAL. For background services, use the client credentials grant. Popular operations include retrieving a user’s profile (GET /v1.0/me), accessing emails, or filtering high-importance messages. For large datasets, use pagination with $top and $skip. Advanced scenarios include delta queries and webhooks for real-time notifications.

When automating Microsoft Graph operations, register an app and choose interactive or automated mode. In automated mode, use the OAuth 2.0 client credentials grant. Grant permissions in the Azure portal under API permissions: select Microsoft Graph, then Application permissions, and choose rights like User.ReadWrite.All or Group.ReadWrite.All. After adding permissions, grant admin consent. Your app needs a client secret or certificate; store them securely using Azure Key Vault or managed identities. If updating user passwords, assign the User Administrator role. Follow best practices: use OAuth 2.0 flows, leverage MSAL, request least privilege, and rotate secrets regularly. For a smooth user experience, attempt silent token acquisition first and implement incremental consent when new scopes are needed.