Why domain-wide delegation is the safer shape
There are two common ways a third-party tool reads a Google Workspace directory. The first stores a per-customer OAuth credential in the vendor's database. The second uses domain-wide delegation, where your super admin authorises the vendor's client id for named scopes inside your own admin console.
The difference matters most when something goes wrong at the vendor. Under domain-wide delegation, QRBold holds no secret of yours to lose — the customer half of the grant is a record in your Google tenant, not a row in QRBold's database. There is nothing to leak in a breach and nothing to rotate after one.
It also makes revocation honest. Removing the delegation in your admin console is effective on QRBold's next token request, with no dependency on QRBold processing a disconnect request correctly. That is the same property the Microsoft Entra ID consent flow has, and it is why both are preferred over storing per-customer credentials.
What the four scopes actually allow
The scope list is deliberately short, and every entry is readonly. There is no write scope in the set, so no configuration of QRBold can result in a change to your directory.
- directory.user.readonly. Reads user profiles — the name, job title, department, email, and phone that populate a card.
- directory.group.readonly. Reads the list of groups, so card assignment can follow group structures you already maintain.
- directory.group.member.readonly. Reads who is in those groups, which is what makes group-based eligibility work.
- reports.audit.readonly. Reads directory audit activity so account changes such as a suspension are detected promptly rather than waiting on a full re-read.
- domain.readonly (optional). Requested when available purely so the dashboard can display your domain name. An admin who declines it still gets a fully working integration.
Built for directories that are actually large
Directory reads are paged at Google's own maxima — 500 users and 200 groups per page — and ceilinged at 200 pages per read. That ceiling works out to a hundred thousand people, comfortably larger than any directory expected here, and it exists so a paging fault on either side surfaces as an error rather than a process that never returns.
Rate limiting is applied per integration rather than globally, which is a deliberate choice. Google charges quota per project per user, so one customer's very large directory should slow that customer's own sync and nobody else's. A single global limiter would let one account's backfill stall every other account's updates.
Transient failures — 429s and 5xx responses — are retried with backoff. Everything else is surfaced as an error to be fixed rather than retried silently, because a permissions problem does not improve by asking again.
Google Workspace as directory, with or without SSO
Google Workspace can play either or both of two roles here. As a directory it supplies the roster and the attributes that populate cards. As an identity provider it can also handle sign-in, so employees reach QRBold with their existing Google credentials and your MFA and context-aware access policies apply without extra configuration.
The roles are independent. An organisation that authenticates through Okta but keeps its authoritative employee directory in Google Workspace can connect the directory here and leave sign-in where it is.