You can develop, but can you develop for the cloud? Harness your development skills and learn how to create robust solutions for Microsoft Azure, aiming for your Microsoft Certified: Azure Developer Associate certification!
Gauge your current knowledge
Gauge your current knowledge
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 on behalf of users, which centralizes identity management and ensures consistent security across all services.
Microsoft Entra ID supports industry-standard protocols to authenticate and authorize access. OAuth 2.0 is an authorization framework that obtains access tokens, while OpenID Connect (OIDC) adds an authentication layer on top of OAuth 2.0 for handling ID tokens. SAML 2.0 is another authentication standard that uses SAML assertions. Applications choose the best flow based on whether they need to sign in users or secure APIs.
The Microsoft Authentication Libraries (MSAL) simplify token handling and policy checks by managing token caching, renewal, and Single Sign-On (SSO). When an app requests a token, Conditional Access evaluates conditions like device health, user location, and risk signals. If policies pass, tokens are issued; otherwise, access is blocked or multi-factor authentication (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. For automated credentials, use managed identities for Azure resources so Azure issues tokens without storing secrets. Use system browsers or MSAL brokers to minimize sign-in prompts, avoid embedded web views to prevent credential exposure, and grant only necessary scopes and roles to enforce least privilege.
In Microsoft Entra ID, managing how apps access data is done through permissions. There are two main types: delegated permissions, which allow an app to act for a signed-in user, and application permissions, which allow an app to run on its own without a user present. Choosing the right type ensures that an application follows the principle of least privilege, meaning the app only gets the access it truly needs to function.
Delegated permissions are used when a user is signed into the application. The app acts as a delegate for the user to perform actions like reading email or accessing files. These permissions use scopes to define specific tasks such as User.Read or Files.Read. The user must usually provide consent before the app can access their information.
Application permissions are designed for apps that run in the background without a user present, often called workloads. These apps use a static scope called .default to request all permissions assigned during registration. Because these apps can access sensitive data across the entire organization, they always require a high level of approval to ensure background services do not have unmonitored access to private resources.
Consent is the process where a user or administrator grants an application the right to access protected resources. While users can often consent to basic permissions, an admin consent workflow is necessary for more sensitive data. Administrators can review and approve permissions before any user in the organization can access the application.
Microsoft Entra ID manages how users and applications access organizational resources. Modern security has moved beyond simple passwords to Conditional Access, which evaluates multiple signals before granting entry. These signals include the user's identity, their specific network location, and the security state of their device. By checking these conditions in real-time, Azure ensures that access is only granted under safe and approved circumstances.
Conditional Access policies function as "if-then" statements that help secure cloud applications. For example, if a user attempts to access a sensitive app from an unmanaged device, then the policy can automatically require MFA. Organizations design these policies based on user risk (the probability that a user's account has been stolen), device compliance (whether a device meets security standards managed by Microsoft Intune), and location signals (the specific IP address or geographic region where the user is located).
Microsoft Entra ID Protection uses machine learning to detect and respond to identity-based threats. It identifies sign-in risk by looking for suspicious login patterns and user risk by flagging accounts that may have leaked credentials. Administrators can configure these tools to automatically block access or force a password reset when high risk is detected, which helps stop attackers before they can move through a network.
Developers integrate these security features into their apps using MSAL. MSAL simplifies requesting tokens and ensures that all Conditional Access requirements are met before the app receives data. When an application is built with MSAL, it can handle complex security challenges like prompting for MFA without the developer needing to write custom security code.
Organizations also use Privileged Identity Management (PIM) to manage high-level administrative roles. PIM provides just-in-time access, meaning users only receive powerful permissions for a limited time to complete a specific task. This combines with Azure Role-Based Access Control (RBAC), which defines exactly what a user can do within a resource. Using these tools together creates a Zero Trust environment where every identity is continuously verified and monitored.
Application permissions and Microsoft Graph scopes control what resources an application can access in Microsoft Entra ID and the Microsoft Graph API. Delegated permissions allow an app to act on behalf of a signed-in user, while application permissions allow the app to act on its own without a user. The principle of least privilege is key here—only grant the permissions absolutely necessary for the app to function.
To manage these permissions, define them during app registration in the Microsoft Entra admin center. For Microsoft Graph, select specific API permissions, which are essentially scopes that define the operations the app can perform, such as reading user data or managing groups. When a user signs in, they are asked to consent to these permissions, allowing the app to access requested resources on their behalf. For higher-risk permissions, admin consent may be required to ensure security and compliance.
The OAuth 2.0 protocol is the industry standard used for authorization. When an application needs to access a protected resource like Microsoft Graph, it requests an access token from Microsoft Entra ID. This request includes the scopes parameter, which specifies the exact permissions needed—for example, Files.Read to read a user's files or User.Read.All to read all user profiles. Microsoft Entra ID then issues a token valid only for those specific scopes, ensuring the app cannot perform unauthorized actions.
For permissions with broader impact, admin consent is required. A tenant administrator must explicitly grant permissions to the application before any user can use it. Conditional Access policies can add an extra layer of security by enforcing rules like requiring MFA or ensuring access only comes from a compliant device before granting a token.
When managing permissions, regularly review and audit the permissions granted to applications and remove any that are no longer needed. For application permissions, consider using certificates instead of client secrets for authentication, as they are more secure. Using MSAL is highly recommended because it simplifies implementing authentication flows, handles token caching and renewal, and supports advanced features like Conditional Access and token protection.
Managed identities provide an automatically managed identity in Microsoft Entra ID for Azure resources. They allow services to connect to other resources without the developer needing to manage or rotate credentials like passwords or keys. This approach follows the Zero Trust model by shifting to a secret-less authentication method that reduces the risk of credential theft.
A system-assigned managed identity is created directly on a specific Azure resource and has a one-to-one relationship with it. This identity is tied to the lifecycle of the resource, meaning it is automatically deleted when the resource is removed. It is the best choice for independent workloads that run on a single resource, such as a specific virtual machine or an Azure Function.
A user-assigned managed identity is created as a standalone Azure resource that can be assigned to one or more services. Unlike system-assigned types, its lifecycle is independent of the resources it is assigned to, requiring manual deletion. This type is ideal for architectural requirements where multiple resources need to share the same identity and permissions.
The process of using these identities involves a source system requesting an access token from Microsoft Entra ID. Once the token is obtained, it is presented to a target system such as Azure SQL or Storage for authentication. The target system then uses Azure RBAC to authorize the specific actions the identity is allowed to perform.
Utilizing managed identities significantly enhances security by ensuring that sensitive credentials never appear in code or environment variables. Azure handles all rotation and protection of identity secrets. User-assigned identities allow for consistent permissions across large sets of resources, and managed identities use regional endpoints to help prevent failures during token acquisition. These identities are available at no extra cost and support a wide range of Azure services.
StudyCerts
StudyCerts