All Google services, including Google Cloud, Google Marketing Platform,and Google Ads, rely onGoogle Sign-In to authenticate users. This document explains the domain model that GoogleSign-In relies on for authentication and identity management. The domain modelhelps you understand how Google Sign-In works in a corporate context, howidentities are managed, and how you can facilitate an integration with anexternal identity provider (IdP). The following diagram shows how these entitiesinteract.

As this diagram shows, at the center of the model is theGoogle identity,which is used by Google Sign-In. The Google identity is related to a number ofother entities that are all relevant in the context of managing identities:

• Google for consumers contains the entities that are relevant forconsumer-focused usage of Google services such as Gmail.
• Google for organizations contains entities managed byCloud Identity orGoogle Workspace.These entities are the most relevant for managing corporate identities.
• Google Cloud contains the entities that are specific toGoogle Cloud.
• External contains entities that are relevant if you integrate Googlewith an external IdP.

Solid arrows in the diagram indicate that entities reference each otheror contain each other.In contrast, dashed arrows denote a federation relationship.

Google identities

Identities, users, and user accounts play a crucial role in identitymanagement. The three terms are closely related and sometimes even usedinterchangeably. However, in the context of identity management, it's worthwhileto differentiate between the concepts:

• Anidentity is a name that uniquely identifies the person who isinteracting with a Google service. Google uses email addresses for thispurpose. A person's email address is considered that person's Googleidentity.

  The process of verifying the association between a person and an identityis called authentication or sign-in, making the person prove that this isindeedtheir identity.

  A person might have multiple email addresses. Because Google servicesuse an email address as identity, such a person would be considered to havemultiple identities.

• Auser account is a data structure that keeps track ofattributes, activities, and configurations that should be applied whenevera certain identity interacts with a Google service. User accounts are notcreated on the fly, but need to be provisioned before the first sign-on.

  User accounts are identified by an ID that is not exposed externally. Userinterfaces or APIs therefore require you to reference the user accountindirectly by its associated identity, such asalice@gmail.com. Despitethis indirection, any data and configuration details are associated withthe user account, not with the identity.

In most cases, there is a one-to-one relationship between user accounts andidentities, which makes them easy to conflate. However, this is not always thecase, as the following edge cases illustrate:

• The relationship between user accounts and identities is not fixed.You can change the primary email address of a user account, whichassociates a different identity with the user.

  As a Cloud Identity or Google Workspace administrator, youcan even swap the primary email addresses of two users. For example, if youswapped the primary email addresses of Alice (alice@example.com) and Bob(bob@example.com), then Alice would be using Bob's previous user accountand Bob would be using Alice's previous user account. Because data andconfiguration is associated with the user account and not the identity,Alice would also now use Bob's existing configuration and data (and Bobwould now use Alice's configuration and data). The following figure showsthis relationship.

  

  In a non-federated setup, you'd also have to reset passwords in order forAlice and Bob to swap user accounts. In a federated setup where Alice andBob use an external IdP to authenticate, resetting passwords wouldn't benecessary.

• The relationship between identity and users might not be 1:1. Aconsumer accountcan intentionally be associated with multiple identities,as in the following diagram.

  It's also possible that one identity refers to two different user accounts.We recommend that you avoid this situation, but it can arise in the case ofaconflicting user account.In such a case, a user is shown a ballot screen during authentication inwhich they select the user account to use.

  

Google differentiates between two types of user accounts,consumer useraccounts andmanaged user accounts. The following sections cover both typesof user accounts and their related entities in more detail.

Google for consumers

If you own a Gmail email address likealice@gmail.com, then your Gmailaccount is aconsumer account. Similarly, if you use theCreate accountlink on the Google Sign-In page and during sign-up you provide a custom emailaddress that you own, such asalice@example.com, then the resulting account isalso a consumer account.

Consumer account

Consumer accounts are created by self-service and are primarily intended to beused for private purposes. The person who created the consumer account has fullcontrol of the account and any data created by using the account. The emailaddress that that person used during sign-up becomes the primary email addressof the consumer account and serves as its identity. That person canadd email addresses to the consumer account. These email addresses serve as additional identitiesand can also be used for signing in.

When a consumer account uses a primary email address that corresponds to theprimary or secondary domain of aCloud Identity or Google Workspace account,then the consumer account is also referred to as anunmanaged user account.

A consumer account can be a member of any number ofgroups.

Google for organizations

If your organization uses Google services, it's best to usemanaged useraccounts. These accounts are calledmanaged because their lifecycle andconfiguration can be fully controlled by the organization.

Managed user accounts are a feature of Cloud Identity andGoogle Workspace.

Cloud Identity or Google Workspace account

A Cloud Identity or Google Workspace account is the top-levelcontainer for users, groups, configuration, and data. A Cloud Identityor Google Workspace account is created when a company signs up forCloud Identity or Google Workspace and corresponds to the notionof atenant.

