Google Workspace no soporta el mismo modelo de client credentials que M365. La forma canónica es un service account con domain-wide delegation que un admin autoriza para impersonar en tu dominio.

Paso 1 — Crear el service account

En Google Cloud Console → IAM & Admin → Service Accounts → Create:

• Name: emate-workspace-sspm.
• Otorgale rol: ninguno dentro de GCP. No necesitamos permisos GCP.

Al final del wizard, Keys → Add key → JSON. Descargá el JSON — no se puede recuperar después.

Guardá el Unique ID del service account (aparece como Client ID en la sección Details).

Paso 2 — Habilitar domain-wide delegation

En el service account → Details → Domain-wide delegation → Enable.

Paso 3 — Autorizar los scopes en Admin Console

En admin.google.com → Security → API Controls → Domain-wide Delegation → Add new:

• Client ID: el Unique ID del paso 1.
• OAuth scopes (separados por coma):

https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/admin.directory.group.readonly,
https://www.googleapis.com/auth/admin.directory.orgunit.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.reports.audit.readonly,
https://www.googleapis.com/auth/gmail.settings.basic,
https://www.googleapis.com/auth/gmail.settings.sharing,
https://www.googleapis.com/auth/drive.metadata.readonly

Autorizá.

Paso 4 — Elegir el email admin a impersonar

El service account por sí solo no puede leer nada — necesita impersonar un user con privilegios. Elegí un email admin de tu dominio (idealmente uno dedicado a esta integración, ej: [email protected]).

Paso 5 — Configurar en la plataforma

En Integraciones → Google Workspace → Configurar credenciales:

• Subí el JSON del service account.
• Ingresá el email admin a impersonar.

La plataforma:

1. Valida el JWT flow (JWT firmado con la key privada → intercambio por access_token).
2. Confirma que puede listar users con el admin impersonado.
3. Corre el primer sync manualmente.

Consideraciones

Auditoría

Cada llamada de Directory API queda auditada en el log de Workspace bajo el email admin impersonado. No mezclamos con logs de un user real — dedicarle un admin específico simplifica el forensic.

Rotación de la key

Rotá la key cada 6-12 meses:

1. Generá una key nueva desde Google Cloud Console.
2. Subila en la plataforma (reemplaza la vieja).
3. Deletea la key vieja desde Google Cloud Console.

Cero downtime.

Diferencias con M365

• Google no tiene el equivalente a Identity Protection (risky users con levels/states). El tab “Riesgo” en el drill-down muestra solo sign-in history + geo, sin risk_level.
• Mailbox audit en Workspace se hace vía Reports API (audit logs) — la plataforma parsea eventos de tipo LOGIN y MAILBOX_ACCESS. Sin equivalente exacto al mailbox audit summary de Exchange.
• External shares — Workspace usa Drive API. La plataforma detecta files compartidos con “anyone” o con dominios externos, igual que en SharePoint pero con schema distinto.

Todo esto se refleja en el dashboard SSPM sin acción del usuario — la lógica se ajusta al vendor.

Comparativa rápida

Feature	M365 (Entra P2)	Google Workspace
Risky users con level/state	✓ Identity Protection	✗
Sign-in history + geo	✓ auditLogs/signIns	✓ activities.list applicationName=login
External shares	✓ SharePoint API	✓ Drive API
Inbox rules	✓ Exchange Rules	✓ Gmail Settings Sharing
OAuth apps	✓ Application + oauth2PermissionGrants	✓ Directory Token Auditing
Mailbox audit summary	✓ Exchange audit config	✗ (aproximación via Reports API)
Password policy	✓ Authentication methods policy	✓ Admin SDK
Conditional Access	✓ Policies + assignments	Aproximación via Context-Aware Access