Working with users in Microsoft Graph

You can use Microsoft Graph to build compelling app experiences based on users and their relationships with other objects. For example, their relationships with other users and groups, group memberships, and the resources they access such as their mails, calendars, files, and administrative roles.

You can access users through Microsoft Graph in two ways:

• By their ID or userPrincipalName, /users/{id} or /users/{userPrincipalName}
• By using the /me alias for the signed-in user, which is the same as /users/{signed-in user's id}

Common API operations

Authorization and privileges

Microsoft Graph supports the use of delegated and application permissions to manage user operations. For more information, see Delegated vs Application permissions and the corresponding API reference documentation for the permissions required for each operation.

Some user operations can be performed by the signed-in user against their own details. For such operations, the user can grant the app the Microsoft Graph permissions to access their own details. The User.ReadBasic.All, User.Read, and User.ReadWrite permissions are such permissions.

Other operations, including managing details for other users, require administrative privileges that are granted through other Microsoft Graph permissions and Microsoft Entra roles. In addition, some operations are considered sensitive and only limited administrators can perform them. For more information, see Who can reset passwords and Who can update sensitive attributes sections.

Default user permissions in Microsoft Entra ID

There are two types of users in Microsoft Entra ID - members and guests. Initially, member users are created natively in the tenant. Guest users join the tenant through redeeming their invitation and access the tenant as business-to-business (B2B) collaboration guests.

The set of default permissions depends on whether the user is a member or a guest user. For more information about what member users and guest users can do, see What are the default user permissions in Microsoft Entra ID?.

Default user permissions in external tenants

There are also default permissions for customers in Microsoft Entra ID in external tenants. The following table indicates the API operations that enable customers to manage their own profile.

The user ID or userPrincipalName is always the signed-in user's.

Users basic profile

The User.ReadBasic.All permission constrains app access to reading a limited set of properties for other users' work or school accounts. This basic profile includes only the following properties:

• displayName
• givenName
• id
• mail
• photo
• securityIdentifier
• surname
• userPrincipalName

In addition, the following scenario-specific permissions also allow apps to read the basic user profile which contains mostly identifier-related properties: User-Mail.ReadWrite.All, User-PasswordProfile.ReadWrite.All, User-Phone.ReadWrite.All, User-LifeCycleInfo.Read.All, User-LifeCycleInfo.ReadWrite.All.

Sensitive actions

The following actions against the user object are considered sensitive and might be locked down to only specific administrators. All users can read the sensitive properties.

Who can perform sensitive actions

Some administrators can perform the preceding sensitive actions for some users.

In the following table, the columns list the roles that can perform sensitive actions. The rows list the roles for which the sensitive action can be performed upon.

The following table is for roles assigned at the scope of a tenant. For roles assigned at the scope of an administrative unit, further restrictions apply.

Who can reset passwords

In the following table, the columns list the roles that can reset passwords and invalidate refresh tokens. The rows list the roles for which their password can be reset. For example, a Password Administrator can reset the password for Directory Readers, Guest Inviter, Password Administrator, and users with no administrator role. If a user is assigned any other role, the Password Administrator cannot reset their password.

The following table is for roles assigned at the scope of a tenant. For roles assigned at the scope of an administrative unit, further restrictions apply.

The ability to reset a password includes the ability to update the following sensitive properties required for self-service password reset:

• businessPhones
• mobilePhone
• otherMails

Common properties

The following represent the default set of properties that are returned when getting a user or listing users. These are a subset of all available properties. To get more user properties, use the $select query parameter. Learn how to use the $select query parameter and see properties that support the $select query parameter.

For details and a list of all the properties, see the user object.

User and group search limitations for guest users in organizations

User and group search capabilities allow the app to search for any user or group in an organization's directory by performing queries against the /users or /groups resource set (for example, https://graph.microsoft.com/v1.0/users). Both administrators and users who are members have this capability; however, guest users don't.

If the signed-in user is a guest user, depending on the permissions an app has been granted, it can read the profile of a specific user or group (for example, https://graph.microsoft.com/v1.0/users/241f22af-f634-44c0-9a15-c8cd2cea5531); however, it can't perform queries against the /users or /groups resource set that potentially returns more than a single resource.

With the appropriate permissions, the app can read the profiles of users or groups that it obtains by following links in navigation properties; for example, /users/{id}/directReports or /groups/{id}/members.

Properties not returned by default

Some properties of the user object aren't returned by default and must be specified in a $select query parameter. For example, birthday and skills. Refer to the properties table of the user entity to identify properties that are returned only when you $select.

Properties stored outside the main data store

While the user resource data is mostly stored in Microsoft Entra ID, some of its properties, like skills, are stored in SharePoint Online. In most instances, you can't specify these properties in the same Create or Update request body as other user properties.

Properties stored outside the main data store also aren't supported as part of change tracking. Therefore, a change to any of these properties doesn't result in an object showing up in the delta query response.

The following properties on the user object are stored outside the main data store: signInActivity, cloudLicensing, mailboxSettings, deviceEnrollmentLimit, print, aboutMe, birthday, hireDate, interests, mySite, pastProjects, preferredName, responsibilities, schools, skills.

Related content

• What are the default user permissions in Microsoft Entra ID?