Cloud Identity and Google Workspace share a common technicalplatform. Both products use the same set of APIs and administrative tools andshare the notion of an account as a container for users and groups; thatcontainer is identified by a domain name. For the purpose of managing users,groups, and authentication, the two products can largely be consideredequivalent.

An account contains groups and one or more organizational units.

Important: A Cloud Identity or Google Workspace account is not auser account, but a directory of user accounts.

Organizational unit

An organizational unit (OU) is a sub-container for user accounts that lets yousegment the user accounts defined in the Cloud Identity orGoogle Workspace account into disjoint sets to make them easier tomanage.

Organizational units are organized hierarchically. Each Cloud Identityor Google Workspace account has a root OU, under which you cancreate more OUs as needed.You can also nest your OUs.

Cloud Identity and Google Workspace lets you apply certainconfigurations by OU, such aslicense assignment or2-step verification.These settings automatically apply to all users in the OU and are also inheritedby child OUs. Organizational units therefore play a key role in managingCloud Identity and Google Workspace configuration.

A user account cannot belong to more than one OU, which makes OUs differentfromgroups.Although OUs are useful for applying configuration to user accounts, they arenot intended to be used for managing access. For managing access, we recommendthat you use groups.

Although OUs resembleGoogle Cloud folders,the two entities serve different purposes and are unrelated to another.

Managed user account

Managed user accounts work similarly to consumer user accounts, but they can befully controlled by administrators of the Cloud Identity orGoogle Workspace account.

The identity of a managed user account is defined by its primary email address.The primary email address has to use a domain that corresponds to one of theprimary, secondary, or alias domains added to the Cloud Identity orGoogle Workspace account. Managed user accounts can have additionalalias email addresses and arecovery email address,but these addresses aren't considered identities and cannot be used for signingin. For example, if Alice usesalice@example.com as her primary email addressand has configuredally@example.com as an alias email address andalice@gmail.com as a recovery email address, then the only email address Alicecan use for signing in isalice@example.com.

Managed user accounts are contained by an organizational unit and can be amember of any number of groups.

Managed user accounts are intended to be used by human users rather thanmachine users. A machine user account is a special kind of account used by anapplication or a virtual machine (VM) instance, not a person. For machine users,Google Cloud providesservice accounts.(Service accounts are discussed in more detail later in this document.)

Note: In the context of Google Workspace, Cloud Identity, andGoogle Cloud, themanaged prefix is sometimes left out in otherdocumentation, and managed user accounts are simply referred to asuseraccounts. In contrast,consumer user accounts are always qualified with theconsumer prefix.

Group

Groups let you bundle multiple users. You can use groups to manage a mailinglist or to apply common access control or configuration to multiple users.

Cloud Identity and Google Workspace identify groups by emailaddress—for example,billing-admins@example.com. Similar to a user's primaryemail address, the group email address must use one of the primary, secondary,or alias domains of the Cloud Identity or Google Workspaceaccount. The email address doesn't need to correspond to a mailbox unless thegroup is used as a mailing list. Authentication still happens using the user'semail rather than the group email, so a user can't sign in using a group emailaddress.

A group can have the following entities as members:

• Users (managed users or consumer accounts)
• Other groups
• Service accounts

Unlike an organizational unit, groups don't act as a container:

• A user or group can be a member of any number of groups, not just one.
• Deleting a group does not delete any of the member users or groups.

Groups can contain members from any Cloud Identity orGoogle Workspace account as well as consumer accounts. You can use thedisallow members outside your organization setting to restrict members to user accounts of the same Cloud Identityor Google Workspace account.

External identities

By federating a Cloud Identity or Google Workspace account withan external IdP, you can enable employees to use their existing identity andcredentials to sign in to Google services.

At the most basic level, federation entailssetting up single sign-on by using SAML,which links identities in Cloud Identity or Google Workspace toidentities managed by your external IdP. To link an identity likealice@example.com and enable it for single sign-on to Google, you must meettwo prerequisites:

• Your external IdP must recognize the identityalice@example.com andallow it to be used for single sign-on.
• Your Cloud Identity or Google Workspace account mustcontain a user account that usesalice@example.com as its identity. Thisuser account must exist before the first single sign-on attempt.

Instead of manually creating and maintaining user accounts inCloud Identity or Google Workspace, you can automate the processby combining SAML-based single sign-on with automatic user provisioning. Theidea of automatic user provisioning is to synchronize all or a subset of theusers and groups from an external authoritative source to Cloud Identityor Google Workspace.

Depending on your choice of IdP, SAML-based single sign-on and automatic userprovisioning might be handled by the same software component or might requireseparate components. The domain model therefore distinguishes between aSAMLidentity provider and anexternal authoritative source.

External SAML identity provider

The external IdP is the sole system for authentication and provides a singlesign-on experience for your employees that spans applications. It is external toGoogle and therefore referred to as anexternal identity provider.

