Domain-Wide Delegation Security Risks in Google Workspace
Domain-wide delegation security risks: how an API client can impersonate every user, the Admin log events that record it, DeleFriend and what to review.
TL;DR. Domain-wide delegation (DWD) lets a service account or API client act as any user in the domain for the scopes you list, with no user consent. A delegation with Gmail or Drive scopes is a skeleton key to every mailbox or drive. New delegations appear in the Admin log as AUTHORIZE_API_CLIENT_ACCESS. Review every delegated client and its scopes during an incident, and remember the 2023 DeleFriend research: whoever can create keys for a delegated service account in Google Cloud inherits the delegation.
Per-user OAuth grants are bounded by what one user can reach. DWD is not. It exists for good reasons (backup tools, migration, e-signature integrations, GAM itself), which is why most tenants have a few delegations nobody remembers approving. For an attacker who reaches a super admin account, adding one is the quietest persistence available. MITRE maps this area to T1098.001 Additional Cloud Credentials and T1484.002 Domain or Tenant Policy Modification: Trust Modification.
How DWD works
Google's Control API access with domain-wide delegation page describes the mechanics:
- A service account is created in a Google Cloud project, or an OAuth client exists for an app.
- A super admin adds its client ID and a list of OAuth scopes under Security → Access and data control → API controls → Manage Domain Wide Delegation.
- The client can now request tokens as any user for those scopes. End-user consent is bypassed.
Google recommends least-privilege scopes and regular review in its domain-wide delegation best practices. Where multi-party approval is enabled, a second super admin must approve new delegations.
What the logs show
| Where | Event | What to read |
|---|---|---|
| Admin log | AUTHORIZE_API_CLIENT_ACCESS | Client name / ID and the scopes granted |
| Admin log | App trust changes (ADD_TO_TRUSTED_OAUTH2_APPS, UNBLOCK_ALL_THIRD_PARTY_API_ACCESS, …) | Controls loosened around the same time |
| OAuth token log | activity for that client | API calls made as each impersonated user |
| Google Cloud audit logs | Service account key creation | New keys on a delegated service account |
In the analyzer, AUTHORIZE_API_CLIENT_ACCESS fires Domain-wide delegation granted to an API client (high). If the same admin account had a risky sign-in within 14 days, the risky sign-in → admin change chain escalates to critical. App-control loosening is flagged separately.
The DeleFriend research
In November 2023, Hunters' Team Axon published "DeleFriend", a design issue they had reported to Google in August 2023. Delegation is bound to the service account's client ID, not to a specific private key. Anyone with the Google Cloud permission to create keys for a service account that already has DWD (iam.serviceAccountKeys.create, part of broad roles such as Editor) can mint a new key and use the existing delegation. No Workspace super admin rights are needed.
The practical consequences for an investigation:
- A compromise of the Google Cloud project hosting a delegated service account is a Workspace compromise in waiting.
- The Workspace Admin log won't show anything new, because the delegation already exists. The signal is on the Cloud side (key creation) and in the token log (new API activity by the client).
- Delegations that are no longer used are pure risk.
Investigating the Google Cloud side (service account keys, IAM changes, audit logs) is its own discipline. gcpforensics.com covers it.
Review checklist
During an incident, and at least yearly:
- Export the delegation list. The console lets you download third-party apps and DWD clients to CSV. For each client: who owns it, which project, which scopes, when it was last used.
- Flag broad scopes:
https://mail.google.com/,gmail.*,drive,admin.directory.*,cloud-platform. Most integrations need far less. - Match every
AUTHORIZE_API_CLIENT_ACCESSin the Admin log to a change request. Unplanned means incident. - Check the owning Cloud projects: who holds Editor/Owner or key-creation rights on delegated service accounts, and whether new keys appeared.
- Remove unused delegations and rotate keys where you keep them.
- Enable multi-party approval for sensitive admin actions if your edition supports it.
If you find a rogue delegation
- Remove the client from Manage Domain Wide Delegation immediately. Google notes changes can take time to apply, typically less than 24 hours.
- Disable or delete the service account's keys in Google Cloud.
- Pull the OAuth token log for that client ID across all users. That is the scope of the data access.
- Treat the super admin account that added it as compromised: reset its sign-in cookies, review its sign-ins and every change it made. See admin role abuse and SSO changes.
How it differs from per-user OAuth
| Per-user OAuth grant | Domain-wide delegation | |
|---|---|---|
| Who approves | The user | A super admin |
| Reach | One user's data | Every user, for listed scopes |
| Log of the grant | OAuth token log authorize | Admin log AUTHORIZE_API_CLIENT_ACCESS |
| Typical abuse | Consent phishing | Admin takeover persistence, Cloud-side key theft |
| Post | Suspicious OAuth apps | This post |
Next in the series: Drive mass download and Takeout exfiltration. To check your Admin log for delegation and trust changes, drop it into the analyzer.
FAQ
Who can grant domain-wide delegation in Google Workspace?
Only a super administrator can add or change domain-wide delegation, under Security → Access and data control → API controls → Manage Domain Wide Delegation. If multi-party approval is enabled, another super admin must approve it.
Which log shows domain-wide delegation changes?
The Admin log. Adding or changing a client's delegated scopes is recorded as AUTHORIZE_API_CLIENT_ACCESS with the client and scopes. The resulting API calls made on behalf of users appear in the OAuth token log.