Difference Between Delegated and App-Only Access in Microsoft Entra ID Applications

On Day 3 of Cybersecurity Awareness Month, we focus on delegated and application permissions in Entra ID, and the security risks associated with them. Stay tuned for more blogs in the Cybersecurity blog series.

Access control is a cornerstone of Microsoft 365 cybersecurity, as permissions determine how users and applications can use resources. To avoid unauthorized access, it is essential to assign the correct type of access for each app in Microsoft Entra identity. Mismanaging these app permissions without understanding their purpose can create opportunities for attackers.

Therefore, in this blog, we break down delegated vs application permissions, examine their risks, and explain how over-permissioning increases security threats.

Applications authenticate with Microsoft Entra ID based on the type of access they have been granted. Broadly, there are two ways these applications can access organizational data.

• Delegated access: The app acts on behalf of a signed-in user.
• App-only access: The app acts on its own identity without a signed user.

Let’s see what the difference is between delegated and application permissions for access tokens in the Microsoft identity platform in detail.

Delegated access allows a client application to get access on behalf of the user. The app can gain authorized access only if the signed-in user holds the needed permissions and the app has been granted the required delegated permissions.

• Delegated Permissions (Scopes): These are the permissions exposed by the service (like Microsoft Graph) defining the specific operations the app can perform on behalf of the user (e.g., Mail.Read, Mail.Send).
• User Permissions: These are the native permissions the signed-in user already holds for the resource. This can be because they own the resource, it was shared with them, or they were assigned a role via a system like Microsoft Entra RBAC.

Delegated permission is useful when actions must align with a real person’s identity. However, its risk lies in the fact that if the user already has broad permissions (like Global Administrator), the app inherits those privileges. So, an attacker can gain access if either the app or user account is compromised.

1. The app prompts the user to sign in, and upon successful sign-in, a consent screen detailing the permissions the app requires (its scope) is displayed. These permissions are only effective when a user is logged in and has consented to the application.
2. Once the user approves the consent, the service issues the app a secure, temporary delegated permission token.
3. This token is the key. It represents the combination of the user’s identity and the specific, limited application permission scope (e.g., Mail.Send).
4. The app uses this token in its requests to the server, proving it’s authorized to act as the user’s agent for that specific task.

Example scenario: App accessing users files with delegated permissions

When a user signs in to an application that has been granted the Files.Read.All delegated permission, the app can only read the files that the user is permitted to access. The application presents the access token to the service, which verifies both the user’s rights and the app’s delegated permission. If both match, the user’s accessible files are made available through the app.

Application permissions (called “App-Only” access) allow a client application to act on its own. The application’s effective rights are solely determined by the permissions explicitly granted to the application. The app can gain authorized access if the right application permission is configured.

• Application Permissions: These are the permissions given by the service that define the specific operations the application itself can perform (e.g., Mail.ReadWrite.All, User.Read.All). These permissions are typically granted by admins during app configuration, as they often involve reading or writing data across the entire organization.

Application permissions are essential for apps that get access without a user to run in the background (e.g., nightly scripts, daemon services). The primary risk lies in the broad scope of permissions often granted and app-only authentication. Because the app acts across all users, if the app’s credentials (a client secret or certificate) are compromised, an attacker gains access to all data and resources covered by those permissions.

1. The organization’s administrator must explicitly grant the required application permissions during the application’s registration or setup. There is no end-user consent screen.
2. The app authenticates the service using its own credentials, such as a client secret (password) or a certificate.
3. The app authentication service verifies the app’s identity and issues it an access token.
4. This token represents the application’s identity and the full list of administrative permissions that were granted to it (e.g., User.Read.All).
5. The app uses this token in its requests to the server, proving it is authorized to perform organization-wide actions without a signed-in user present.

Example Scenario: App accessing all user’s files using application permissions

When an application is granted the Files.Read.All application permission through Microsoft Graph, it can read every file in the tenant, regardless of which user owns them. The app authenticates with its own identity, and the service verifies that the app has been granted this tenant-wide permission.

While the above explains delegated and app-only access in detail, the table below provides a quick comparison of delegated and application permissions.

