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.

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 grant broad access regardless of user. Delegated permissions are limited by both the permission scope AND the user's own permissions.

Viewing API Permissions

The Roles & Access tab provides a comprehensive view of all permissions your application has been granted:

1. Navigate to your application's details page

2. Go to the Roles & Access tab

3. Select the Permissions sub-tab

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

Permission Status Indicators

Each permission shows its grant status:

Granted: Permission has been consented to and is active

Not Granted: Permission configured but not yet consented to

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

Note: Scope management (creating, editing, deleting) must be done in Azure Portal or via Entra ID APIs. AZExecute provides read-only views of exposed scopes.

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.

How Pre-Authorization Works

1

Configuration

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

2

Silent Consent

When users sign in to the client app, consent is granted automatically

3

Seamless Access

Client application can call the API without consent prompts

Viewing Pre-Authorized Clients

On the 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 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 provides a comprehensive overview of all permissions and access granted TO your application by other applications and users.

Viewing the Grant Report

1. Navigate to Roles & Access tab

2. Select the Grant Report 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

� Assignment date

� Source (direct assignment or group membership)

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

� Configuration date

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

Best Practices

Follow principle of least privilege

Only request permissions your application actually needs

Prefer delegated over application permissions when possible

Delegated permissions provide better security through user context

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

If you encounter any issues or need further assistance, please contact us at

info@azexecute.com

. Our support team is here to help you.