Setting up Google
Creating an OAuth application, the scopes each service needs, and the consent screen decision that determines whether connections last.
You create one OAuth application in your Google Cloud project. Members then connect their own accounts against it, and the assistant acts with each member's own permissions.
This page is the setup walkthrough. Connectors covers the policy questions worth deciding first, and Setting up Microsoft is the equivalent for Microsoft 365.
1. Decide the consent screen first
This is the decision that determines whether your rollout survives, so make it before creating anything.
Internal is the right answer if everyone who will connect is in your own Google Workspace. Connections last, and none of the verification below applies.
External means Google treats your application as public. Two consequences follow:
- While the screen is in Testing, Google expires every connection after seven days no matter how often it is used. Members reconnect weekly, blame the assistant, and stop using it.
- Moving it to production while requesting Gmail or full Drive access requires Google's verification and a third-party security assessment, renewed annually.
If your members are all in your Workspace, choose Internal.
2. Create the OAuth application
In the Google Cloud console, pick or create a project, then:
- APIs & Services, then OAuth consent screen. Choose Internal or External per the decision above, and fill in the application name and support contacts.
- Enable the APIs for the services you intend to offer: Google Drive, Gmail, Google Calendar, Google Docs, Google Sheets, Google Slides. An API that is not enabled fails at the moment a member first uses it, not when they connect.
- Credentials, then Create credentials, then OAuth client ID. Application type Web application, and add the authorised redirect URI
https://app.asteria-labs.com/api/connectors/callback. - Copy the client ID and client secret.
3. The scopes each service uses
You do not enter these anywhere in Asteria Cloud; we request them when a member connects, based on the services they select. They are listed so you can see what your members are approving, and add them to your consent screen's scope list.
| Service | Scopes | What it is used for |
|---|---|---|
| Drive | drive.readonly | Reading Drive files, and mirroring a folder into a collection |
| Gmail | gmail.modify | Reading, searching, drafting and sending mail |
| Calendar | calendar.events, calendar.calendarlist.readonly | Reading the calendar and creating events |
| Docs, Sheets, Slides, Drive uploads | drive | Creating and editing documents, and saving deliverables into a folder |
| Directory | admin.directory.group.readonly, cloud-identity.groups.readonly | Checking which groups a person belongs to, so a mirrored Drive folder shows each person only what they can already open |
Three things about this table are Google's design rather than ours, and members will ask about all three.
Docs, Sheets, Slides and Drive uploads share one scope. They are one permission with four names, so enabling any of them enables all four. There is no way to offer document editing without also allowing spreadsheet editing.
That shared scope is full Drive access, not just the documents being edited. Google only grants document commenting together with access to files generally, so editing one document means the application can reach the member's Drive. This is the scope that makes an External consent screen expensive.
Gmail and full Drive are both restricted scopes. On an Internal consent screen this costs nothing. On an External one it is the verification and assessment described above.
4. Register it in Asteria Cloud
In the console, go to Connectors, then Google, and enter the client ID and client secret. Turn the Google Workspace switch on. Members cannot connect until it is on.
Members then go to Profile, then Connections, connect their account, and choose which services to allow. They can only change that selection by disconnecting and reconnecting, so the consent screen is worth getting right the first time.
5. Optional: group access to shared files
When a collection mirrors a Drive folder, Asteria Cloud shows each person only the files they can already open in Drive. Files shared with an individual work with no extra setup. Files shared with a Google group need one more step, because we have to be able to check who belongs to that group.
Add the Directory row from the table above to your consent screen, and have members select Directory when they connect. Nested groups resolve where your Google Workspace edition supports Cloud Identity; otherwise direct membership is used.
Without it, a file shared only with a group stays hidden from everyone. That fails in the safe direction, files are never shown to someone who should not see them, but hidden files look like the assistant losing documents, so it is worth closing if your teams share by group.