Configure permissions

3 minutes

Before the Microsoft identity platform can authorize your app to access data in Microsoft Graph or the Microsoft cloud, the app must be granted the privileges that it needs. In this unit, you learn about the different types of permissions and how to configure them for your Microsoft Teams app in the Azure portal.

What are permissions?

Microsoft Graph exposes granular permissions that control the access that apps have to Microsoft Graph resources, like users, groups, and mail. As a developer, you decide which Microsoft Graph permissions to request for your app based on the access scenario and the operations you want to perform.

Permissions naming pattern

Microsoft Graph permissions are named in the following pattern:

{resource}.{operation}.{constraint}

Value	Description	Examples
`{resource}`	Refers to a Microsoft Graph resource to which the permission allows access. For example, the `user` resource.	`User`, `Application`, or `Group`
`{operation}`	Refers to the Microsoft Graph API operations that are allowed on the data that is exposed by the resource. For example, `Read` for read operations only, or `ReadWrite` for read, create, update, and delete operations.	`Read`, `ReadBasic`, `ReadWrite`, `Create`, `Manage`, or `Migrate`
`{constraint}`	Determines the potential extent of access an app has within the directory. This value may not be explicitly declared. When undeclared, the default constraint is limited to data that's owned by the signed-in user.	`All`, `AppFolder`, `OwnedBy`, `Selected`, `Shared`, `Hidden`

Examples:

User.Read - Allows the app to read information about the signed-in user.
Application.ReadWrite.All - Allows the app to manage all applications in the tenant.
Application.ReadWrite.OwnedBy - Allows the app to manage only the applications that it creates or owns.
Group.Create - Allows the application create new groups, but not modify or delete them.
Member.Read.Hidden - Allows the app to read hidden memberships.

For the full list of permissions exposed by Microsoft Graph, see the Microsoft Graph permissions reference.

Understand delegated vs. application permissions

The permissions for your app to access resources, like Microsoft Graph data, can be granted in two ways:

Delegated permissions: Also called scopes, allow users with permissions to consent for the app to act on their behalf.
Application permissions: Also called app roles, allow the app to access data on its own, without a signed-in user.

Users or administrators must grant or consent to the permissions for an app request. When a user signs into an app, the app must specify the permissions, it needs to be included in the access token. These permissions:

May be preauthorized for the application by an administrator.
May be consented by the user directly.
If not preauthorized, may require administrator privileges to grant consent. For example, this may be required for permissions with a greater potential security impact.

Follow best practices for requesting permissions

When building an app that uses Microsoft Entra ID to provide sign-in and access tokens for secured endpoints, there are a few best practices you should follow:

Only ask for the permissions required for your current app functionality. Don't request user consent for permissions that you haven't yet implemented for your application.
When requesting permissions for app functionality, you should request the least-privileged access appropriate. For example, if an app analyzes a user's email but takes no action on the mailbox, you shouldn't request the more permissive Mail.ReadWrite when Mail.Read will work.
Apps should gracefully handle scenarios where the user doesn't grant consent to the app when permissions are requested. In the case where an app doesn't receive an access token with the required permissions, it should explain the situation to the user with options on how to remedy the issue.