Best way to use OAuth 2.0 for Forge Teamwork Graph connector ingestion?

Forge
,
1

I’m building a Forge graph:connector app that ingests Google Drive files into Teamwork Graph / Rovo Search using OAuth (API Key approach works fine).

The manifest defines a Google OAuth provider:


providers:

auth:

- key: google

type: oauth2

scopes:

- profile

- https://www.googleapis.com/auth/userinfo.email

- https://www.googleapis.com/auth/drive.readonly

OAuth works from a Jira global page using api.asUser().withProvider('google', 'google-apis'): after requestCredentials(), listAccounts() returns the authorized Google account.

However, the connector lifecycle functions (validateConnection and onConnectionChange) do not seem to have access to that same OAuth account. In those functions, listAccounts() / hasCredentials() returns no usable credentials, even though the global page shows the account as authorized.

My questions:

  1. Is Forge external OAuth intended to be usable inside graph:connector lifecycle functions such as validateConnection and onConnectionChange?
  2. If yes, what is the correct way to bind the Google OAuth account/token to a specific connector connection?
  3. If no, is the recommended pattern for private Google Drive ingestion to use a backend credential such as a Google service account instead?
  4. What role does graph:connector.auth.provider play here? Is it only for end-user identity/permission mapping, or should it also make the provider credentials available to connector callbacks?
2

Hi Martin,

Is Forge external OAuth intended to be usable inside graph:connector lifecycle functions such as validateConnection and onConnectionChange?

Not in the current form where we make the calls via asUser().withProvider(‘google’). I am trying to replicate exactly what you are doing and will get back with my findings.

If no, is the recommended pattern for private Google Drive ingestion to use a backend credential such as a Google service account instead?

Google service account is the correct way till we allow Admin Oauth flow while setting up Forge Connectors. This is coming up as a parity thing between what we currently have in Rovo connectors vs Forge ones.

What role does graph:connector.auth.provider play here? Is it only for end-user identity/permission mapping, or should it also make the provider credentials available to connector callbacks?

Your instinct is correct here. This is used to do the user mapping to make ACL/Perms of the ingested entities work correctly. You can also do the mapping via mapUser() in the SDK