This integration is in preview.
Prerequisites
Complete the preparation checklist.
Application setup
In the Google Cloud console, select the project owning the sign-in application. In Google Auth Platform > Branding, set its name, support email, and contact details. Under Audience, choose Internal for that Workspace organization or External for approved accounts outside it. Add approved test users while an External app is in Testing and complete the production publishing requirements before cutover.
Under Data Access, request only openid, profile, and email. Under Clients, create a Web application and set Authorized redirect URIs to https://api.<platform-host>/identity/callback. Save the client secret securely. This server-side integration needs no Authorized JavaScript origins entry and no Gmail or Drive permission.
Use your Istari domain for <platform-host>. For a custom API hostname or base URL, use the configured callback address.
Collected values
Collect the Client ID and secret from the client registration. The issuer is exactly https://accounts.google.com, without a Workspace domain or project ID. For Workspace accounts, a directory administrator can export immutable user IDs with users.get or paginated users.list; that is an administrative export, not an Identity Service runtime permission. For personal accounts, obtain sub from a validated response in controlled setup with engineering assistance, without copying tokens into support records.
Installation configuration
identity:
oidc:
provider: google
issuer: "https://accounts.google.com"
clientId: "<client-id>"
clientAuthMethod: client_secret_basic
scopes: "openid profile email"
idpMigration:
enabled: false
Store ISTARI_DIGITAL_IDENTITY_SERVICE_OIDC_CLIENT_SECRET in the Identity Service Secret. Set ISTARI_DIGITAL_IDENTITY_SERVICE_ENROLLMENT_POLICY=pre-registered-only.
Account preparation
Prepare explicit sub mappings and set identity.idpMigration.enabled: false. For new people, use import-humans -provider google with an upstream_subject column; for existing people, use the shared subject mapping procedure with new_provider=google. Workspace and personal accounts are supported. Personal accounts cannot claim email-only registrations. Workspace email claiming is limited to a pending registration explicitly created for google, with email_verified=true and a nonempty hd claim. An email suffix is not proof of that claim, and hd never grants tenant membership.
See account import commands and administrator setup.
Verification
Confirm imported Workspace and personal subjects resolve to the intended local principal. Exercise local refresh, sign-out, and sign-in again. Verify the old local refresh token remains invalid after logout and that the new login keeps the same account. Run the shared continuity checks for existing users.
Limitations
The service adds access_type=offline; do not request offline_access. It does not force prompt=consent or send an hd account-selection hint. Google may return a refresh token only at initial consent. An encrypted existing grant can be reused only after a new validated login for the same issuer, client, and sub. Logout revokes Istari sessions locally and retains a dormant encrypted grant; it does not end the Google SSO session. A later login can therefore proceed without another password prompt. Google has no OIDC end_session_endpoint for this integration.
Verify account access, editing, and sharing for your Workspace or personal-account setup before rollout. See Google's web application guide.