New graph API consent permissions

Today we're glad to announce a few updates to our Azure AD Graph API permission scopes.  Some of these new permission scopes can be consented by non-admin users, enabling greater reach for your applications.  This is something the team is really excited about. 

The new permission scopes

In addition to the four existing permission scopes (the four listed at the bottom in the Azure Management Portal screenshot below), we've now added four new delegated scopes (and an additional app-only permission scope which is not shown).

In order to enable a number of key scenarios, developers previously needed to request privileged permissions that required an administrator to consent.  By introducing a new set of more granular permissions, we've allowed some key scenarios to be enabled for your app that can either be consented by a non-admin user. For example with the "Read all users' basic profiles" you can now build a people picking experience to control access to resources in your application, that non-admin users can consent to. While introducing this additional flexibility for you, we still ensure that privileged operations can only be consented by an administrator. This allows you to create applications that can reach a larger audience, while protecting privileged operations . Additional permissions around groups still require admin consent, but are now less privileged in nature than the pre-existing permission scopes. 


Permission scopes required

Admin consent required?

People picker - core to many applications is the ability to pick users to control access to resources in your application.

Read all users' basic profiles


Org chart navigator -  see a user's reports and their management chain.

Read all users' full profiles


Groups and memberships viewer

Read all users' basic profiles

Read all groups


Group management service that allows users to create, manage and delete groups.  (NOTE the user of the app would need to be in a role that allows for group creation and management).

Read all users' basic profiles

Read and write all groups



So you might ask - how can we allow an end user to consent to release  information to an application about other users in their organization?  The new permission "Read all users' basic profiles" (which has the scope claim value "user.readbasic.all") releases only limited information about other users. When querying the user entity, it exposes only enough information to make a people picker useful, without releasing information like phone numbers or location.  To be specific, it allows the calling application to get the first name, last name, display name, photo and email address of other users in the organization of the signed-in user.

We've also updated a few of the existing permission scopes:

  1. We've restricted the "Read and write directory data" permission so that it no longer allows the application to reset other user passwords.
  2. We've extended the "Sign in and read user profile" permission to also allow the application to read some basic information about the company (company display name and verified domains) through the tenantDetails entity.  NOTE: For any users who have already consented to this permission (prior to this update), the application will not have access to the tenantDetails entity.

Great new permissions topic

To go with this release, we've updated our Azure AD Graph API permissions topic.  This topic goes into greater detail on all our permission scopes, describing:

  • Concepts such as delegated vs app-only permissions, and full vs basic profiles for users and groups.
  • Permission scope details highlighting what each scope is capable of, if it's app-only or delegated, and whether it requires an admin to consent.

What's next?

This change not only introduced new permission scopes, but also an update to our underlying platform that will allow our team to introduce additional permission scopes more quickly.  New scopes will be driven by developer and application scenarios and by our principles to align permission scopes along the entities in our API and to explicitly split out new permission scopes for privileged operations (such as changing or resetting passwords).

What do you think?

As always, we'd love to hear more from you all.  Are these new permission scopes useful?  Are there any permission scopes you'd like to see and why those are important for your scenarios?