Pushrail Docs
Open app
Guides · Destinations

Connect with Google (OAuth)

Connect a GCS, BigQuery, or Pub/Sub destination by signing in with Google, the trade-offs of user OAuth, and how to keep the connection from breaking under a Workspace reauthentication policy.

Connect with Google (OAuth)

Google sign-in (OAuth) is no longer offered when you create a new destination — choose the IAM service-account binding (or a service-account key) instead. This page covers destinations that were already connected with Google OAuth: they keep working, and you can still reconnect them.

Some GCS, BigQuery, and Pub/Sub destinations authenticate by signing in with Google: a token obtained when someone clicked Connect with Google and approved access. It is the quickest way to get a destination working, with no IAM policy to write and no key file to download.

It is also the least durable option, which is why it is no longer offered for new destinations. If you have an existing Google OAuth connection, this page explains what it depends on and how to keep it alive.

Prefer the IAM service-account binding

Granting our service account access with an IAM binding is the recommended option. The binding is owned by your organization, not a person, so it survives staff changes and is never subject to a personal reauthentication prompt. The destination form walks you through it when you pick "Grant our service account access." Migrating an existing OAuth destination is just a matter of switching its auth method to the binding and saving.

The downsides of Google OAuth

A Google OAuth connection is tied to the person who authorized it. If that account is suspended, deleted, leaves the company, or has its access to the target resource removed, the connection stops working and deliveries fail until someone reconnects.

Beyond the account-ownership risk, two Google behaviors commonly break OAuth connections:

  • Workspace reauthentication policy. If your Google Workspace organization enforces Google Cloud session control (a periodic re-sign-in for Google Cloud access), the stored token cannot be refreshed once the session ages out. The refresh fails with a reauth error (invalid_rapt) and the destination shows "credential is no longer active" until a human reconnects in the browser. This is the single most common cause of a healthy OAuth destination going dark. The fix is to exempt Pushrail as a trusted app, below.
  • Token revocation. The authorizing user can revoke Pushrail's access at any time from their Google Account's third-party access page. Doing so immediately breaks the connection.

If none of these apply to you (for example, you are connecting with a consumer Google account, or your Workspace has no reauthentication policy), OAuth will keep working on its own and you can skip the next section.

Keep OAuth working under a reauthentication policy

If your organization enforces Google Cloud session control, mark Pushrail as a trusted app so its token is exempt from the periodic reauthentication challenge. This is more surgical than turning reauthentication off for everyone. You need to be a Google Workspace super administrator.

  1. Exempt trusted apps from reauthentication. In the Admin console, go to Security → Access and data control → Google Cloud session control. Select the organizational unit that contains the connecting account, and enable the option to exempt trusted apps from reauthentication. Save.
  2. Add Pushrail to your trusted apps. Go to Security → Access and data control → API controls → App access control, choose Manage third-party app access → Configure new app, find the Pushrail app (search by name, or paste its OAuth client ID as shown on the consent screen), and set its access to Trusted. Save.
  3. Wait a few minutes for the policy to propagate, then reconnect the destination once. The earlier connection's token was already invalidated by the failed refresh, so a fresh sign-in is required regardless.

Marking an app trusted applies to the whole organizational unit, not just one user. If you would rather not change the policy that broadly, place the connecting account (or a dedicated service identity) in a child organizational unit and configure it only there.

Even with this in place, the connection is still tied to the authorizing user's account. Exempting the trusted app removes the reauthentication breakage; it does not remove the account-ownership risk. For a connection that depends on nobody, use the IAM service-account binding.

Reconnecting

When a connection breaks (the destination shows "credential is no longer active" or a connection-expired banner), open the destination and click Connect with Google again. The new sign-in replaces the stored token in place. No configuration is lost, and queued deliveries resume on the next attempt.