Important: We are no longer accepting new registrations for the Play EMM API. Learn more.

Identities and user accounts

Identity provisioning (or account provisioning) is the process of setting up accounts and establishing connections among the three systems that hold user data, and in some cases setting up connections between users and their devices.

In an Android enterprise environment, three different systems hold user account information:

The organization's user directory is the definitive source of information about users.
You (the EMM solution provider) must maintain at least a minimal directory of the organization's users.
Google maintains some information about managed Google Play Accounts and Google Accounts to provide app management through Google Play.

A Users resource represents an account associated with an enterprise. The account can be specific to a device, or can be associated with an individual who has multiple devices and uses the account across them all. The account can provide access to managed Google Play only, or to other Google services, depending on how you set up your customer's enterprise:

Managed Google Accounts are existing accounts that are managed by Google. These accounts require the customer to either use Google as their identity provider or link their organization's user directory to Google. For enterprises using managed Google Accounts, Google is responsible for authenticating the user during device provisioning.
Managed Google Play Accounts provide a way for enterprises to automatically create limited user accounts through their enterprise mobility management (EMM) solution provider. These accounts provide access to Managed Google Play only. The EMM is fully responsible for authenticating the user when needed. For managed Google Play Accounts enterprises, this is the only type of account available.

Table 1: Users API fields and methods

	managed Google Play Accounts	managed Google Accounts
Field
id
kind
accountIdentifier	A unique identifier that you create and map to the ID (`userId`) returned from Google Play. Don’t use personally identifiable information (PII).	Not set.
accountType	deviceAccount, userAccount	userAccount
displayName	The name you display in UI items, such as within Google Play. Don’t use personally identifiable information.	Not set.
managementType	emmManaged	googleManaged, emmManaged
primaryEmail	Not set.	This field is the primary key by which you manage synchronization from Google-managed domain accounts to user accounts in your system.
Methods
delete
generateAuthenticationToken
generateToken
get
getAvailableProductSet
insert
list
revokeToken
setAvailableProductSet
update

As part of our device enrollment improvements, we are transitioning to using managed Google Accounts for all Android Enterprise devices used by an employee with a corporate identity.

For new enrollments, we now recommend using managed Google Accounts over managed Google Play Accounts. While we continue to support managed Google Play Accounts for existing users, they only provide access to the managed Google Play store. Managed Google Accounts give users access to the full suite of Google services and cross-device features.

Enrollment improvements

Managed Google Accounts establish a user's identity with Google. This enables cross-device experiences, such as task hand-off, notifications, and nearby sharing. These features are increasingly important in the enterprise space, where users often use multiple devices.

Enterprises that don't use Google as their identity provider are now strongly recommended to link their existing identity provider to Google. This enables the creation of managed Google Accounts for employees during the binding process. Enterprises should use the same identity provider for this as they use with their EMM.

We've implemented the following changes:

The authentication of the end user during device enrollment is now handled by Google/Android. The EMM's Device Policy Controller (DPC) requires that Android authenticate the user at the appropriate point, and Android then returns the identity of the logged-in user to the DPC.
The EMM must pass an enrollment token to Android when requesting user authentication. This token is returned by an API call to the Android Enterprise API and might be encoded within the QR, NFC, or zero-touch enrollment payload.

While Android now handles authentication and provides the user identity to the EMM, it is still the EMM's responsibility to map the user identity to the correct group or organizational structure. This mapping is essential for applying the appropriate policies to the device. Therefore, enterprises must continue to link their organization's user directory to their EMM.

IT admins can enable or disable the new Google-provided end-user authentication feature. To provide users with the best experience, including cross-device features, we recommend that IT admins link their organization's user directory to Google. Without this link, users will have managed Google Play Accounts and won't have access to cross-device experiences.

A new requirement for all EMMs is to provide additional information when creating enrollment and sign-in tokens. Specifically, you must now indicate whether a device is userless (such as a kiosk or dedicated device) or not.

Benefits

The new process offers the following key improvements:

Simplified enrollment: It reduces the number of manual steps and complexity compared to standard methods.
Google Account support: You can now use Google Accounts with all provisioning methods. This removes the needs for managed Google Play Accounts.
Enhanced user experience: With managed Google Accounts, you get a richer Android experience that includes powerful cross-device features like sharing and copy-paste.

