Google Workspace Domain-Wide Delegation Security Guide

Domain-wide delegation lets a single Google Cloud service account act as any user in a Google Workspace tenant, without those users ever seeing a consent screen. Google's own documentation describes it as a way to grant client apps access to Workspace users' data "without user consent", and its Cloud IAM guidance warns that this includes super administrators. That makes every delegated service account a tenant-wide non-human identity whose security depends on a Google Cloud project that the Workspace team often does not control. This guide explains how delegation is configured and enforced, who can change it, how to detect misuse and what a defensible baseline looks like. It is written for Workspace administrators, Google Cloud platform teams and the identity and detection engineers who sit between them.

Key takeaways

Scopes limit data types, not people. A delegation grant restricts which APIs the service account may call, but Google states that scopes do not limit which users can be impersonated.
The control plane is split across two consoles. A super admin authorises the client ID in the Admin console, but anyone who can mint tokens or keys for that service account in Google Cloud can use the grant.
Keys are optional and should not exist. Delegation does not require downloadable service account keys; use the IAM Credentials signJwt route and block key creation with organisation policy.
Delegated calls look like the user. API activity is recorded against the impersonated user, so detection must correlate the Admin audit event, the OAuth token log and Cloud audit logs.
Every grant needs an owner and an end date. Migration and sync tools are the classic leftovers; Google recommends deleting clients once a migration is complete.

How identity and access work in Google Workspace domain-wide delegation

Delegation joins two identity systems. The service account lives in a Google Cloud project and is governed by Cloud IAM. The grant that lets it act inside Workspace lives in the Admin console, under Menu > Security > Access and data control > API controls > Manage Domain Wide Delegation. The service account itself never becomes a Workspace user and, as Google notes, cannot own Workspace assets such as Drive files.

The token flow, as documented in Google's OAuth 2.0 for Server to Server Applications page, works like this:

The application builds a JWT with iss set to the service account email, sub set to the email of the user to impersonate, scope listing the space-delimited OAuth scopes, and aud set to https://oauth2.googleapis.com/token.
The JWT is signed with RS256. The exp claim can be at most one hour after iat.
Google's token endpoint checks that the client ID has a delegation grant covering every requested scope, then issues an access token for that user (the documented example lifetime is 3,600 seconds).
The application calls Gmail, Drive, Calendar or Admin SDK APIs with that token. Access is limited to what the impersonated user can already reach and to the authorised scopes.

Two details matter for security. First, the grant is bound to the service account's OAuth client ID, not to a particular key. Hunters' Team Axon showed in 2023 ("DeleFriend") that a principal able to create keys for a service account could try scope combinations until one matched an existing delegation, without being a super admin. Second, because sub can be any user, a single grant with a Gmail scope is effectively read access to every mailbox in the tenant, executives and admins included.

Access route	Who consents	Whose data	Typical use	Main risk
User OAuth consent (third-party or internal app)	Each user, subject to API controls	The consenting user only	Productivity add-ons, AI assistants	Over-broad scopes, shadow apps
Domain-wide delegation to a service account	A super admin, once, for the tenant	Any user in the tenant	Migration, archiving, backup, sync, internal automation	Tenant-wide impersonation from a Cloud project
Domain-wide delegation to an OAuth client (no consent screen)	A super admin	Users who sign in to that app	Internal apps where consent prompts are unwanted	Silent access to restricted scopes
Admin SDK with an admin user's own OAuth token	The admin	Whatever the admin role allows	Scripts run by named admins	Token theft from the admin's device
Service account acting as itself	Not applicable	Only resources shared with it	Cloud resources, shared drives where supported	Lower blast radius; preferred where possible

For the Cloud side of the picture (roles, impersonation and key controls in general), see the Google Cloud IAM and Service Accounts Guide. This page focuses on what changes once a service account is delegated.

Admin roles and privileged access

Effective control over a delegated service account is held by two groups of people, and both must be treated as privileged.

Workspace super administrators: Google's help centre states that you must be a super administrator to add, edit or delete delegation clients. Scopes on an existing client can be edited, but the client ID cannot. If multi-party approval is enabled, authorising a client, editing its scopes or deleting it requires approval from a second super admin. Turn this on: it is the only built-in four-eyes control on delegation.
Service Settings administrators: this privilege manages API controls (trusted, limited and blocked apps, restricted services). It does not grant delegation, but a trusted app overrides service restrictions, so the role still deserves review.
Google Cloud principals on the delegated service account: Google's best-practice page lists iam.serviceAccountTokenCreator, iam.serviceAccountKeyAdmin and Owner or Editor roles as the grants that give direct or inherited ability to act as the account. Anyone with iam.serviceAccounts.setIamPolicy (Owner, Security Admin, Service Account Admin) can grant themselves that ability.
Project-level grants: a Token Creator role granted at project or folder level lets the holder impersonate every service account in that project. Google advises managing access on each service account individually.

The practical consequence is that a Cloud project editor can become, in effect, a Workspace-wide mail reader. Google recommends hosting delegated service accounts in dedicated Google Cloud projects used for nothing else, restricting edit access to those projects, and disabling automatic Editor grants to default service accounts. To review who can act as a delegated account, Google gives this Cloud Asset Inventory command:

gcloud asset get-effective-iam-policy --scope=organizations/ORG_ID --names=//iam.googleapis.com/projects/PROJECT_ID/serviceAccounts/SERVICE_ACCOUNT_ID

Treat the people it returns as holders of a tenant-wide privileged credential. See the Least Privilege Techniques Guide for techniques to keep that list short.

Integrations, API tokens and service accounts

Most delegation grants come from a short list of integration types. Each has a different minimum scope set and a different expected lifetime.

Integration type	Typical scopes requested	Narrower alternative to ask for	Expected lifetime
Mail migration or archiving	Full Gmail (`https://mail.google.com/`), `gmail.modify`	`gmail.readonly` for archive-only tools	Weeks; delete after cut-over
Backup and e-discovery	Gmail, `drive`, Calendar, Contacts	Read-only variants where restores are not needed	Long-lived; review quarterly
Signature or calendar management	`gmail.settings.basic`, `calendar`	Settings-only and `calendar.events` where sufficient	Long-lived
Directory sync and HR provisioning	Admin SDK directory scopes	Read-only directory scopes; avoid delegation by using a dedicated admin role where the API allows	Long-lived
Security tooling (email security, DLP)	Gmail read and modify, Drive read	Vendor-documented minimum per feature	Long-lived; third-party risk review

Google's help centre gives https://www.googleapis.com/auth/drive and https://www.googleapis.com/auth/calendar as example scopes and repeatedly says to keep them "as narrow as possible". When a vendor asks for full Gmail or full Drive, ask which feature needs it and whether a read-only scope would work.

Credential handling is where most avoidable exposure sits:

No downloadable keys: Google's domain-wide delegation best practices state that delegation does not require service account keys and recommend the signJwt API instead. The workload signs the JWT through the IAM Credentials API using its attached identity, so there is no private key file to leak.
Organisation policy: apply the "Disable service account key creation" and key upload constraints to the delegation projects. Google notes these are enforced by default for organisations created on or after 3 May 2024; older organisations must set them. See the Google Cloud Service Account Keys Security Guide.
Third-party vendors: where a SaaS vendor runs the service account in its own project, you cannot see its key hygiene. Ask how the vendor stores credentials for the account, whether it uses keys, and how quickly it can rotate. The Salesloft Drift breach showed what happens when an integration vendor's environment holds customer tokens: Google reported that Drift Email tokens were used to read mail in a small number of Workspace accounts.
User-consented apps are a separate path: the Vercel Context.ai OAuth breach started with one employee granting a consumer AI app broad access to a corporate Google account. Delegation would have made the same app tenant-wide, which is why delegation requests deserve a stricter review than ordinary app approvals. See the SaaS and OAuth App Governance Guide.

Logging and detection

Delegation produces evidence in three places, and none of them tells the full story alone.

Source	Event or field	What it shows	Alert on
Workspace Admin audit log (security settings)	`AUTHORIZE_API_CLIENT_ACCESS`, `REVOKE_API_CLIENT_ACCESS`	A delegation client was authorised or its access removed	Every authorisation; scope additions outside a change ticket
Workspace Admin audit log (API controls)	`ADD_TO_TRUSTED_OAUTH2_APPS`, `BLOCK_ALL_THIRD_PARTY_API_ACCESS`, `TRUST_DOMAIN_OWNED_OAUTH2_APPS`	Changes to app access levels and unconfigured-app settings	Apps moved to Trusted; internal apps trusted wholesale
OAuth Token audit log (`applicationName=token`)	`activity` events with `client_id`, `api_name`, `method_name`, `num_response_bytes`, `product_bucket`	Which client called which API for which user, and how much data came back	Delegated client touching many users quickly; new `api_name` for a known client; byte spikes
Google Cloud audit logs for the delegation project	Service account key creation, IAM policy changes on the service account, signJwt or token generation calls	Who obtained the ability to act as the delegated account	Any key creation; new Token Creator binding; signJwt from an unexpected principal

The OAuth Token log records the client ID with each activity event, which is what lets you separate delegated calls from the user's own activity. Hunters observed that delegated calls are otherwise logged under the victim user's identity, so investigations that only look at user activity will miss them. Build a join on client_id between the token log and your inventory of authorised delegation clients, and alert on any client ID that appears in token activity but not in the inventory.

Detection rules for the AUTHORIZE_API_CLIENT_ACCESS event are published by SIEM vendors and map it to MITRE ATT&CK T1098 Account Manipulation. Use of a delegated token to read mail corresponds to T1114.002 Remote Email Collection and, more generally, T1550.001 Application Access Token. Creation of a new service account key for a delegated account is T1098.001 Additional Cloud Credentials. For query patterns across the Workspace logs, see the Google Workspace Audit Log Detection Guide.

Metrics that show the programme is working:

Delegation inventory coverage: percentage of clients on the Manage Domain Wide Delegation page with a named owner, business purpose and review date (target 100%).
Scope breadth: number of clients holding full Gmail or full Drive scopes, tracked down over time.
Key exposure: count of user-managed keys on delegated service accounts (target zero).
Privileged principals per delegated account: principals returned by the effective IAM policy check, with a target of a handful per account.
Stale grants: clients with no OAuth Token activity in 90 days, which are candidates for deletion.
Time to revoke: elapsed time from a vendor breach notice to delegation removal.

Hardening baseline

The baseline below follows Google's published best practices, ordered so that the cheapest, highest-impact controls come first.

Decide whether delegation is needed at all. Google's first recommendation is to avoid it where a service account acting as itself, user OAuth consent or a Marketplace app would do. Record the decision for every grant.
Inventory current grants. Export the delegation client list, match each client ID to a service account (Google Cloud > IAM & Admin > Service accounts > Advanced settings shows the client ID) or to a vendor, and assign an owner.
Enable multi-party approval for super admin actions so that no single administrator can add or widen a grant.
Trim scopes. Use View details on each client to list scopes, remove any that are unused, and replace full scopes with read-only or feature-specific ones. Remember that changes can take up to 24 hours to propagate, and that deleting a client breaks the dependent application immediately.
Isolate the Cloud side. Move internally run delegated service accounts into dedicated projects, remove project-level Token Creator and Editor grants, apply key creation and upload constraints, and use lateral movement insights to find cross-project impersonation paths.
Remove keys. Replace key-based signing with signJwt from an attached workload identity; delete remaining keys after cut-over.
Wire up detection for the events in the table above and test it by authorising a harmless test client with a read-only scope, confirming the alert, then deleting it.
Set review cadence. Quarterly for vendor and backup grants, and an end date for every migration grant.

Roll back by exception rather than by disabling controls: if a scope reduction breaks an integration, restore the single scope via Edit, record why, and set a date to revisit it.

Small versus large tenants: a small organisation may have two or three grants and can review them by hand in the Admin console each quarter. A large tenant with dozens of vendor grants needs the inventory in a system of record, automated joins between Admin and token logs, and a third-party risk process that treats any vendor requesting delegation as high risk by default.

Framework mapping

Framework	Reference	How it applies to delegation
NIST SP 800-53 Rev. 5	AC-6 Least Privilege, AC-6(5) Privileged Accounts	Narrow scopes; treat delegated accounts and their Token Creators as privileged
NIST SP 800-53 Rev. 5	AC-2 Account Management, IA-9 Service Identification and Authentication	Owner, purpose and review date per grant; keyless authentication
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, AC-6(9) Log Use of Privileged Functions	Correlating Admin, token and Cloud audit logs
NIST CSF 2.0	PR.AA-01, PR.AA-05	Managing service identities and their authorisations
NIST CSF 2.0	DE.CM-03	Monitoring technology usage for adverse events
CIS Controls v8.1	Control 5 Account Management, Control 6 Access Control Management, Control 8 Audit Log Management	Inventory, least privilege and log review for service accounts
ISO/IEC 27001:2022 Annex A	5.15 Access control, 5.18 Access rights, 8.2 Privileged access rights, 8.15 Logging	Policy, provisioning and review of tenant-wide access
MITRE ATT&CK	T1098, T1098.001, T1550.001, T1114.002	Grant creation, key addition and use of delegated tokens

Common misconfigurations

Leftover migration grants: a mail migration tool authorised with full Gmail scope years ago and never removed. Google explicitly calls out deleting clients after migration.
Delegated account in a shared project: the service account sits in a general development project where dozens of engineers hold Editor, so the effective audience for tenant-wide impersonation is the whole team.
Long-lived keys on delegated accounts: a JSON key created for a proof of concept and stored in a repository or CI variable. Anyone holding the key can authenticate as the service account with no prior authentication, as Google puts it.
Believing scopes limit the user set: teams assume an archiving tool can only reach "the archive users". Delegation has no user filter; restrict impersonation targets in the application and monitor sub values through token activity.
Scope creep through edits: scopes added to an existing client during troubleshooting and never removed, with no alert on the change.
Vendor grants outside third-party review: security vendors and backup providers granted delegation as part of onboarding, without the same contract, breach notification and token-storage questions applied to other critical suppliers.

Practitioner checklist

Export every client from Manage Domain Wide Delegation and record owner, purpose, scopes and review date.
Enable multi-party approval for super admin actions.
Delete grants for completed migrations and any client with no token activity in 90 days.
Replace full Gmail and Drive scopes with read-only or feature-specific scopes where the integration allows.
Move internal delegated service accounts into dedicated projects and remove project-level Token Creator and Editor grants.
Apply key creation and upload constraints and delete existing user-managed keys; sign with signJwt.
Run the effective IAM policy check for each delegated account and reduce the principals it returns.
Alert on AUTHORIZE_API_CLIENT_ACCESS, new keys on delegated accounts and unknown client IDs in OAuth Token activity.
Add delegation questions (token storage, keys, rotation, breach notice) to vendor security reviews.

Google Workspace Domain-Wide Delegation Security Guide: Governing Tenant-Wide Service Account Access