Permissions & Scopes

Application Permissions & Scopes

Understanding and managing application permissions is critical for security and functionality. AZExecute provides comprehensive tools to view, manage, and govern API permissions, exposed scopes, and application roles for your Entra ID applications.

To create or change app roles, delegated scopes, identifier URIs, and pre-authorized clients, see Application Registration Configuration. Permission grants and consent remain governed separately.

Choose the Right View

Start with the application that needs access (the client), or the application exposing the API (the resource). For example, Compass requesting AtlasAPI's api_access scope is an outgoing permission for Compass and incoming access for AtlasAPI.

The tabs use task-oriented names: APIs used was previously Permissions, and Access to this app is the Grant Report. App roles, API scopes, and User & admin consent retain the same capabilities. Older screenshots below may show the previous labels. The permission rules, approval checks, and grant/revoke behavior are unchanged.

Roles & Access sub-tab	What it answers
App roles	Which app roles does this application expose, and who is assigned?
APIs used	Which APIs and permissions does this client have configured, and which are granted?
API scopes	Which delegated scopes does this API expose, and which clients are pre-authorized?
Access to this app	Which clients, users, or groups have access to this API, and which configured clients still need admin consent?
User & admin consent	Which user and tenant-wide delegated grants exist for this client, and can I revoke them?

Use the separate Requests tab for the justification, reviewer decision, and consent-verification workflow. Request history and the current Entra grant state answer different questions.

Configuration, Approval, and Consent

An app registration defines the application and its configured API permissions. Its service principal (Enterprise application in Entra) represents it in a tenant and holds grants and assignments. They share an Application (client) ID, but have different Object IDs. Compare tenant and Application IDs when names differ; similar names or permission lists do not prove two records are the same application. See Microsoft's application and service principal model.

State	Meaning
Configured permission	The client registration declares the permission it needs. Adding it does not itself grant access.
Approved request	An authorized reviewer accepted the business need. The request outcome determines whether configuration, consent, or further verification remains.
User consent	A delegated grant applies to one user through one client. It does not satisfy a tenant-wide admin-consent check.
Admin consent	A delegated grant applies to all users in this tenant for a particular client, API, and set of scopes. A signed-in user is still required.
Application permission	An app-role assignment authorizes the client service principal to act without a signed-in user.

Entra represents user and tenant-wide delegated grants as Principal and AllPrincipals respectively. Admin consent required: No describes a scope's consent requirement; it does not mean consent already exists. Tenant consent policy can further restrict user consent. See Microsoft's delegated grant definition and permissions and consent overview.

Permission Types

Entra ID supports several types of permissions, each serving different authentication scenarios:

Application Permissions (App Roles)

Application permissions allow your app to act as itself without a signed-in user present.

Use Case: Background services, daemons, server-to-server scenarios

Consent Required: Always requires admin consent

Authentication: Uses client credentials (secret or certificate)

Example: "User.Read.All", "Mail.ReadWrite", "Directory.Read.All"

Delegated Permissions (OAuth2 Scopes)

Delegated permissions allow your app to act on behalf of a signed-in user.

Use Case: Web apps, mobile apps, single-page applications

Consent Required: User consent or admin consent depending on permission sensitivity

Authentication: Uses authorization code flow or on-behalf-of flow

Example: "User.Read", "Mail.Send", "Files.ReadWrite"

Key Difference: Application permissions authorize the application identity. Delegated permissions authorize actions on behalf of a user, within the scope and the API's user-access rules. Admin consent to a delegated scope does not turn it into an application permission.

Viewing API Permissions

The Roles & Access → APIs used view lists configured API permissions and compares them with grants for this client:

1. Navigate to your application's details page

2. Go to the Roles & Access tab

3. Select the APIs used sub-tab

4. View permissions grouped by API (Microsoft Graph, Entra ID, custom APIs)

Permission Status Indicators

Each permission shows its grant status:

Granted: The matching application-role assignment or tenant-wide delegated grant exists. API authorization and sign-in requirements still apply.

Not Granted: The permission is configured but the matching assignment or tenant-wide delegated grant is missing. Individual users may already have consented; inspect the User & admin consent tab for those grants.

Grant One Delegated Permission

For an active internal API, you can grant a specific configured, enabled scope to a specific client. This is tenant-wide consent for that client and scope. Other clients and unselected permissions are unaffected, and existing granted scopes are preserved.

From the client application

Open the client application's Roles & Access → APIs used.
Find the internal API and the delegated permission marked Not Granted.
Select Grant admin consent on that permission and confirm the client, API, scope, and tenant-wide effect.
Review the refreshed grant status. Repeat only for other permissions you intend to grant.

From the API application's Grant Report

