Permission Requests

Permission Request System

The Permission Request system in AZExecute provides a formal approval workflow for managing internal API access, external API permissions, app roles, delegated scopes, and pre-authorized client access. It gives requesters a clear way to ask for access and gives owners and administrators an audit trail for approval decisions.

Start with the client application, target API, grant type, and minimum permissions needed. Follow the request status through to the grant or consent outcome. For existing configured permissions, see granting one permission to one application.

Automating Permission Requests with REST or MCP

REST clients and AI agents can use the same governed workflow for both internal and external API permissions. Authenticate with the required API role, use Swagger or MCP operation discovery to inspect the current contract, and always select permissions returned by the discovery operations instead of guessing identifiers.

API access does not bypass ownership, tenant, license, role, approval, or consent checks. Service principals must have an assigned AZExecute API app role, and approval still follows the configured internal-owner or TenantAdmin path.

Open API Swagger for the supported permission discovery, request, and review operations.

Why Use Permission Requests?

Permission requests solve several common challenges in application permission management:

Security Governance: API owners review and approve permission requests before granting access

Audit Trail: Complete history of who requested what access and when it was granted or denied

Justification Required: Requesters must explain why they need access, aiding in security decisions

Automated Notifications: Application owners are notified of pending requests via email

Reduced Admin Burden: Distributes permission management to application owners instead of central IT

Permission requests create a collaborative workflow between application developers (requesters) and API owners (approvers), ensuring least-privilege access is maintained.

Permission Requests from Application Requests

Permission Requests can be created directly by an application owner, or they can be created from API permissions included in an Application Request. This keeps API access review consistent no matter how the application was requested and prevents application creation from automatically granting unrelated API access.

• Internal API permissions are reviewed by the owners of the target application

• External API permissions are reviewed by an administrator and may require Entra ID consent

• Each request keeps its own justification, approval state, and audit history

• If the application request itself is created without approval, the related Permission Requests still remain pending until the right approver handles them

Creating an application, approving its API access request, and granting consent are separate steps. External permissions that require admin consent enter the consent queue after approval; the Entra administrator completes consent and AZExecute verifies it.

Permission Target Model

A Permission Request always has a source application, a target API, and a grant type. The target determines who reviews the request and whether Entra ID consent may be required.

Internal APIs

• The target is another application managed in AZExecute

• The target application owners review whether the source application should receive access

• After approval, AZExecute applies the access where tenant setup and Entra ID permissions allow it

External APIs

• The target is an API outside the managed application list, such as Microsoft Graph or another public service principal

• Administrators review these requests because external APIs often require tenant-wide consent or elevated Entra ID permissions

• Approval configures the requested permissions. Required tenant-wide consent is completed separately by an appropriately authorized Entra administrator

Pre-Authorized Client Access

• Pre-authorization is intended for trusted client applications and internal API ownership scenarios

• Approvers should only approve it when the source application is trusted to bypass normal user consent prompts for the selected scopes

An AZExecute TenantAdmin can review external requests, but this product role does not grant Entra privileges. Entra consent and delegated consent checks require appropriate Entra access. Use the least privileged role supported for the specific operation.

Request Types

The system supports three types of permission requests, each serving different access scenarios:

Application Permissions (App Roles)

Request application-level permissions that allow your app to act without a signed-in user.

Use When: Your background service needs to access an API automatically

Example: Requesting "User.Read.All" to synchronize user data from Microsoft Graph

Grant Process: Internal requests apply app-role assignments. External requests configure the permission and await admin consent. See the outcome table below.

Delegated Permissions (OAuth2 Scopes)

Request delegated permissions that allow your app to act on behalf of signed-in users.

Use When: Your web or mobile app needs to access APIs while users are signed in

Example: Requesting "Mail.Send" to send emails on behalf of the signed-in user

Grant Process: After approval, AZExecute applies the delegated scope where possible. User or admin consent may still be required depending on the permission.

Pre-Authorized Client Access

Request to be added as a pre-authorized (trusted) client for specific API scopes.

Use When: You want to eliminate consent prompts for users accessing your API

Example: Requesting pre-authorization for "access_as_user" scope in a related first-party app

Grant Process: After approval, pre-authorization is configured in Entra ID

Target Model: Use for trusted internal or first-party API scenarios where the API owner controls the exposed scopes

