If you have gone looking for the "Show domain-wide delegation" link on a service account in the Google Cloud Console and could not find it, you are not doing anything wrong. That control used to live under Advanced settings on the service account page, and Google has retired it.
The short answer: you no longer enable domain-wide delegation in the Cloud Console at all. You authorise it in the Google Admin console, and all you need from Cloud Console is the service account's numeric client ID.
The 30-second version
- Cloud Console → IAM & Admin → Service Accounts → click your service account → copy the Unique ID (a 21-digit number).
- Go to admin.google.com as a super-admin.
- Security → Access and data control → API controls.
- Under Domain-wide delegation, click Manage domain-wide delegation.
- Add new, paste the Unique ID as the Client ID, paste your scopes, Authorise.
That is the whole thing. No toggle in Cloud Console is required, and the absence of one is not blocking you.
Why the toggle disappeared
The old checkbox never actually granted anything. It only registered a product name for the OAuth consent entry and gave you a shortcut link into the Admin console. The real grant - the part that lets a service account impersonate users in your domain - has always been made by a Workspace super-admin in the Admin console, because that is the only place with authority over your domain's data.
Removing the Cloud Console control tightened that story: domain-wide delegation is a Workspace decision, so it is configured in Workspace. If a guide written a couple of years ago tells you to tick a box in Cloud Console, skip that step and go straight to the Admin console.
Finding the right client ID
This is where most people get stuck, because Google uses the word "client ID" for several different things.
- What you need: the service account's Unique ID - a long number, roughly 21 digits, shown on the service account's Details tab. In some screens the same value is labelled OAuth 2 Client ID.
- What you do not need: the service account's email address, the JSON key's
private_key_id, or a Web Application OAuth client ID ending in.apps.googleusercontent.com. Pasting one of those is the single most common cause of failure.
If you downloaded a JSON key for the service account, the correct value is also in that file, under client_id.
Scopes: exact strings, comma-separated
The Admin console asks for a comma-separated list of OAuth scopes. They must match, character for character, the scopes your application requests. A trailing space or a .readonly you did not intend will cause a silent rejection later.
For read-only directory sync - the common case for an asset tracker pulling your staff list - two scopes are usually enough:
https://www.googleapis.com/auth/admin.directory.user.readonlyhttps://www.googleapis.com/auth/admin.directory.group.readonly
Grant the narrowest scopes that do the job. Domain-wide delegation is powerful: it lets the service account act as any user in your domain, so read-only scopes are worth insisting on when the integration only needs to read.
Do not forget the subject
Delegation alone is not enough. When your code requests a token it must also name the user it is impersonating - often called the subject or impersonated user. For Admin SDK directory calls that has to be an actual super-admin account in the domain, not the service account's own address and not a mailbox-less alias.
A delegation that is correctly authorised but has no subject set fails in exactly the same way as one that was never authorised, which makes this an easy hour to lose.
Troubleshooting the three errors you will actually hit
unauthorized_client
The pairing of client ID and scope is not authorised. In practice this means one of: the wrong ID was pasted, a scope in the request is missing from the Admin console entry, or the scope strings differ slightly. Compare them side by side rather than trusting a glance - admin.directory.user and admin.directory.user.readonly look nearly identical in a narrow input box.
Nothing works for a few minutes, then it does
Delegation changes propagate. Give it several minutes before assuming the configuration is wrong, and re-test with a fresh token rather than a cached one.
403 with a valid token
Usually the impersonated subject lacks the admin privilege for the data being read, or the relevant API (for directory data, the Admin SDK API) was never enabled on the Cloud project. Both are quick to confirm.
A note on how often this moves
Google reorganises these screens fairly regularly, and the exact menu labels in Cloud Console and the Admin console drift year to year. The structure underneath has been stable for a long time, so it is worth remembering the shape rather than the click path: Cloud Console holds the identity, the Admin console grants it permission over your domain, and your code chooses which user it acts as. If a menu has moved, search the Admin console for "domain-wide delegation" and you will land in the right place.
Where this fits in SimpleAMS
SimpleAMS uses exactly this mechanism for Google Workspace directory sync, so your staff list stays current and assets get checked out to real people instead of hand-typed names. The full walkthrough, including creating the project and enabling Sign in with Google, is in our Google Workspace setup guide.
If you would rather not run identity plumbing yourself at all, that is a fair position - it is much of why IT teams at growing companies move to a hosted asset tracker in the first place. You can also sync devices directly from Intune, Jamf Pro or Mosyle, and provision users over SCIM if you are on Okta or Entra ID.