Google Workspace's administration guide calls domain-wide delegation a powerful feature: an administrator can let a client application access users' Workspace data without each user's consent. That is useful for migration, synchronization and internal automation. It also makes a client ID and its surrounding identity controls a meaningful enterprise security boundary. A buyer commissioning an assessment needs to know which application can act, on whose behalf, for what data and under whose operational control.
Quick answer. Inventory the authorized clients and scopes, then trace each high-impact grant from its business owner through service-account or OAuth-client control to a Workspace user's data. Use customer-owned test identities and synthetic records to prove allowed access, denied access, scope changes and revocation. A scope that names only Gmail or Drive does not limit the set of users a delegated service account can impersonate, as Google's best-practices guide states.
This is a buyer's test design for the customer's own environment. It is not a claim that every domain-wide grant is unsafe, that Google's documentation requires a penetration test, or that a security vendor has special permission to access a third-party tenant. Written authorization and a narrow rules of engagement belong in the statement of work.
Why this deserves its own scope
The Google Cloud penetration-testing scope guide covers Cloud projects and IAM broadly. Domain-wide delegation needs a more specific question: can an application move from a credential or Cloud IAM permission into a different Workspace user's mail, files, calendar or other authorized API data? A general cloud configuration review may record that the grant exists without testing its effect. A broad web application scan may never see the administrative grant at all.
Google documents two forms of domain-wide delegation. A Workspace super administrator can authorize a service account to access data on behalf of a user. The administrator can also authorize an OAuth client application so users do not see a consent screen. These are related administrative decisions, but the credentials, runtime controls and meaningful test cases differ. The engagement should first label which type each authorized client actually uses.
For a service account, the delegated API call names a user to impersonate. Google's server-to-server OAuth documentation says that user is specified explicitly when making the call. The Admin console authorizes a client ID and a set of OAuth scopes; Google states that scopes limit types of data, not which users the service account can impersonate. A test that checks only whether the scope list looks short can therefore miss the user reach of the grant.
The practical unit of risk is an authority path: someone or something can control a delegated client; that client can obtain a token under approved scopes; the call selects a Workspace user; and the API returns or changes data according to those authorities. The buyer should request evidence at every hop. The test need not retrieve real employee content to prove the path. Two synthetic users, separate test records and a carefully limited API action can show the allowed and denied decisions.
Figure 1: The service-account form of domain-wide delegation follows Cloud control, the Workspace grant, the selected user and the API result. OAuth-client grants use a different first stage. Stingrai synthesis based on Google's delegation administration guide and best practices.
The domain-wide delegation buyer matrix
Write expected behavior before testing. The table is a procurement and report acceptance matrix, not a recipe for use against an unowned tenant. Each row can be performed with customer-owned identities and synthetic data where the tenant owner authorizes it.
Boundary | Allowed proof | Denied or exception proof | Report artifact |
|---|---|---|---|
Grant inventory | Every active client ID has an owner, purpose and approved data scopes | Unknown, stale or duplicate grants are flagged for owner decision | Redacted inventory and scope rationale |
Client type | Service-account and OAuth-client grants are labeled correctly | A test meant for one type is not assumed to cover the other | Client-to-application mapping |
Service-account control | Approved workload can act as the delegated service account | Unapproved user, role or project cannot mint credentials or alter its control | Effective IAM path and observed denial |
Workspace scope | A synthetic record in the approved data type is accessible when intended | A request outside the authorized API scope fails | Scope-to-API result matrix |
Subject selection | Approved synthetic user can be selected for the intended workflow | Policy-excluded test persona is blocked by application or operational control where such a restriction is claimed | Subject decision and compensating control evidence |
Business workflow | Only the documented migration, backup or automation action executes | An unrelated or higher-impact action is not available under the grant | Workflow trace and authorization decision |
Change control | Super-admin and, if enabled, second-party approval are recorded | A scope increase cannot bypass the stated approval process | Approval, change and effective-scope timestamps |
Revocation | Removed scopes or deleted client grant stop future unauthorized use after the documented transition | Old access is not treated as safely gone merely because a console edit was submitted | Before/after test and propagation caveat |
The subject-selection row needs precise wording. Google does not promise that an OAuth scope restricts a delegated service account to a particular set of users. If a business application claims it may only act for a named population, that limit may be implemented in the application, its operating process, or another control. The report should state where it lives and test it as that kind of control. Do not label an allowed impersonation of a second synthetic user a Google platform bug when the grant is working as Google documents.
Inventory the grant before sending any test call
Google's Admin console instructions have the super administrator enter a client ID and API scopes, then authorize it. The same page recommends periodic review and deleting clients that are no longer needed. For a mid-market or enterprise buyer, that makes inventory the natural first deliverable. Ask the tenant owner for a read-only export or supervised review of authorized client IDs, grant purpose, owner, created or changed date where available, and listed scopes. Redact the identifiers in any publication or proposal example; the real inventory belongs in the confidential assessment report.
The tester should reconcile each client with a deployed application, vendor, service account or integration owner. A grant that no one can explain is not proof of compromise. It is a decision item: identify it, find the owner or prepare an approved removal plan. Likewise, a broad scope may be justified for a migration window and unnecessary after migration. The report should record business purpose and alternatives, rather than assigning severity from the scope string alone.
Google recommends using direct service-account access or user OAuth consent when those can meet the use case. Include this design question in the buyer brief: is domain-wide authority actually required for this workflow? A tester should not tear out a production dependency to answer it. The useful output is a migration decision with owner, impact and sequencing for any grant that can be narrowed or retired.
Trace who can use the delegated identity
For a service-account grant, the Workspace Admin console entry is only one side of the authority path. A principal in Google Cloud may be able to use the account's credentials, obtain signed material or alter the account's access policy. Google's DWD best practices tell administrators to restrict who can change the service-account allow policy, limit access to dedicated projects, constrain key creation and avoid keys where possible. The guide specifically recommends the signJwt API instead of service-account keys for domain-wide delegation.
Ask for an effective-control review, not just a list of directly assigned roles. The assessor should identify the approved runtime, people who can manage its project, inherited access, people who can control the service account, and any existing keys. Test a small number of authorized and unauthorized synthetic principals under the tenant owner's rules. An environment with no downloadable keys may still grant dangerous control through IAM. Conversely, seeing a management permission does not itself prove the user can read Workspace data; the path must be demonstrated or explicitly marked as inferred from configuration.
Do not ask the tester to copy a service-account key into a report or a shared ticket. A safe report can show redacted role bindings, key inventory metadata, controlled token issuance decisions and the resulting synthetic API access. If the customer's secrets are needed during testing, handle them under the engagement's secure evidence process and omit them from the published blog and marketing material.
Test scopes against data and users separately
An OAuth scope defines the kinds of API data an application may request. Google says the delegated service-account scope does not limit which users can be impersonated. Build two axes in the test sheet: data type and synthetic user. A least-privilege scope may reject a Calendar operation while allowing a Drive operation, yet the same allowed Drive scope may be usable while selecting more than one Workspace user. The expected result depends on the client's approved purpose and the application's own subject-control design.
Use the least sensitive synthetic record that can answer the business question. One test user can own a marked file or message; another can own a different marked record; a third can represent a deliberately excluded population if the integration claims such a restriction. Record the user selected, scope in effect, API action, result and expected policy. Avoid blanket mailbox searches or broad Drive exports. An assessment can prove reach without ingesting live employee content.
For OAuth-client grants without a service account, adapt the test to the actual consent-free application flow. The buyer still needs client ownership, scope justification, user context and revocation evidence, but a Cloud IAM review of a service account that does not exist would be wasted effort. This distinction should appear in proposals and reports, especially where several migrations and Marketplace or internal apps coexist.
Changes, approval and revocation require measured evidence
Google's administration guide says that multi-party approval is required for adding, editing or deleting a domain-wide delegation when the organization has that feature enabled. It also says scope changes can take up to 24 hours, though they typically propagate sooner. Deleting a client authorization is described differently: applications dependent on it immediately stop working. A report should not flatten these statements into “all revocation is instant.”
Plan the test so the change owner, not the assessor acting alone, authorizes every administrative step. Record the approved scope, time of submission, time the Admin console reflects it, and the time a fresh controlled API call changes behavior. Use short-lived test grants only if the customer's change process permits them. Where a production grant cannot be edited safely, use a nonproduction or dedicated test client with comparable policy and document the limitation. The goal is a measured operational decision, not a dramatic live disruption.
Ask whether a departure, vendor termination or compromised integration has a runbook. It should identify who can disable the client, who can revoke or rotate service-account credentials, which application will break, who will verify that new access fails, and where to preserve logs. A penetration test can exercise the technical part with a synthetic client and return a tabletop question for the production runbook. The enterprise identity test matrix gives context for broader identity and deprovisioning paths beyond this Workspace-specific boundary.
What the buyer should provide before a quote
A credible proposal needs more than the tenant name. Supply a controlled scope packet with the following:
Grant count and purpose. Number of DWD client IDs, owner of each, business process, internal or third-party application, and expected retirement date if temporary.
Client type and hosting. Mark service-account grants separately from consent-free OAuth clients. Identify the relevant Cloud project and workload for each service-account path.
Data scope. List approved OAuth scopes and the data types they govern. Name excluded APIs and destructive operations. Do not provide real user data for proposal preparation.
Test identities. Provide two or more owned synthetic Workspace users and synthetic records, with separate roles or populations if an application claims a subject restriction.
Change authority. Name the super-admin owner and whether multi-party approval is enabled. Specify whether test grants, scope edits or deletions are permitted in the chosen environment.
Rules of engagement. Define the authorized tenant, applications, API operations, rate limits, test window, monitoring contact and stop conditions.
Business acceptance question. For example: “Can a principal outside the integration team obtain the delegated authority?” or “Does the approved migration client reach only the data types in its grant?”
The quote should separate a configuration and identity-path review from active API validation. Some buyers need only an inventory and architecture decision; others need a supervised test of actual access under several personas. The price and timeline should follow the count of grants, projects, application paths, scopes and approved workflows. Do not accept a single “Google Workspace pentest” line item without a named authority path and evidence method.
What makes the report useful to an enterprise buyer
A useful report is a table of every in-scope grant and its owner, scope, technical control path, validated user reach, and business decision. Findings should distinguish three things: a documented platform behavior that the organization did not expect, an application control that failed, and a Cloud IAM or credential-management path that gives an unapproved principal control of the delegated identity. Those are different remediation owners.
For each validation, request the expected policy, synthetic account used, authorized API action, observed result, timestamp and a redacted trace. A clean result needs denial evidence as well as successful access. “No critical findings” does not answer whether a second user, a wrong scope or an unapproved principal was actually tested. Mark each row passed, failed, blocked, excluded or not applicable. Follow failed rows with the smallest viable fix, owner, retest step and residual business decision.
Treat the report as confidential. It can contain real client IDs, effective IAM paths and tenant-specific access facts that do not belong in marketing copy. Public thought leadership should use only the synthetic matrix here and Google's public documentation. That separation protects the customer's tenant while allowing buyers to understand the methodology.
An organization should revisit the grant after a migration ends, an integration changes scopes, a service account moves projects, IAM roles change, a key or runtime is replaced, or a vendor relationship ends. These are change-driven test triggers based on the authority path. Google's documentation recommends regular review, but it does not set a universal penetration-test cadence for this feature.
Where Stingrai fits
Stingrai can scope a human-led Google Workspace and cloud identity assessment around the customer-owned DWD grants, service-account control and synthetic user-data workflows. The deliverable can map allowed and denied authority, name the controls and owners, provide reproducible redacted evidence, and retest a remediation. A web or API component may be tested alongside that identity path where the integration has a customer-controlled application interface. Autonomous web-app testing should not be represented as a substitute for judgment about Cloud IAM, Workspace administration and live tenant change control.
Buyers can begin with the cloud penetration testing service or request a tailored quote. Share the grant count and the safe scope packet above, not live credentials or employee content.
Frequently Asked Questions
What is a Google Workspace domain-wide delegation assessment?
It reviews the clients a Workspace super administrator has authorized, their OAuth scopes, who controls them, and what user data they can actually reach. A scoped test uses owned identities and synthetic records to prove allowed and denied behavior without reading real employee content.
Do narrow OAuth scopes limit a service account to certain users?
No. Google says OAuth scopes restrict the types of user data a delegated service account can access, not which users it can impersonate. If an application is meant to act for only a subset of users, the assessment must identify and test the separate control enforcing that claim.
Is every domain-wide delegation grant a service account?
No. Google documents service-account delegation and OAuth client applications that avoid a user consent screen. The buyer should identify the client type before choosing Cloud IAM and runtime test cases.
Does deleting a grant have the same timing as editing its scopes?
No. Google's administration guide says scope changes can take up to 24 hours, while applications depending on a deleted client authorization immediately stop working. Test and record the actual transition for the customer's approved scenario.
What test data should an enterprise provide?
Provide customer-owned synthetic Workspace users, marked test records, approved API actions and a rules-of-engagement contact. Do not put employee mail, real documents, keys or tokens into the public brief or the marketing article.
When should the organization retest a DWD integration?
Retest the affected authority path when scopes, service-account IAM, credentials, hosting, application workflows or vendor ownership change. A temporary migration grant should also be reviewed for removal when its purpose ends.