Security Note: Pre-authorization requests require careful review as they bypass user consent. Only approve for applications you fully trust.

Creating a Permission Request

To request permissions for your application:

1. Navigate to your application's details page

2. Go to the Requests tab

3. Click Request Permission button

4. The request creation dialog opens

Request Creation Steps

Step 1: Select Target Application

• Search for the API application you need access to

• Use the autocomplete to filter by application name or ID

• Select the application from the dropdown

Step 2: Choose Permission Type

• Application Permission: For background services and daemon apps

• Delegated Permission: For user-interactive applications

• Authorized Client: To be pre-authorized for specific scopes

Step 3: Select Specific Permissions

The system displays available permissions based on your selection:

• Browse the list of available permissions

• Select multiple permissions only when they belong in the same approval decision. Review every selection before using "Select All"

• Already-granted permissions are shown as disabled with status indicator

• Select only the permissions you actually need (principle of least privilege)

Smart Detection: The system automatically detects if a permission is already granted and prevents duplicate requests.

Step 4: Provide Justification

• Explain why you need these permissions (required field)

• Be specific about the use case and business requirement

• Good justification helps approvers make informed decisions

• Maximum 500 characters

Step 5: Review and Submit

• Review the request summary showing all selected permissions

• Verify the target application is correct

• Click Submit Request to send for approval

• Requests are created immediately and owners are notified

Managing Outgoing Requests

The Outgoing tab shows all permission requests your application has made to other applications:

Viewing Outgoing Requests

1. Navigate to the Requests tab

2. Ensure Outgoing sub-tab is selected

3. View all requests grouped by target application

4. Filter by status (Pending, Approved, Denied)

Request Information Displayed

Target Application: Which API you're requesting access to

Permission Details: Name and value of requested permission

Grant Type: Application, Delegated, or Authorized Client

Request Date: When you submitted the request

Status: Pending, Approved, Awaiting admin consent, Consent granted, Rejected, or Cancelled

Justification: Your explanation for needing the permission

Status Meanings

Status	Meaning and next step
Pending	Waiting for the target API owner or tenant administrator to review the requested access.
Approved	Approved and processed for its request type. A delegated request without an admin-consent requirement can be configured/approved without any user having consented.
Awaiting admin consent	The reviewer approved the request and the permissions are configured, but required tenant-wide consent remains. A tenant administrator must complete or verify it.
Consent granted	The required consent was completed or verified for the requested permissions. This records the workflow result; later changes in Entra can change actual access.
Rejected	The reviewer declined the request. Read the reason and request narrower access if appropriate.
Cancelled	The requester withdrew the request. Cancellation is not a grant-revocation action.

Use After Approval to understand the outcome for each request type. Use Roles & Access to inspect actual configured permissions and grants. A request decision is not a permanent guarantee of access.

Managing Incoming Requests

If you're an application owner, you'll receive permission requests from other applications that want to access your API or be pre-authorized:

Viewing Incoming Requests

1. Navigate to your application's Requests tab

2. Select the Incoming sub-tab

3. View requests from other applications

4. Pending requests are highlighted for your attention

Request Details

Each incoming request shows:

• Source Application: Which app is requesting access

• Requester: Who submitted the request (name and email)

• Permission Requested: Specific permission name and description

• Grant Type: Application, Delegated, or Pre-Authorization

• Justification: Why they need this access

• Request Date: When it was submitted

Reviewing and Approving Requests

A bundled request is approved as a whole. If only some permissions are justified, have the request corrected or split before approval. The Grant Report's individual client/scope action is a separate grant operation; it does not partially approve or complete a bundled request. Internal requests can be reviewed by the target API's owner or a tenant administrator in the same tenant; external requests require a tenant administrator.

To process a pending request:

1. Click on the request to expand details

2. Review the justification and assess if access is appropriate

3. Consider the principle of least privilege - is this the minimum permission needed?

4. Click Approve to approve the requested access and start processing

5. For pre-authorization requests, approval automatically configures Entra ID

6. For application or delegated permissions, AZExecute applies the access where possible; user or administrator consent may still be required depending on the API and permission

7. Read the resulting status. If it is Awaiting admin consent, follow the administrator consent steps below

Rejecting Requests

If you need to deny a request:

1. Click Reject on the request

2. Provide a reason for denial (helpful for the requester)

