Are you a guardian of your domain? Lean how to leverage your aptitude in security to protect Microsoft Azure technologies, with a goal of earning the Microsoft Certified: Azure Security Engineer Associate certification!
Gauge your current knowledge
Gauge your current knowledge
Enterprise applications in Microsoft Entra ID use OAuth permission grants to control how apps access protected data. There are two main types of permissions that serve different authorization purposes. Delegated permissions allow an application to act on behalf of a signed-in user, meaning the application can only access resources that the user themselves has permission to see. In contrast, application permissions let an application run with its own identity without any signed-in user context, which is the standard choice for background services or automated tasks. Delegated permissions can be approved by either users or administrators depending on the scope risk, while application permissions always require an administrator to grant consent.
Administrators control the authorization flow across the tenant through several consent settings that establish clear security boundaries. User consent settings determine whether regular users can approve permissions for themselves or if every permission request must route through an approval chain. To balance security with user productivity, administrators can configure an admin consent workflow that routes pending permission requests directly to designated approvers. For organization-wide deployments, administrators can grant tenant-wide admin consent, which approves an application's access for all users at once. This action carries significant risk because it opens up data access tenant-wide, so it must be heavily restricted and monitored.
Organizations must regularly audit which permissions have been granted to detect over-privileged applications. Azure AD activity logs record all consent events and permission grants, tracking exactly who approved a permission and when the change occurred. For programmatic auditing, administrators query the Microsoft Graph API using the oauth2PermissionGrants endpoint to review active delegated permissions, and the appRoleAssignments endpoint to check application permissions. These logs reveal which applications hold access to specific data scopes, allowing administrators to find and flag permissions that no longer serve a business purpose.
When an application no longer requires access, administrators can revoke consent to block the application from calling APIs. To remove a delegated permission grant, administrators use the Microsoft Entra admin center or send a DELETE /oauth2PermissionGrants/{grant-id} request through the Microsoft Graph API. To remove an application permission, they call DELETE /servicePrincipals/{id}/appRoleAssignedTo/{assignment-id}. Once the deletion completes, the application can no longer obtain access tokens for that scope. However, if dynamic consent is still allowed, the application might prompt the user to consent again upon the next login, meaning administrators must also lock down tenant-wide consent settings to prevent re-consent.
A secure application environment requires ongoing enforcement of a least-privilege security model. Organizations should implement permission grant policies that restrict which API scopes users are allowed to approve on their own, automatically blocking high-risk requests. Administrators can also set up access reviews to periodically validate whether active permissions are still necessary. These reviews work alongside Conditional Access policies to provide continuous monitoring and ensure that only verified applications can access corporate resources.
To establish an identity for a custom application, developers must create an app registration within the Microsoft Entra admin center. During this initial setup, developers define the application name, configure a redirect URI to securely receive authentication tokens, and choose the supported account types. Selecting the correct account type defines the trust boundary and determines who can sign in:
After the app registration is created, developers can define application roles within the registration settings to enforce role-based access control (RBAC) inside the application code.
To access secured data resources, applications request tokens using OAuth 2.0 and OpenID Connect protocols. The app registration lists the specific API permissions the application needs to run, which are categorized into delegated permissions or application permissions. To secure these inbound identity requests, developers should use certificate-based authentication instead of relying on simple client secrets. Under this trust model, the application securely stores the private key, while the corresponding public key is uploaded directly to the app registration to verify the identity of the application.
Administrators protect application resources by applying Conditional Access policies to the sign-in flow. These policies evaluate active signals, such as user risk levels, device compliance, and geographic location, before Microsoft Entra ID will issue an access token. If a sign-in request fails to satisfy the policy requirements, the login attempt is blocked or the user is prompted for multi-factor authentication. Additionally, administrators can enforce security boundaries by requiring admin consent for high-risk API permissions, preventing regular users from accidentally authorizing malicious software to access sensitive data.
In Microsoft Entra ID, OAuth2 permission scopes and app roles enable fine-grained authorization for both user-delegated and application-level access. OAuth2 scopes represent specific API access rights that apps request on behalf of users, while app roles define role-based access control within an application and appear as roles claims in tokens. To declare these scopes and roles, developers edit the app registration manifest or use the Azure portal settings. In the manifest, scopes are configured under the requiredResourceAccess property, while roles are declared within the appRoles array. In the portal interface, developers use the Expose an API blade to add custom scopes and the App roles blade to create roles with assigned member types like Users, Applications, or both.
Once scopes and roles are defined, administrators manage consent using the Microsoft Entra admin center under Enterprise apps > Permissions, the Microsoft Graph API, or PowerShell. To programmatically grant or revoke these assignments, administrators use the OAuth2PermissionGrant and AppRoleAssignment endpoints in Microsoft Graph, or call PowerShell cmdlets such as Get-EntraServicePrincipalAppRoleAssignment and Remove-EntraOAuth2PermissionGrant. When revoking excess permissions, administrators must clean up any static consent entries in both the app registration and the enterprise application to prevent authorization bypasses. Finally, to verify that access controls are working correctly, security teams can decode and inspect the access token or ID token JSON Web Token (JWT) to ensure the scope and roles claims exactly match the intended design.
Least-privilege access requires giving applications and users only the minimum permissions necessary to perform their jobs. When an application requests access to corporate resources, security teams must assess whether the requested scopes are strictly required for the application's functionality. Reviewing these scopes prevents over-privileged access and limits the potential blast radius if the application's credentials are ever compromised.
Administrators regulate the consent process by configuring user and admin consent policies through the portal or Microsoft Graph. These policies act as a gatekeeper, allowing admins to block all user consent entirely and require admin consent for every application. Alternatively, policies can be customized to allow users to consent only to low-risk permissions or to applications developed by verified publishers.
Security operations require continuous monitoring of active permissions to detect unauthorized access. Administrators use Azure AD sign-in logs and entitlement management reports to audit historic consent grants and identify who approved each permission. If an administrator detects an unauthorized or suspicious consent grant, they can immediately revoke the permission to cut off the application's access to the tenant.
Service principals function as the local representation of an application identity within a specific Microsoft Entra directory. To authenticate non-interactively with Azure resources, service principals support three different credential types:
Choosing the right credential type directly impacts the overall security posture and dictates how easily credential management can be automated.
Implementing certificate-based authentication reduces the risk of credential leakage because no raw secret strings are transmitted over the network. For temporary testing, developers can use self-signed certificates or client secrets, but these should be replaced with production-grade certificates in live environments. Administrators should configure automated credential rotation using Azure Key Vault, Azure Automation, or application lifecycle policies. This automation ensures that credentials are rotated on a regular schedule, minimizing the usability window of any compromised credential.
Administrators assign Azure RBAC roles to service principals to grant them permission to manage Azure resources. To adhere to the principle of least privilege, these role assignments must be scoped to the narrowest boundary possible, such as a single resource, a resource group, or an entire subscription. Security teams should use built-in roles for standard tasks or build custom roles for highly specific access requirements. Regularly reviewing these active role assignments helps identify and remove unneeded permissions to maintain a minimized attack surface.
Wherever possible, organizations should migrate to managed identities for Azure resources to eliminate manual credential management entirely. A system-assigned managed identity is tied directly to a single Azure resource lifecycle, whereas a user-assigned managed identity is created as a standalone resource and can be shared across multiple Azure resources. Because Azure automatically handles the creation, distribution, and rotation of the underlying credentials, managed identities simplify operations and remove the risk of credential exposure.
Managed identities allow Azure resources to authenticate securely without storing credentials in application code. A system-assigned managed identity is tied directly to the lifecycle of a single Azure resource, meaning Microsoft Entra ID automatically deletes the identity when the resource is deleted. A user-assigned managed identity exists as an independent Azure resource that must be manually deleted when it is no longer needed, allowing it to be shared across multiple virtual machines or services.
When an application runs on an Azure resource with an enabled managed identity, the application requests an access token from the local Microsoft Entra ID token endpoint. The token endpoint returns the requested token over a secure, private network channel, preventing credential exposure to the public internet. Once the application receives the token, it presents it to target Azure services to authenticate. Authorization is then evaluated at two distinct boundaries: the control plane, which uses Azure RBAC via Azure Resource Manager, and the data plane, which relies on service-specific access control lists.
Administrators manage these identities as service principal objects within the Enterprise applications portal or by using the Microsoft Graph API. To verify that managed identities maintain a strong security posture, security teams must audit their permissions and ensure they are not added to highly privileged groups. For ongoing security operations, administrators use Azure Activity logs and Sign-in logs to track token requests and analyze which identities have accessed specific resources.