Identity Basics 2 - Permissions, Scopes and Consent

In my previous post, we saw how app registrations add identity configurations for applications on Azure AD. Just like a user, an application would also require access to resources like Microsoft Graph, which need authorization. The resource owner can grant(consent) or deny this authorization to the application. There are mainly 2 access scenarios:

1. Delegated access - access on behalf of a signed-in user. User is signed-into a client application, which access the resource on behalf of the user. This requires delegated permissions (also referred to as scopes). All scenarios involving user actions should use delegated access. Also, scopes should be limited using the principle of least-privilege.
   See also: the full list of Microsoft Graph permissions
2. App-only access - access without a user, as the application’s own identity. This scenario is when the application runs as a background service or daemon used for automation or backup, or the data can’t be scoped to a single user. The client app needs to be granted appropriate application roles of the resource app it’s calling to access the requested data. Application roles granted through consent are called application permissions.

Consent is the process by which admins or users authorize an application to access a protected resource. e.g. during an application sign-in for the first time, a user may see a consent prompt with the list of permissions that the client app is requesting (e.g. ability to see the user’s profile or access the user’s calendar). Granting consent can happen in 3 ways:

1. User consent - requested when the user attempts to sign-in to the client application for the first time.
   

2. Admin consent - In many cases, an admin may be required to grant consent : either application permissions or high-privilege delegated permissions. Administrators can grant consent for themselves or for the entire organization. Examples of some admin-restricted permissions (especially in organizations as opposed to individual consumers) could be reading all users' full profiles using User.Read.All, or reading all groups in a tenant with Groups.Read.All.
   

If admins have not granted consent, and the client application requests delegated permissions that require admin consent, the users receivs an error message that says they’re unauthorized to consent to the permissions, and are asked to contact their admin for access to the app.

3. Preauthorization - resource owners can grant permissions without requiring users to see consent prompts for the same set of permissions that have been preauthorized.

Admin consent for Multi-tenant applications:

By default, web API/app registrations are single-tenant upon creation, unless supported account types are changed during the app registration. For a multi-tenant application, its app registration exists only in the tenant where it was created, and so permissions can’t be configured in the local tenant. In such cases where admin consent is required, the administrators need to log in to the application themselves, which triggers the admin consent sign-in experience. I will explore the application sign-in process in later posts.