Open the target API's Roles & Access → Access to this app.
Find the delegated scope marked Awaiting admin consent and select Review consent.
In the principals dialog, select Grant admin consent beside the intended application.
Confirm the named application and scope. Only that row is granted; other pending applications remain awaiting consent.

Example: granting AtlasAPI's api_access to Compass leaves Compass-Access and OPSManager-API unchanged. Cancelling the confirmation makes no change. A successful row becomes All users (admin consent), and the report reloads after the attempt. Read-only views and existing user/admin grant rows do not offer this action.

These actions update Entra grants, without changing permission-request statuses. If a request is awaiting consent, use its consent follow-up to verify completion. Microsoft Graph supports adding selected scopes to a grant; the existing scope list must be retained when updating it. See updating delegated grants.

Who Can Grant or Approve?

Action	AZExecute authorization	How the Entra operation runs
Grant from the client's APIs used view	Client owner who also owns the target API, or has an approved delegated request for the exact client/API/scope; alternatively, a tenant administrator.	Configured App Consent Helper.
Grant from the target API's Grant Report	Target API owner or tenant administrator.	Configured App Consent Helper.
Review an internal permission request	Target API owner or tenant administrator.	Application identity for app roles and pre-authorization; App Consent Helper for delegated admin consent.
Review an external API request	Tenant administrator.	Configuration first; required admin consent follows the administrator workflow.
Review/revoke through the User & admin consent tab	Subject to application access and revocation policy; admin grants require tenant administrator access.	Signed-in user's delegated Graph context and Entra privileges.

Owning only the client is insufficient to approve access to another team's API. Pending, rejected, cancelled, or unrelated requests do not authorize client-side granting. The server rechecks tenant, ownership or approval, configured permission, and current enabled scope before granting. Direct internal granting requires the App Consent Helper to be ready; it does not grant Microsoft Graph or other external API permissions.

AZExecute approval authority is a product policy. It does not assign the reviewer an Entra administrator role. Tenant administrators must configure the helper with the required Entra authorization before owners can use this workflow. The separate Consent tab uses the existing Directory.AccessAsUser.All delegated context and never falls back to the helper or app-only credentials. See consent setup and policy and Microsoft's admin-consent role requirements.

Exposing API Scopes

If your application provides an API that other applications should access, you can expose custom scopes:

Viewing Exposed Scopes

1. Navigate to Roles & Access tab

2. Select the API scopes sub-tab

3. View all OAuth2 permission scopes your API exposes

4. See which applications are pre-authorized to use these scopes

Scope Components

Each exposed scope includes several properties:

Scope Value

The scope name used in code (e.g., "access_as_user", "read_data")

Display Name

User-friendly name shown during consent

Description

Detailed explanation shown to users and admins during consent

Consent Type

Whether users can consent themselves or admin consent is required

Enabled State

Whether the scope is currently enabled and can be requested

Editing scopes: This API scopes view is read-only. Authorized owners can use Registration Configuration when enabled by the tenant, or manage the registration in Entra. Defining a scope does not grant it to a client.

Pre-Authorized Client Applications

Pre-authorization allows trusted applications to access your API without requiring user consent. This streamlines the user experience for first-party applications.

Pre-authorization is a separate registration setting for selected clients and scopes; it is not evidence of a tenant-wide delegated grant. It does not approve every permission the client requests. See Microsoft's pre-authorized application definition.

How Pre-Authorization Works

1

Configuration

API owner adds client application as pre-authorized for specific scopes

2

Silent Consent

Users do not need to consent to the specific pre-authorized scopes

3

Seamless Access

The client still needs a valid token, and API authorization rules still apply

Viewing Pre-Authorized Clients

On the API scopes sub-tab, you can see:

• List of all pre-authorized client applications

• Which scopes each client is pre-authorized to use

• Client application details (name, application ID)

Security Note: Only pre-authorize applications you fully trust and control. Pre-authorization bypasses user consent, which is a key security mechanism.

Requesting Pre-Authorization

Use the Permission Request system to request pre-authorization:

1. Navigate to the Requests tab

2. Click Request Permission

3. Select the target API application

4. Choose Authorized Client as the grant type

5. Select the scopes you need access to

6. Provide justification and submit

Application Roles

Application roles (App Roles) allow you to implement role-based access control (RBAC) within your application.

Viewing App Roles

1. Navigate to Roles & Access tab

2. Select the App roles sub-tab

3. View all defined application roles

4. See which users, groups, or applications are assigned to each role

App Role Properties

Display Name

User-friendly name for the role (e.g., "Administrator", "Reader")

Value

The role claim value in tokens (e.g., "app.admin", "app.reader")

Description

Explanation of what the role grants access to

Allowed Member Types

