Google Workspace — server administrator setup
Configure Google Workspace once for your Nautilo Server, then let each person connect their own account.
For server administrators. Google makes this setup more fiddly than it should be, but you only need to do it once for your Nautilo Server. Work through these steps, then everyone can connect their own Google account.
Just connecting your account? Use Connect your Google account. You do not need to create a Google project, enable APIs, or upload credentials.
1. Create a Google project and enable its APIs
- Open Google Cloud Console.
- Open the project selector at the top. Select your existing project, or choose New Project, name it Nautilo Workspace, and choose Create. For company-only access, select your company's organization when creating it.
- Select that project. Keep using it for every Google Cloud step below.
- Open APIs & Services → Library. Search for each API below, open it, and choose Enable. Manage means it is already enabled.
- Google Drive API
- Google Docs API
- Google Sheets API
- Google Slides API
- Gmail API
- Google Calendar API
If your organization restricts project creation, ask its administrator to create the project for you.
2. Register your Google app
- Open Google Auth platform → Branding → Get Started.
- Enter an app name, such as Nautilo Workspace, and your support email. Choose Next.
- Choose External for personal Gmail accounts or people from different organizations. Choose Internal if everyone belongs to the project's Google organization. Choose Next.
- Enter your contact email, choose Next, accept Google's policy agreement, then choose Continue → Create.
An existing app can use its current branding. External apps initially use Testing; switch to In production in step 5, before connecting anyone, to avoid weekly sign-ins.
3. Create the Desktop client and download its JSON
- Open Google Auth platform → Clients → Create Client.
- Choose Desktop app, name it Nautilo Desktop, and choose Create.
- Download the JSON immediately, before closing the creation dialog. Save it somewhere private; you will upload this file in step 6.
Choose Desktop app even when your Nautilo Server runs in the cloud. This flow needs no Server URL, redirect URL, or router configuration. Google only shows a new client's complete secret at creation, so keep the downloaded file. See Google's client instructions.
4. Add the requested permissions
For an External app:
- Open Google Auth platform → Data Access → Add or Remove Scopes.
- Expand the list below and add its scopes. Use Manually add scopes for any scope missing from the picker.
- Choose Update, then Save.
An Internal app can continue to step 5; Google does not require the same consent-screen scope declaration for that audience.
These permissions include write access and additional Google services beyond Nautilo's current tools. Approve them only for accounts you want to give that access.
Expand and copy the Google permission list
openid
email
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/documents
https://www.googleapis.com/auth/spreadsheets
https://www.googleapis.com/auth/presentations
https://www.googleapis.com/auth/gmail.modify
https://www.googleapis.com/auth/gmail.settings.basic
https://www.googleapis.com/auth/gmail.settings.sharing
https://www.googleapis.com/auth/calendar
https://www.googleapis.com/auth/forms.body
https://www.googleapis.com/auth/forms.responses.readonly
https://www.googleapis.com/auth/script.projects
https://www.googleapis.com/auth/script.deployments
https://www.googleapis.com/auth/script.processes
https://www.googleapis.com/auth/contacts
https://www.googleapis.com/auth/contacts.other.readonly
https://www.googleapis.com/auth/directory.readonly
https://www.googleapis.com/auth/tasksThis matches Nautilo's current Desktop request. Changing this declaration in
Google Console does not change the permissions Nautilo requests at sign-in.
For example, listing only gmail.readonly here does not make the connection
read-only. The mapping is in the
Google client's source.
Google's Data Access instructions explain manual entry, including scopes for APIs not enabled in the project.
5. Keep the connection working beyond seven days
For an External app used by you or a few people you know:
- Open Google Auth platform → Audience.
- Under publishing status, choose Publish app → Confirm.
- Check that it says In production before continuing.
Use In production, not Testing. Testing expires these authorizations after seven days. Production removes that weekly expiry and lets the connection keep renewing access automatically. There is no “forever” timeout to select; Google can still revoke access. If you already connected in Testing, reconnect once after this change. Google's audience rules.
For an eligible Internal app, keep Internal and continue. That route does not have External Testing's seven-day expiry.
Inviting unrelated outside users? Complete Google's verification requirements before offering the app broadly. An unverified External app requesting these permissions has a 100-new-user lifetime cap; publishing alone does not lift it. Expand the verification details below if that applies to your deployment.
External users: verification, the 100-user cap, and security assessment
Google distinguishes personal use by you/a few people you know, organization-only Internal use, and apps offered more widely. Being self-hosted or having fewer than 100 users does not itself exempt an app from verification.
| Setup | What applies |
|---|---|
| External, Testing | Up to 100 listed test users; these user-data authorizations expire after seven days. |
| External, unverified, In production | An unverified-app warning and a 100-new-user lifetime cap for unapproved sensitive/restricted scopes. Removing users does not reset it. |
| External, verified for the requested scopes | The unverified-app cap does not apply for approved scopes. Adding unapproved scopes can bring it back. |
| Eligible Internal app | Organization-only access with a verification exception. Organization app controls still apply. |
Check Audience for your project's actual quota. Google can adjust limits. These rules come from Google's audience documentation and unverified-app guidance.
For wider External use:
- Review the requested scopes and justify why each is needed. Nautilo currently requests additional permissions beyond its exposed tools; account for those in the review rather than declaring a narrower request.
- Prepare your application's public homepage and privacy policy, covering Google data use, storage, sharing, and model processing.
- Verify your authorized domains in Google Search Console with an account associated with the Cloud project. Use domains you control.
- Complete Branding → Verify Branding, resolve issues, then Publish branding.
- Follow Verification Center for data-access review. Provide scope justifications and the requested demonstration of sign-in, consent, and features using those scopes. Monitor your contact inbox.
Restricted-scope data passing through servers can require a Google-approved assessor and a CASA security assessment, with annual reassessment, unless an exception applies. Desktop sign-in does not establish an exception when data also reaches your Nautilo Server or model providers. Google's restricted-scope guide and sensitive-scope guide explain the requirements and exceptions.
Publish app changes the audience's publishing status; it is separate from verification and branding approval. It does not make your Nautilo Server public, but the Testing account list no longer restricts the Google app's audience. Control access to Nautilo through its own accounts and permissions.
Company or school accounts: allow the app if your organization requires it
A Workspace administrator with Service Settings privilege can approve the specific client before people connect:
- Open Google Admin → Security → Access and data control → API controls → Manage App Access.
- Choose Configure new app and search by the OAuth client ID created in step 3.
- Select the app and the organizational units that need access.
- Choose Specific Google data and configure the approved scopes, including Google sign-in scopes. Trusted permits access to all Google services; Limited only permits unrestricted services.
- Continue, review, and finish. Allow policy changes to propagate before retrying; Google says this can take up to 24 hours.
Approve this client rather than lifting restrictions for all apps. These controls can also affect Internal apps. See Google's app-access instructions.
6. Upload the JSON to Nautilo
- Sign into your Nautilo Server as an administrator allowed to manage connection providers.
- Open Connections → Apps & accounts → Google Workspace.
- Under Set up Google Workspace for this server, find Google OAuth client JSON and choose Choose JSON.
- Select the downloaded file from step 3. Wait for Connect your Google account to become available.
The Server setup is complete. Each person now connects their own Google account; uploading this file does not share the administrator's mailbox.
If a managed Nautilo Cloud Server says the integration is unavailable, its hosting administrator manages this configuration.
7. Test the connection and invite your users
Follow Connect your Google account with your own account and confirm that your Genie retrieves your calendar. Then send your users that same short guide, not this administrator guide.
They only sign in to their own Google account. They reuse the Server setup you have completed; they need no Google Cloud project, OAuth client, or JSON file.
More help, only if you need it
Fix a connection problem
| What you see | What to do |
|---|---|
| No setup/upload controls | Use a Nautilo account allowed to manage connection providers; check whether hosting manages the configuration. |
| JSON rejected | Use the saved, complete Desktop OAuth client JSON. It contains an installed section with client_id and client_secret. API keys and service-account keys are different files. |
| Lost client JSON | Recover your private backup. Google only exposes newly created secrets at creation; use supported secret rotation where available or deliberately replace the client and update Nautilo. Preserve the working client until you have a replacement plan. |
redirect_uri_mismatch | Use a Desktop app client and upload its JSON. A Web client can pass file validation but fail at login. |
org_internal | Connect an account in the project's organization, or have the project owner select the appropriate audience. |
access_denied or “developer hasn't given you access” | Check Audience: use In production for ongoing External use. If deliberately testing, add the exact account under Test users. Also check cancelled consent and organization policy. |
admin_policy_enforced or an organization block | Ask your Workspace administrator to approve the client using the company-account instructions in step 5. |
| “Google hasn't verified this app” | Check that the app is your intended client. Review its audience and verification status with the administrator. |
API disabled, SERVICE_DISABLED, or accessNotConfigured | Enable the named API in the same project as the uploaded client, allow propagation, then retry. |
| Insufficient authentication scopes | Check the permissions granted at consent and organization app controls. Correct the configuration, then reconnect. |
invalid_client or deleted_client | Check that the client exists and the JSON belongs to it. Google may allow restoration within 30 days of deletion; otherwise replace it deliberately and reconnect. |
| Login fails about seven days later | Set Audience → Publish app → In production, then reconnect once. |
invalid_grant, expired authorization, or Reconnect | Reconnect through Nautilo. If it repeats, check Testing status, revoked access, password changes, and Google account policies. |
| Callback fails or sign-in times out | Keep Desktop open and complete sign-in on the same computer. Check local loopback blocking, then restart Continue with Google. This connection needs no publicly forwarded port. |
gog_missing | Repair/update Nautilo Desktop to restore its local Google runtime. |
| Connected, but Genie cannot use Google | Check your Google Workspace permission in Nautilo and that Desktop remains connected to the Server. |
| File not found or permission denied | Open the file with the connected Google account and check that it has access. |
Google documents Desktop authorization errors. For support, share the failed step and error code. Keep client secrets, tokens, full callback URLs, and private document contents out of the report.
What Google Workspace currently supports in Nautilo
Workspace is Google's current name for G Suite. Personal Gmail accounts can connect too; a paid Workspace subscription is not required for this setup. A Google Gemini API key supplies model access, not access to mail or documents.
| Service | Current Nautilo tools |
|---|---|
| Drive | File search and metadata |
| Docs and Sheets | Supported reading, creation, and editing operations |
| Gmail | Message search and reading; sending is not currently exposed |
| Calendar | Event reading and a creation preview; the preview does not create an event |
| Slides | Presentation information and slide inspection |
The current sign-in request also includes Forms, Apps Script, Contacts, and Tasks permissions, without corresponding Nautilo commands. Gmail and Calendar scopes include write access beyond the current tools. Enabling more APIs alone does not add tools.
The six APIs in step 1 have service IDs drive.googleapis.com,
docs.googleapis.com, sheets.googleapis.com, slides.googleapis.com,
gmail.googleapis.com, and calendar-json.googleapis.com. See Google's
API directory.
Google restricts operations using gmail.settings.sharing to Workspace service
accounts with domain-wide delegation. Requesting that scope does not make those
operations available through Nautilo's Desktop sign-in. This setup needs a
Desktop client, not domain-wide delegation. See Google's
Gmail scope definitions.
Personal authorization currently happens in Desktop, not the browser or mobile client. The Desktop runtime provides the connection while running and connected.
Keep access working, change accounts, or disconnect
In production removes External Testing's weekly expiry. Nautilo's Google runtime uses refresh tokens to renew short-lived access tokens automatically; there is no need to reconnect for each normal access-token expiry.
Google does not guarantee permanent authorization. Revoked access, six months without refresh-token use, password changes affecting Gmail access, time-limited grants, and token limits can require another sign-in. Google permits 100 refresh tokens per Google account per client ID; issuing more invalidates the oldest. This is separate from the app's 100-user cap. See Google's token-expiration rules.
Use Change account or Disconnect on Nautilo's Google Workspace card. An expired connection offers Reconnect, Use a different Google account, and Remove account. To revoke access at Google, use your account's third-party connections. Removing a local connection does not revoke every other device's grant.
Keep the downloaded JSON, project ID, client ID, and project recovery details in your private credential store. Reuse the working Server configuration when one person reconnects; replacing the OAuth client affects other users too.