When youconfigure single sign-on,Cloud Identity or Google Workspace relays authentication decisionsto a SAML IdP. In SAML terms,Cloud Identity or Google Workspace acts as aservice provider that trusts the SAML IdP to verify a user's identity on its behalf.

Commonly used external IdPs include Active Directory Federation Services (ADFS), Entra ID, Okta, or Ping Identity.

External authoritative source

The authoritative source for identities is the sole system that you use tocreate, manage, and delete identities for your employees. It's external toGoogle and therefore referred to as anexternal authoritative source.

From the external authoritative source, user accounts and groups can beautomatically provisioned to Cloud Identity or Google Workspace.Provisioning might be handled by the authoritative source itself, or by means ofprovisioning middleware.

For automatic user provisioning to be effective, users have to be provisionedwith an identity that your SAML IdP recognizes. If you map between identities(for example, if you map the identityalice@example.com inCloud Identity or Google Workspace tou12345@corp.example.com inyour SAML IdP), then both the SAML IdP and the provisioning middleware mustperform the same mapping.

External user account

External identity providers are assumed to have the concept of a user accountthat keeps track of the name, attributes, and configuration.

The authoritative source (or provisioning middleware) is expected to provisionall (or a subset of) external user accounts to Cloud Identity orGoogle Workspace in order to facilitate a sign-on experience. In manycases, it's sufficient to propagate only a subset of the user's attributes (suchas email address, first name, and last name) to Cloud Identity orGoogle Workspace so that you can limit data redundancy.

External group

If your external IdP supports the notion of a group, then you can optionallymap these groups to groups in Cloud Identity orGoogle Workspace.

Mapping and auto-provisioning groups is optional and not required for singlesign-on, but both steps can be useful if you want to reuse existing groups tocontrol access in Google Workspace or Google Cloud.

Google Cloud

Like other Google services, Google Cloud relies on Google Sign-In toauthenticate users. Google Cloud also closely integrates withGoogle Workspace and Cloud Identity to allow you to manageresources efficiently.

Google Cloud introduces the notion of organization nodes, folders, andprojects. These entities are primarily used for managing access andconfiguration, so they are only tangentially relevant in the context of identitymanagement. However, Google Cloud also includes an additional type of useraccount: service accounts. Service accounts belong to projects and play acrucial role in identity management.

Organization node

Anorganization is the root node in theGoogle Cloud resource hierarchy and a container for projects and folders. Organizations let you structureresources hierarchically and are key to managing resources centrally andefficiently.

Each organization belongs to a single Cloud Identity orGoogle Workspace account. The name of the organization is derived from theprimary domain name of the corresponding Cloud Identity orGoogle Workspace account.

Note: Google Cloud organizations are unrelated toorganizations in Google Marketing Platform.

Folder

Folders are nodes in the Google Cloud resource hierarchy and can containprojects, other folders, or a combination of both. You use folders to groupresources that share commonIdentity and Access Management (IAM) policies ororganizational policies.These policies automatically apply to all projects in the folder and are alsoinherited by child folders.

Folders are similar, but unrelated, toorganizational units.Organizational units help you manage users and apply common configuration orpolicies to users, whereas folders help you manage Google Cloud projects and applycommon configuration or policies to projects.

Project

A project is acontainer for resources.Projects play a crucial role for managing APIs, billing, and managing access toresources.

In the context of identity management, projects are relevant because they arethe containers for service accounts.

Service account

Aservice account (or Google Cloud service account) is a special kindof user account that is intended to be used by applications and other types ofmachine users.

Each service accountbelongs to a Google Cloud project.As is the case withmanaged user accounts,administrators can fully control the lifecycle and configuration of a serviceaccount.

Service accounts also use an email address as their identity, but unlike withmanaged user accounts, the email address always uses a Google-owned domain suchasdeveloper.gserviceaccount.com.

Service accounts don't participate in federation and also don't have apassword. On Google Cloud, youuse IAM to control the permission that a service account has for a compute resource such as avirtual machine (VM) or Cloud Run function, removing the need to managecredentials. Outside of Google Cloud, you can useservice account keys to let an application authenticate by using a service account.

Kubernetes service account

Kubernetes service accounts are aconcept of Kubernetes and are relevant when you useGoogle Kubernetes Engine (GKE).Similar to Google Cloud service accounts, Kubernetes service accounts aremeant to be used by applications, not humans.

Kubernetes service accounts can be used to authenticate when an applicationcalls the Kubernetes API of a Kubernetes cluster, but they cannot be usedoutside of the cluster. They are not recognized by any Google APIs and aretherefore not a replacement for a Google Cloud service account.

When you deploy an application as a KubernetesPod,you canassociate the Pod with a service account.This association lets the application use the Kubernetes API withouthaving to configure or maintain certificates or other credentials.

By usingWorkload Identity,you can link a Kubernetes service account to a Google Cloud serviceaccount. This link lets an application also authenticate to Google APIs,again without having to maintain certificates or other credentials.

What's next

• Review ourreference architectures for identity management.