Domain-wide delegation best practices

As an administrator, you can use domain-wide delegation to allow internal and third-party apps to access your users’ Google Workspace data, bypassing end user consent. To do this, you create a service account in the Google Cloud console and delegate domain-wide authority to the account in your Google Admin console. You can also provide limited API scopes to the service account in the Admin console. For more information about domain-wide delegation, go to Control API access with domain-wide delegation.

Manage and secure service accounts

Identity and Access Management (IAM) provides guidelines for using service accounts to limit access and protect against privilege escalation and non-repudiation threats. To review the guidelines, go to Best practices for using service accounts. 

While all recommendations in the guide apply to protect service accounts that use domain-wide delegation, some highlighted practices are as follows:

	Use direct service account access or OAuth consent instead Avoid using domain-wide delegation if you can accomplish your task directly using a service account or by using OAuth consent. If you can't avoid using domain-wide delegation, restrict the set of OAuth scopes that the service account can use. Although OAuth scopes don't restrict which users the service account can impersonate, they restrict the types of user data that the service account can access. Avoid using domain-wide delegation
	Restrict service account key creation and upload Use organization policies to restrict key creation and upload for service accounts with domain-wide delegation. This limits service account impersonation through service account keys. Don't let users create or upload service account keys
	Disable automatic role grants ​​for default service accounts Service accounts that are created by default are granted the Editor role, which allows the account to read and modify all resources in the Google Cloud project. You can disable automatic role grants for default service accounts to ensure that they don’t automatically get the Editor role and can’t easily be exploited by a malicious user.  Don't use automatic role grants for default service accounts
	Limit lateral movement Lateral movement is when a service account in one project has permission to impersonate a service account in another project. This can result in unintended access to resources. Use "lateral movement insights" to detect and limit lateral movement through impersonation.  Use lateral movement insights to limit lateral movement
	Limit access to service accounts with domain-wide delegation Don't let a user change the allow policy of a service account if the service account has more privileges than the user. Use IAM roles to limit access to service accounts with domain-wide delegation grants.  Avoid letting users change the allow policies of more privileged service accounts

Protect service accounts from insider risk

Use domain-wide delegation only when you have a critical business case that requires an app to bypass user consent to access Google Workspace data. Try alternatives such as OAuth with user consent or use Marketplace apps. For more information, go to Google Workspace Marketplace. 

Follow these best practices to protect service accounts with domain-wide delegation privileges from insider risk:

	Grant access to essential privileges only Ensure that service accounts with domain-wide delegation have only the essential privileges needed to perform their intended functions. Do not give access to non-essential OAuth scopes.
	Host service accounts in dedicated Google Cloud projects Ensure that service accounts with domain-wide delegation are hosted in dedicated Google Cloud projects. Do not use those projects for other business needs.
	Avoid using service account keys Using service account keys is not necessary to perform domain-wide delegation. Use the signJwt API instead.  Avoid using service account keys for domain-wide delegation
	Restrict access to projects that have domain-wide delegation Minimize the number of people that have edit access to Google Cloud projects with domain-wide delegation set up. You can use Cloud Asset Inventory API to understand who has access to service accounts. For example, use Cloud Shell to run: gcloud asset get-effective-iam-policy --scope=organizations/<ORG_ID> --names=//iam.googleapis.com/projects/<PROJECT_ID>/serviceAccounts/ <SERVICE_ACCOUNT_ID> ORG_ID: Your Google Cloud organization ID. Learn more PROJECT_ID: ID of the Google Cloud project the service account resides under. Learn more SERVICE_ACCOUNT_ID: ID of the service account. The ID is listed under Client ID on the Admin console domain-wide delegation page, or in the service account’s email address. Learn more Look for permissions or roles such as iam.serviceAccountTokenCreator or iam.serviceAccountKeyAdmin owner and editor to understand who has direct or inherited permissions to the service account. Understand who has access to Google Cloud service accounts

Related topics

• Security checklists
• Cloud Shell
• Control API access with domain-wide delegation