Table of Contents
Types of permissions
In this post, we want to give you our brief description of the two permissions Delegated vs Application.
The official document. If you are still here, this is the dumb down version of the doc. The concept is simple.
Delegated access (access on behalf of a user)
Delegated permissions are used in the delegated access scenario. They’re permissions that allow the application to act on a user’s behalf. The application will never be able to access anything the signed in user themselves couldn’t access.
For example, imagine an application that has been granted the Files.Read.All delegated permission on behalf of Alex, the user. The application will only be able to read files that Tom can personally access. An example of delegated permission page looks like this:
If you’re an admin of your tenant, you can check the permissions granted for an aap in Microsoft Entra admin center. For example, we’ve checked the Microsoft Graph Command Line Tools app.
App-only access (access without a user)
Application permissions, sometimes called app roles are used in the app-only access scenario, without a signed-in user present. The application will be able to access any data that the permission is associated with.
For example, below use the application permission with right to export all users information.
The main difference between the two is that the Delegated permission requires a user to sign in and needs consent from the user while the Application permission uses its own application identity (Application ID and credential certificate or client secrets) to authenticate against the Azure Active Directory without require a user’s consent.
Comparison of delegated and application permissions
For example, to send emails using Microsoft Graph, you need to consent to the mail.send permission scope, but depending on if you consent to this permission using delegated or application permissions, a different level of access is granted.
If you consent to the mail.send permission in a delegated scenario, you may notice you can only send mail as the user authenticated in your current session (the current user context).
However, when consenting to the equivalent application permission, you will notice you can send mail as any user in your organisation.
More things about sonsenting permission
One way that applications are granted permissions is through consent. Consent is a process where users or admins authorize an application to access a protected resource.
User consent
User consent happens when:
- A user attempts to sign into an application.
- The user provides their sign-in credentials.
- These credentials are checked to determine whether consent has already been granted.
- If no previous record of user or admin consent for the required permissions exists, the user is shown a consent prompt, and asked to grant the application the requested permissions.
Other scenarios where users may see a consent prompt include:
- When previously granted consent is revoked.
- When the application is coded to specifically prompt for consent during sign-in.
- When the application uses dynamic consent to ask for new permissions as needed at run time.
The key details of a consent prompt are the list of permissions the application requires and the publisher information. For more information about the consent prompt and the consent experience for both admins and end-users, see application consent experience.
Administrator consent
In many cases, an admin may be required to grant consent on behalf of the user. Depending on the permissions they require, some applications might require an administrator to be the one who grants consent.
For example, application permissions and many high privileges delegated permissions can only be consented to by an administrator. Administrators can grant consent for themselves or for the entire organization. For more information about user and admin consent, see user and admin consent overview.
Preauthorization
Preauthorization allows a resource application owner to grant permissions without requiring users to see a consent prompt for the same set of permissions that have been preauthorized. This way, an application that has been preauthorized won’t ask users to consent to permissions. Resource owners can preauthorize client apps in the Azure portal or by using PowerShell and APIs, like Microsoft Graph.
Not a reader? Watch this related video tutorial:
