Guide
Google Domain-Wide Delegation, Explained
Domain-wide delegation lets a single service account impersonate any user in a Google Workspace domain without each person consenting. It's powerful for backend automation and dangerous for the same reason: one key can read every mailbox. This guide explains how delegation works, the security trade-offs an admin signs up for, and when per-user OAuth — the model Nylas uses — gets you the same access with a smaller blast radius and no admin-level key to guard.
Written by Aaron de Mello Senior Engineering Manager
Command references used in this guide: nylas auth login, nylas auth list, and nylas email list.
What is domain-wide delegation?
Domain-wide delegation is a Google Workspace feature that lets a service account act on behalf of users in the domain without each user granting consent. A Workspace admin authorizes the service account's client ID for specific scopes, and from then on the account can mint tokens that impersonate any user, calling Gmail or Calendar as them. It's the standard path for server-to-server automation across a whole organization.
The authorization is admin-level and broad. Per the Google Workspace admin docs, delegation is configured in the Admin console by mapping the service account to scopes, and it applies across the domain. That breadth is the feature's value and its risk: the service account key becomes a credential that can reach every authorized mailbox.
When do you need delegation versus per-user OAuth?
You need delegation when a backend must access mailboxes without any user in the loop — a compliance archiver that reads all mail, or a provisioning job that sets up calendars for new hires before they log in. In those cases there's no user to click consent, so impersonation by a service account is the only model that fits.
You don't need it when users can connect their own accounts. Per-user OAuth — where each person consents once and your app holds a grant scoped to their mailbox — covers most products: CRMs, schedulers, assistants. The table contrasts the two so you can match the model to the requirement rather than reaching for delegation by default.
| Aspect | Domain-wide delegation | Per-user OAuth (Nylas) |
|---|---|---|
| Consent | Admin, once for the domain | Each user, for their mailbox |
| Blast radius | Every user in the domain | One mailbox per grant |
| Revocation | Admin removes the mapping | User revokes their grant |
| Works without user | Yes | No (user connects) |
| Providers | Google Workspace only | 6 providers |
How does Nylas avoid the delegation key?
Nylas uses per-user OAuth, so each person connects their own mailbox and you hold a grant scoped to just that account. There's no domain-wide service account key to store, rotate, or worry about leaking — and the same model works across six providers, not just Google Workspace. Connect a user with nylas auth login, and the grant is revocable by that user at any time.
That smaller blast radius is the security win. A leaked per-user grant exposes one mailbox; a leaked delegation key exposes the whole domain. For the cases that genuinely need no-user-in-the-loop access across all mailboxes, delegation remains the right Google-native tool — but for products where users authenticate themselves, per-user OAuth is simpler and safer.
# Per-user OAuth: each user connects their own mailbox, one grant each
nylas auth login --provider google
nylas auth list # see connected accounts
nylas email list --json --limit 10 # acts as the connected user onlyNext steps
- Service account vs OAuth — the broader app-level vs per-user choice
- OAuth scopes for email — scoping access correctly
- Email API authentication methods — the auth options compared
- Provision agent accounts at scale — many mailboxes without DWD
- Full command reference — every flag and subcommand documented