Sign in with Google

Overview

Some applications only expose authenticated surface through Sign in with Google. Pensar can drive that flow with a Google user minted on the workspace agent inbox — a real Cloud Identity account with a stored password and employee ID.

Workspace members cannot create these accounts. A Pensar admin mints the user on Admin → Agent Inboxes (Cloud Identity Free is capped at 50 seats). You then invite that address into your product, set the login URL, and run a credential test.

Do not add a Google login as a normal Username & Password credential. The minted row is labeled Google and is what the agent uses to click your Sign in with Google button.

Workflow

1

Ask Pensar to mint the Google user

A Pensar admin opens Admin → Agent Inboxes, selects the workspace inbox, and creates a Google account. That writes a workspace credential whose username is the inbox email (…@agents.pensar.dev or your stage’s inbox domain). The password and Google employee ID are stored with the credential and cannot be edited in the console.

2

Invite the inbox email in your product

In your application (or Google Workspace / IdP admin, depending on how you grant access), invite that exact inbox address as a user who can Sign in with Google. Until the address is a valid user of your product, the login will fail at Google or bounce back from your app.

3

Set the login URL

Open Settings → Credentials, find the row labeled Google, and set Login URL to the page on your product that starts Sign in with Google (the page with the Google button). Save. Pensar does not auto-test this credential until that URL is set.

4

Run a credential test

After save, Pensar queues a credential test. The agent opens the login URL in Chrome, clicks your Google button, fills the Google email and password (and the employee ID if Google asks to verify the account), then returns to your app. A successful test shows Authenticated.

What the agent does

  • Goes to the Login URL you set and clicks the product’s Google / Sign in with Google control. It does not fill your native username and password form.
  • Completes Google’s identifier and password prompts. Secrets are filled by reference, not pasted into the prompt.
  • If Google asks to verify the account, it fills Google employee ID from the credential’s additional field.
  • Fails closed on “this browser or app may not be secure”, a CAPTCHA, or a blocked-app interstitial. It will not attempt account recovery.

Pentest and retest runs that include this credential use the same Chrome + Google path.

After you delete the inbox

Deleting the inbox Google user also deletes the matching workspace credential, so a leftover password row cannot be reused.

  • Authentication — other credential types (username/password, bearer token, custom headers, mTLS)
  • Adding domains — attaching credentials when you add a domain