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
issset to the service account email,subset to the email of the user to impersonate,scopelisting the space-delimited OAuth scopes, andaudset tohttps://oauth2.googleapis.com/token. - The JWT is signed with RS256. The
expclaim can be at most one hour afteriat. - 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.serviceAccountKeyAdminand Owner or Editor roles as the grants that give direct or inherited ability to act as the account. Anyone withiam.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
activityin 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
subvalues 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.
Standards and references
- Google Workspace Admin Help: Control API access with domain-wide delegation
- Google Workspace Admin Help: Domain-wide delegation best practices
- Google for Developers: Using OAuth 2.0 for Server to Server Applications
- Google Cloud: Best practices for using service accounts securely
- Google Workspace Admin Help: Control which third-party and internal apps access Google Workspace data
- Google for Developers: Reports API OAuth Token audit activity events
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Account Manipulation
Related NHI Mgmt Group resources: Google Cloud IAM and Service Accounts Guide · Google Workspace Security Guide · Google Workspace Audit Log Detection Guide · SaaS and OAuth App Governance Guide