Implementation of user accounts

To learn how to proceed with this new enrollment flow, see Implement user accounts.

Lifecycle of managed Google Accounts

For organizations that use Google Accounts, user accounts in an EMM’s solution mirror existing user accounts associated with another Google service (such as Google Workspace). These accounts are googleManaged (Table 1) because Google's backend services are the source for the creation of and information about the account.

As an EMM, you can provide mechanisms in your console to facilitate the creation and ongoing synchronization of user accounts held in your system with their Google domain account sources using tools such as Google Cloud Directory Sync (GCDS) and the Google Admin SDK Directory API. for an overview of various approaches. The Google-managed domain identity model requires that the user account exists in the context of your solution (EMM console, EMM server, perhaps in a datastore) before it can be provisioned on any of the user's devices in the context of a work profile.

During identity provisioning, the organization's Google-managed domain is populated with user accounts. In some cases, users' existing online identities (for example, their Microsoft Exchange accounts) are synchronized with their Google Accounts.

Synchronize customer accounts

In a Google Accounts deployment, the organization can use the GCDS tool to synchronize the data in their G Suite domain with the data in their LDAP directory. Alternatively, you can use GCDS to do this on the organization's behalf, if the organization gives you access.

The GCDS tool calls the Google Directory API and synchronizes usernames, but not passwords.

If the organization uses Microsoft Active Directory and wants to keep users' G Suite passwords in sync with their Active Directory passwords, then they—or you—can use the G Suite Password Sync (GSPS) tool with GCDS.

For GCDS instructions for admins, see Prepare your G Suite domain for synchronization.

Google Directory API

In a Google Accounts deployment, you can use the Google Directory API to synchronize active directories, passwords, or both:

Using the Directory API for directory-only sync. If you have read-only access to the organization's managed Google domain, you can use the Google Directory API to get Google Account information, such as usernames (but not passwords) from Google. Because you're unable to write any data to users' Google Accounts, the organization is fully responsible for account life cycles.

Scenario 1 and SAML-based SSO authentication scenarios describe this situation more fully.

For information about using the Directory API in this way, see Retrieve all account users in the Directory API documentation.
Using the Directory API for directory and optional password sync. If you have read-write access to the organization's managed Google domain, you can use the Google Directory API to get usernames, passwords, and other Google Account information. You can update this information and sync it with your own database, and you might have full or partial responsibility for account life cycles, depending on the solution that you're offering to your customer.

Scenario 2 describes this situation more fully.

For more about using the Directory API to manage user account information, see the Directory API: User Accounts developer's guide.

Google Accounts scenarios

A few typical Google Accounts identity-provisioning scenarios are described in the following section.

Scenario 1: Customer responsible for account life cycles

Using the Directory API (with read-only access) and GCDS

In this scenario, your customer creates and maintains Google Accounts for its users.

You get user account information from the organization's LDAP directory, and you correlate this with Google Account data that you get from Google using the Google Directory API.

The organization is fully responsible for account life cycles. For example, when a new Google Account is created, the organization adds the user to their LDAP directory. The next time you sync your database to the LDAP directory, your database receives information about this new user.

In this scenario:

You have read-only access to Google Accounts.
Your database acquires Google Account names, but no LDAP usernames or passwords.
You use the Google Directory API to get basic account information for your customer's users. (The information available to you is the non-writable information returned by a Users.get request). You use this information to verify that users' Google Accounts exist so that users can authenticate to their devices.
Your customer uses the GCDS tool to do a one-way sync to populate users' Google Accounts. (The organization probably also uses GCDS for their own ongoing synchronization after identity provisioning is complete.) Optionally, the organization can also use the GSPS tool to sync not only usernames, but also passwords.

Scenario 2: EMM responsible for account life cycles

Using the Directory API with
read-write access

In this scenario, you handle the process of creating Google Accounts on behalf of your customer, and you're responsible for the users' account life cycles.

For example, when user information changes in the organization's LDAP directory, you're responsible for updating the user's Google Account. GCDS is not used in this scenario.