3. Consider suggesting an alternative permission if appropriate

4. Requester is notified of the denial and your reason

Review Carefully: Before approving application permissions or pre-authorization, ensure you trust the requesting application. These grant broad access without individual user consent.

Notifications

The permission request system sends automated email notifications to keep all parties informed:

When Notifications are Sent

Request Submitted

Target application owners receive notification of new permission request

Request Approved

Requester receives confirmation with next steps (if consent required)

Request Denied

Requester receives notification with denial reason

Notification Content

Email notifications include:

• Application names (source and target)

• Requested permission details

• Justification provided

• Direct link to review or view request in AZExecute

• Next steps (for approvals)

After Approval: Applying Access

Approval records the reviewer's decision. The API type, permission type, and tenant consent policy determine the next step. Internal request processing uses configured application credentials; it does not borrow the reviewing owner's Entra administrator privileges.

Request	What approval does	Expected outcome
Internal application permission	Validates the enabled app role and application member type, configures it on the client, then applies the app-role assignment using the Application identity.	Approved after successful processing.
Internal delegated scope requiring admin consent	Configures the scope and grants tenant-wide consent through the App Consent Helper when ready.	Consent granted on success; Awaiting admin consent if the helper is not ready.
Internal delegated scope without an admin-consent requirement	Configures the scope. If the tenant's “Always grant admin consent for approved internal requests” policy is enabled, it follows the helper path above.	Approved without that policy; user consent may still be needed. With the policy, Consent granted or Awaiting admin consent.
External application permission or delegated scope requiring admin consent	Configures the permission and routes it to the administrator's consent queue. Internal helper setup does not change this path.	Awaiting admin consent until verified.
External delegated scope without an admin-consent requirement	Configures the scope; the internal always-consent policy does not apply.	Approved; actual user consent remains subject to Entra tenant policy.
Pre-authorized client	Configures the selected client and scopes on the internal API registration using the Application identity.	Approved. Pre-authorization is separate from a tenant-wide consent grant.

Missing or disabled permissions must be corrected before approval. If a configured helper fails during execution, the operation reports failure; it does not silently retry as the signed-in user. Refresh the request and current grants before retrying an interrupted operation because Entra writes may already have occurred.

See administrator consent setup and who can grant or approve. API-owner approval is AZExecute governance; actual writes still require the executing identity's Entra authorization.

A tenant administrator opens Approvals → API Permissions → Awaiting admin consent and selects the request.
For an internal request with a ready helper, use Complete consent. Otherwise, use Open in Entra and have an appropriately authorized Entra administrator grant the intended permissions.
After granting in Entra or elsewhere, select Check consent. This reads Graph as the signed-in administrator; AZExecute's TenantAdmin role alone does not provide Entra privileges. For an internal request with a ready helper, the action is labelled Complete consent and uses the helper to complete the requested grants.
The request becomes Consent granted only when every requested enabled scope has tenant-wide consent for the exact client and API service principals, or every requested application-role assignment is present.

Partial grants, individual user consent, and configured manifest entries do not complete an admin-consent request. Checks run when requested; there is no background consent polling. The original owner approval and reviewer remain recorded separately from verification.

Granting one client/scope from Permissions or Grant Report does not automatically update its request. Use Check consent, or Complete consent when offered, for an awaiting request afterwards. For external APIs, follow Microsoft's admin-consent requirements; review the permissions shown by Entra before confirming, since its app-level action can cover more permissions than one AZExecute request.

Best Practices

For Requesters

Request only what you need

Follow principle of least privilege - don't request broad permissions when narrow ones will work

Provide detailed justification

Explain specific use case, not just "needed for application to work"

Choose correct permission type

Use delegated permissions when users are involved, application permissions only for background services

Contact API owners if denied

Discuss concerns and possibly request alternative permissions

For Approvers

Review requests promptly

Pending requests block development work - try to respond within 24-48 hours

Verify justification makes sense

If unclear, ask requester for more details before approving

Be cautious with application permissions

These grant broad access without user context - ensure they're truly necessary

Only pre-authorize trusted applications

Pre-authorization bypasses consent - use only for first-party apps you control

Provide helpful denial reasons

Explain why denied and suggest alternatives if applicable

Periodically review granted permissions

Use the Grant Report to audit who has access and revoke if no longer needed