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.
StudyCerts
StudyCerts