Aspect	Delegated Access	App-Only Access
Identity Context	App acts on behalf of a signed-in user	App acts independently
Authentication	Requires user sign-in (OAuth 2.0) and user consent	Uses client secret, certificate, or managed identity
Scope of Permissions	Limited by user rights and app scopes	Directly tied to app’s assigned scopes
Risk Surface	If the user is compromised, the app inherits their privileges	If app credentials are compromised, attacker has broad access
Visibility	Actions show up as user activity in logs	Shows as service principal activity, harder to trace
Types of Apps	Web/mobile/single-page app (SPA)	Web/daemon
Who Can Consent	Users can consent for their data and admins can consent for all users	Only admin can consent
Consent Methods	Requests individual permissions at sign-in. For permissions already pre-configured in the app registration, these are handled statically.	Uses only the pre-configured list on the app registration.
Lifespan	Tied to user session or tokens	Long-lived access and survives beyond user lifecycle
Typical Use Case	Apps that need to “act as a user” (e.g., read calendar, send mail)	Background tasks, automation, backups, etc.

Note: You can add both delegated and application permissions to an application, depending on the required access scenarios. In such cases, the app’s method of accessing data depends on the authentication approach used.

When it comes to security, delegated and app-only access are two sides of the same coin. Both can be safe when scoped correctly, but both can be disastrous when over-permissioned.

Delegated Access Risks

• Admins sometimes allow apps to request tenant-wide delegated scopes (like Mail.ReadWrite.All) even if the user only needs a fraction of that data.
• If a privileged user (e.g., Global Admin) uses the app, the app inherits all of those privileges.
• Attack Scenario: A consent phishing attack tricks a user into granting a malicious app “Send mail as you.” The attacker now impersonates the user for BEC (Business Email Compromise).

App-Only Access Risks

• Developers often grant tenant wide admin consent (e.g., Mail.ReadWrite.All permissions) to app-only identities for convenience.
• Credentials (secrets/certs) might be stored insecurely in code or config files.
• Attack Scenario: A leaked client secret for an app with User.ReadWrite.All lets an attacker silently modify settings, add backdoor accounts, elevate privileges, etc. This can all happen without triggering user-facing sign-ins.

At the core, the danger isn’t just the permission model itself, but the habit of granting more permissions than truly needed.

Both delegated and app-only access are essential for productivity and automation in Microsoft 365. The problem isn’t their existence, it’s how loosely they’re managed. Here’s how to tighten control.

Enforce Least Access Privilege: To tighten control, it is important to enforce Microsoft Entra least access privilege control by assigning only the minimum scopes an app needs. Broad permissions, such as tenant-wide scopes (*.All), should be avoided unless necessary. For delegated apps, incremental consent should be used, requesting additional permissions only when required.

Choose the Right Permission Type: When deciding which permission to grant, align the choice between delegated and application permissions with the application’s actual requirements. Consider the nature of the tasks it needs to perform and the level of access needed to achieve them.

Control User Consent: Manage user consent to applications in Microsoft 365 by configuring consent workflows so that sensitive scopes require consent approval from admin team. Regularly review app permissions and consents to detect and remediate illicit consent grant attacks.

Secure App-Only Credentials: Use certificates or managed identities instead of client secrets to secure app-only credentials. Restrict the creation of client secrets on Microsoft Entra apps, rotate credentials regularly, and avoid hard-coding them in scripts or repositories. Additionally, implement Microsoft Entra application management policies to enforce rules for how app credentials are created, stored, and maintained.

Monitor and Audit Permissions: Regularly review service principals and application registrations to decommission those that are no longer in use. Also, monitor app sign-ins for anomalies or suspicious activity to maintain a secure and compliant environment.

Educate Users and Developers: Train users to recognize consent phishing prompts and guide developers to request the narrowest scopes possible during app design. Embed security reviews into the app registration process to ensure proper governance.

Wrapping Up

To keep permissions minimal, tightly monitored, and under strict control is important, because they can be exploited if not carefully managed. We hope this blog helps you better understand delegated vs application permissions and promotes a secure environment that supports productivity while minimizing risk. If questions remain, share them in the comments section below for further discussion.