Copy page

Google Identity

Twin of the Sign in with Google OAuth 2.0 and OpenID Connect provider.

The issuer behind Sign in with Google. It mints the tokens the Google Drive, Gmail and Google Calendar twins verify.

Covers	accounts.google.com, oauth2.googleapis.com, openidconnect.googleapis.com, www.googleapis.com
Auth	OAuth client id and secret, bearer access tokens
Issues tokens for	Google Drive, Gmail, Google Calendar
Operations	15

Coverage

Two grants: authorization code and refresh token. The endpoints behind them are authorize, token, revoke, tokeninfo, both userinfo shapes, the discovery document and the certificate endpoints, each on Google’s own host and path.

This twin is added to your environment automatically when you ask for a Google product twin that needs it, so you rarely request it directly.

Credentials

Any well-formed client id and secret authenticate by default, as long as the client id has Google’s own shape. Set auth.mode to enforced to accept only the clients the world knows. See Credentials.

Vendor specific details

• Google is slash sensitive. /token/ is a 404, and so is a wrong method, never a 405. A trailing slash on a real path returns JSON; a wholly unknown path returns Google’s HTML 404 page.
• A rejected bearer on userinfo is 401 invalid_request with “Invalid Credentials” and no WWW-Authenticate header at all, whatever RFC 6750 says.
• The refresh token comes back only on the code exchange, and only when you asked for access_type=offline. A refresh grant returns a new access token and never echoes the refresh token again.
• A client id that Google could not have minted is refused in every mode. It has to look like digits-suffix.apps.googleusercontent.com.

Its own notes

Once a sandbox is running, this twin serves its own operating notes at {control_url}/veris/manual: the credentials it accepts, the API versions it serves, and the fault statuses you can arm against it. They are generated from the same source as its behaviour, so they cannot drift.