Google Workspace
Connects to the Google Workspace Admin SDK to pull your user directory and Chrome OS device inventory into Clariti. This gives you visibility into your Google-managed identities and endpoints alongside your other security assets.
Two ways to connect
Most people should use Option A (Sign in with Google). It takes about a minute, needs no Google Cloud project, and works even if your organization blocks service-account keys.
Option A — Sign in with Google (recommended). In Clariti, click Connect Google Workspace → Connect with Google. A Google sign-in window opens; sign in as a Workspace super admin and approve the read-only access. That's it — no Google Cloud Console, no key files, no domain-wide delegation. Choose this unless you have a specific reason not to.
You must approve the Google sign-in while signed in as a super admin. If you approve as a regular user, Clariti connects but reads no directory data (Google returns an empty/403 result for non-admins).
If you see "Access blocked" or "Google hasn't verified this app": your organization restricts which third-party apps can access Workspace data. A super admin allowlists Clariti once — go to Admin console → Security → Access and data control → API controls → Manage App Access → Configure new app, search for Clariti (or paste the Clariti OAuth client ID), select it, and set access to Trusted for your organization. Then run Connect with Google again. Trusting the app by its client ID lets your org use it without waiting on Google's public app verification. You'll find the exact client ID (and a copy button) in Clariti's Connect Google Workspace dialog, under "First time connecting?".
Option B — Service account key (advanced). Create a Google Cloud service account, download a JSON key, and authorize it for domain-wide delegation. Use this only if you specifically want a service-account credential. Note: many organizations enforce an org policy (iam.disableServiceAccountKeyCreation) that blocks creating the key entirely — if you hit "Service account key creation is disabled," use Option A instead. The rest of this guide covers Option B.
What You'll Need
- Google Workspace super admin account
- A Google Cloud project (free to create)
- About 15 minutes
- A Clariti account with adapter setup permissions
This is the most involved adapter setup because Google requires three separate consoles (Cloud Console, Admin Console, and the service account page). Set aside 15 uninterrupted minutes and keep all three tabs open — it'll go smoother.
Configure in Google Cloud Console
Create a Google Cloud Project
Navigate to: console.cloud.google.com → Project selector → New Project
Go to console.cloud.google.com. Click the project selector dropdown at the top of the page, then click New Project.
- Project name:
Clariti Integration - Organization: Select your organization
- Location: Your organization
Click Create.
Use a descriptive project name like "Clariti Integration" — you'll likely have multiple GCP projects eventually and need to find this one quickly. Avoid generic names like "test" or "api-project."
Why: Google Cloud organizes API access by project. Clariti needs its own project to house the service account and API credentials.
Enable the Admin SDK API
Navigate to: APIs & Services → Library
Make sure your new project is selected in the project dropdown. Then navigate to APIs & Services → Library in the left sidebar.
Search for Admin SDK API and click on it. Click Enable.
This enables the Google Workspace Admin SDK for your project, which provides access to user directory and device data.
Why: Google Cloud APIs are disabled by default. You need to explicitly enable the Admin SDK so your service account can call it.
Create a Service Account
Navigate to: IAM & Admin → Service Accounts → Create Service Account
Navigate to IAM & Admin → Service Accounts in the left sidebar. Click Create Service Account.
- Service account name:
Clariti AI - Service account ID: Auto-generated (will look like
clariti-ai@your-project.iam.gserviceaccount.com)
Click Create and Continue. The next two steps (Grant access, Grant users access) are optional — click Continue then Done to skip them.
Why: A service account is Google's version of an application identity — it lets Clariti authenticate as a non-human entity rather than impersonating a real user.
Create a JSON Key
Navigate to: Service account details → Keys tab
Click on the service account you just created in the list. Go to the Keys tab. Click Add Key → Create new key → select JSON → click Create.
A JSON file downloads automatically. Save it securely — you'll paste its contents into Clariti.
Don't lose this JSON key file. While you can always create a new key, the old one can't be recovered. Store it somewhere secure until you've pasted it into Clariti.
Why: The JSON key file contains the private key that authenticates the service account. This is the credential you'll paste into Clariti.
Copy the Service Account Client ID
Navigate to: Service account details page
Still on the service account details page, find and copy the Unique ID (also called Client ID). This is a long numeric value — not the service account email address.
The numeric Client ID is on the service account details page, in the "Unique ID" field. It's a number like 123456789012345678. Don't confuse it with the service account email address.
Why: The numeric Client ID (different from the email address) is what you'll enter in the Google Admin console for domain-wide delegation.
Configure Domain-Wide Delegation
Open Domain-Wide Delegation Settings
Navigate to: admin.google.com → Security → Access and data control → API controls → Domain-wide delegation
Open a new tab and go to admin.google.com. Navigate to Security → Access and data control → API controls. Scroll down to Domain-wide delegation and click Manage Domain Wide Delegation.
Click Add new.
Domain-wide delegation lets a service account act on behalf of users in your organization — it's Google's equivalent of Microsoft's "Application permissions." Without it, the service account has no access to your Workspace data, even if the Admin SDK API is enabled.
Why: Domain-wide delegation authorizes the service account to access Workspace data on behalf of users in your organization. Without it, the service account exists but can't read any Workspace data.
Authorize the Service Account
Navigate to: Domain-wide delegation → Add new
In the Add new dialog:
- Client ID: Paste the numeric Client ID from Step 5
- OAuth scopes: Paste the following (comma-separated, no spaces between scopes):
https://www.googleapis.com/auth/admin.directory.user.readonly,https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly,https://www.googleapis.com/auth/admin.directory.device.mobile.readonly
Click Authorize.
Paste all three scopes exactly as shown, comma-separated with no spaces. Google's domain-wide delegation authorization is all-or-nothing per scope set — if even one scope is missing, Clariti's token request for ALL scopes will fail with "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested," not just a partial failure.
These three scopes are the only ones Option B (service account) ever requests. Alert Center, suspicious sign-in detection, over-broad OAuth token grant findings, and group membership enrichment each need an additional scope that Clariti only requests through Option A (Sign in with Google) — adding them to this domain-wide delegation list yourself has no effect, since Clariti's service-account flow never asks for them. If you're on Option B and want those checks, reconnect using Option A instead.
Why: This step maps specific OAuth scopes (data access rights) to your service account, controlling exactly what data Clariti can read.
Copy Your Customer ID (optional — reseller accounts only)
Navigate to: admin.google.com → Account → Account settings
Most organizations can skip this step — leave the Customer ID field blank in Clariti. If you manage a reseller account: still in the Admin console, go to Account → Account settings and copy your Customer ID — it starts with "C" followed by numbers.
The Customer ID is NOT your domain name. It's the alphanumeric ID on the Account settings page that starts with "C" followed by numbers (like C03xyz123). Using your domain name (like company.com) will fail with a cryptic error.
The Customer ID is at admin.google.com → Account → Account settings, in the "Customer ID" field. It starts with a "C" followed by numbers.
Why: Clariti defaults to Google's `my_customer` alias, which resolves to your own organization. You only need an explicit Customer ID if you manage Workspace through a reseller account.
Enter Credentials in Clariti
In Clariti, go to Connectors → Integrations, find Google Workspace, and click Connect. The dialog defaults to Connect with Google (Option A) — click use a service account instead to show the service-account form:
| Value from vendor console | Paste into Clariti field |
|---|---|
JSON key file (downloaded in Step 4) | Service account JSON key (file upload) |
A Workspace super-admin email | Delegated admin email |
Customer ID (Step 8, optional) | Customer ID — leave blank unless you manage a reseller account |
Upload the JSON key file exactly as downloaded (no need to open or edit it). The Delegated admin email is the super admin the service account impersonates for directory reads — typically your own admin address.
Verify Connection
Click Connect Google Workspace. Clariti validates the credentials with Google immediately — a delegation or scope problem shows up right in the dialog. The first sync pulls your user directory and Chrome OS devices (if any); data usually appears within a few minutes.
Alert Center findings
If you connected using Option A (Sign in with Google), Clariti also reads your Google Workspace Alert Center feed — the same alerts your Admin Console surfaces under Reporting → Alert Center (suspicious logins, phishing, leaked passwords, data-loss-prevention matches, and more). Each open alert becomes a Clariti finding, capped at the 25 most severe with a rollup card for the rest.
Alert Center requires the apps.alerts scope, which is only requested by the OAuth ("Sign in with Google") connect flow — not the service-account / domain-wide-delegation path (Option B). If you connected before this capability shipped, or you use Option B, Alert Center data stays silent (not an error) until you reconnect via Option A.
Suspicious sign-in findings
If you connected using Option A (Sign in with Google), Clariti also reads your Login audit log for sign-ins Google's own detection already flagged as suspicious — an unfamiliar location/device, a legacy insecure ("less secure app") protocol, or unusual programmatic/API access. Clariti raises one anomaly finding per affected account per day (not one per event), capped at the 10 most-affected accounts with a rollup card for the rest.
Suspicious sign-in detection requires the admin.reports.audit.readonly scope, which is only requested by the OAuth ("Sign in with Google") connect flow — not the service-account / domain-wide-delegation path (Option B). If you connected before this capability shipped, or you use Option B, suspicious sign-in data stays silent (not an error). Manually adding this scope to the service account's domain-wide delegation authorization has no effect — Clariti's service-account flow never requests it. Reconnect using Option A to enable this check.
Over-broad OAuth token grant findings
If you connected using Option A (Sign in with Google), Clariti also reads each user's third-party app OAuth grants (Admin Console → Security → API controls → App access control) to flag shadow-IT access. A grant is flagged when the app holds full, non-narrowed access to Gmail or Drive, or a write-capable directory scope (the ability to create, modify, or delete users, groups, or devices) — narrower grants (e.g. per-file Drive access) are not flagged. Clariti raises one config_risk finding per user-and-app pair holding such a grant, capped at the 25 most significant with a rollup card for the rest.
Because there is no bulk endpoint for this data, Clariti checks up to 1,000 active users per sync. On a larger directory, findings still fire for every over-broad grant Clariti actually found — an unchecked user is simply not covered yet, not confirmed clean.
Over-broad token grants require the admin.directory.user.security scope, which is only requested by the OAuth ("Sign in with Google") connect flow — not the service-account / domain-wide-delegation path (Option B). If you connected before this capability shipped, or you use Option B, this check stays silent (not an error). Manually adding this scope to the service account's domain-wide delegation authorization has no effect — Clariti's service-account flow never requests it. Reconnect using Option A to enable this check.
Group membership enrichment
If you connected using Option A (Sign in with Google), Clariti also reads your Google Groups and their membership, and attaches the groups each user belongs to onto that user's existing record in Clariti — Groups do not become a separate asset or a second identity record, they only enrich the user directory Clariti already pulls.
Group membership enrichment requires the admin.directory.group.readonly scope, which is only requested by the OAuth ("Sign in with Google") connect flow — not the service-account / domain-wide-delegation path (Option B). If you connected before this capability shipped, or you use Option B, group membership stays silent (not an error). Manually adding this scope to the service account's domain-wide delegation authorization has no effect — Clariti's service-account flow never requests it. Reconnect using Option A to enable this check.
MFA coverage-gap findings
Clariti reads the 2-Step Verification (2SV) status Google already returns on every user record — no extra API call or scope required. If more than half of your active users have not enrolled in 2SV, Clariti raises one coverage_gap finding, worded differently depending on the cause:
- Never enforced — if your org has not turned on 2SV enforcement for most of those unenrolled users, the finding reads as a policy gap ("2SV never enforced") and points you to Admin Console → Security → Authentication → 2-Step Verification to turn on enforcement.
- Enforced but incomplete rollout — if your org already enforces 2SV but users still haven't completed enrollment, the finding reads as a stalled rollout and points you to filter Users by 2SV status = Not Enrolled to send reminders.
Suspended/deprovisioned users are excluded from this calculation — they can't sign in regardless of MFA posture. The finding is silent when most active users are enrolled.
Troubleshooting
401 Unauthorized Domain-wide delegation is not configured or the service account is not authorized. Go back to admin.google.com → Security → API controls → Domain-wide delegation and verify the service account's Client ID is listed with the correct OAuth scopes.
403 Forbidden The OAuth scopes in domain-wide delegation don't match what Clariti is requesting. Verify you pasted both scopes exactly as shown in Step 7, with no extra spaces or missing characters.
"Not Authorized to access this resource/api" Wrong Customer ID. Go to admin.google.com → Account → Account settings and verify you're using the Customer ID (starts with "C"), not your domain name or any other identifier.
"Service account not found" The Client ID entered in domain-wide delegation doesn't match the service account. Go back to the service account details in the Cloud Console, copy the numeric Unique ID again, and update the domain-wide delegation entry in the Admin console.
No data appearing after successful connection If the connection test passes but no users appear, verify that the Admin SDK API is enabled in the Cloud Console (Step 2). Also confirm the service account email has not been blocked in the Admin console's API controls.