Who can be assigned: Users/Groups, Applications, or Both

Enabled State

Whether the role can currently be assigned

Use Cases for App Roles

Application RBAC: Implement role-based access control within your app

API Permissions: Define granular permissions for service-to-service calls

Multi-Tenant Apps: Consistent roles across different customer tenants

Best Practice: Use app roles for application-specific permissions and Entra ID groups for organizational roles. This separation makes management clearer.

Grant Report

The Grant Report shows inbound access: which clients, users, and groups can access this application/API, together with configured clients that still lack tenant-wide delegated consent.

Viewing the Grant Report

1. Navigate to Roles & Access tab

2. Select the Access to this app sub-tab

3. View all inbound permissions and role assignments

Grant Report Sections

App Role Assignments

Shows which users, groups, or applications have been assigned to your app roles:

• Principal name (user or application)

• Assigned role name

• Principal type: user, group, or application

• Whether an application assignment is also configured on the client registration

Delegated Permission Grants

Shows delegated permissions that have been consented to:

• Client application requesting access

• Granted scopes

• Consent type (User or Admin)

• Principal (if user consent, which user consented)

Pre-Authorized Clients

Lists applications that have been pre-authorized to access your API:

• Client application name and ID

• Pre-authorized scopes

• Pre-authorization listed separately from consent grants

Audit Use: Use the Grant Report regularly to audit who has access to your application and ensure principle of least privilege is maintained.

Why a client can appear in both granted and pending entries

A user may have consented to a scope through Compass while Compass has no tenant-wide consent for that scope. The report keeps that user grant visible and also lists Compass under Awaiting admin consent. In the principals dialog, Awaiting admin consent describes the missing tenant-wide grant; it is not the status of a permission request. The report counts granted entries separately from entries awaiting consent. Consent counts describe grants, not unique people; the same user can have separate grants through different clients.

Use Review consent to grant only the chosen client and scope. For application-role assignments marked granted but not configured, Configure permission updates the client registration's configured permissions; it does not create a new grant. Review its confirmation, which can include multiple clients in the group.

Review and Revoke Existing Consent

Open the client application's Roles & Access → User & admin consent. Select Individual users (user consent) or All users (admin consent), then search by user, API, or permission. The last check time is shown above the table. Expand How consent works & technical details for the service principal Object ID and consent explanation. Application permissions are shown separately in Permissions.

Where available, Revoke consent removes the selected grant, including all permissions listed in that grant's confirmation. This is different from granting one scope. Review the affected user or all-users audience before confirming. The operation runs as your signed-in user and needs appropriate Entra access even if AZExecute allows you to manage the application.

Revocation does not immediately sign users out; existing access tokens may remain usable until expiry, and users may be able to consent again under tenant policy. Removing a configured permission or changing a request status is also separate from revoking an existing grant. Refresh the Consent view to inspect the resulting state.

Resolve Common Consent Questions

What you see	What to check next
No grant action, or an unavailable action	Check ownership or exact approved request, active internal applications, configured/enabled scope, and App Consent Helper readiness. Read-only access does not allow granting.
Request approved, but access still missing	Read its outcome and consent requirement. Configuration and owner approval alone do not prove a grant exists.
Entra and AZExecute appear different	Compare tenant and Application IDs, then refresh. Check whether each view shows configured permissions, one user's consent, tenant-wide consent, or API pre-authorization.
Consent was granted outside the request workflow	A tenant administrator should use Check consent, or Complete consent when the helper is offered, on an awaiting request. Every requested permission must be covered before it completes.
Grant failed or the response was interrupted	Refresh and inspect current grants before retrying. A server-side write may have completed. Give your administrator the displayed error reference and application, API, scope, and time.
Grant exists but the API rejects access	Check the token's API audience, requested scopes or roles, signed-in user where required, and the API's own authorization rules.

Best Practices

Follow principle of least privilege

Only request permissions your application actually needs

Prefer delegated over application permissions when possible

Use delegated access for user-driven work; use narrowly scoped application permissions when a workload must operate without a user.

Review the Grant Report regularly

Audit who has access and remove unnecessary assignments

Document why each permission is needed

Maintain documentation for compliance and future reference

Use app roles for application-specific permissions

Don't rely solely on Entra ID groups for in-app authorization

Be cautious with pre-authorization

Only pre-authorize applications you fully trust and control

Use the permission request system for changes

Formal request-approval workflow maintains governance and audit trail

Grant only the client, API, and permissions justified by the use case. Review all-users consent explicitly, keep ownership current, and review configuration and actual grants together when removing access. These practices follow Microsoft's least-privilege guidance. AZExecute's owner-review and helper workflows are product-specific controls, not a replacement for Entra authorization or your organization's consent policy.