[DOCS-ISSUE] - Google: OAuth2 single service: Missing essential steps for local(host) and testing operations, missing information about using scopes

[ackalker]

NOTE!

This is for issues with documentation of n8n. If the problem you are having is actually a bug in the software, please file a bug here instead.

Where is the bug/mistake?
Please help us by pasting in the URL of the page or telling us the title.

https://docs.n8n.io/integrations/builtin/credentials/google/oauth-single-service/?utm_source=n8n_app&utm_medium=credential_settings&utm_campaign=create_new_credentials_modal

What problem did you find?
A clear and concise description of what is wrong.

• The steps in the documentation seem focussed on n8n instances accessible from the internet, although local use is mentioned.
• The steps don't clearly differentiate between testing / development and production deployments in key areas.
• Missing information about important security implications (and how to manage them) of OAuth access by workflows, especially those involving AI agents.

Additional context
Add any other context about the problem here.

The example workflow in the n8n Community Edition guides the user to setup a simple AI agent workflow. The final steps deal with setting up a Google Calendar node as a tool for use by the AI agent, which in turn entails configuring OAuth credentials for access to the Google Calendar API.
Users who aren't familiar with setting up OAuth and who don't understand the different possible flows (such as domain-based versus localhost-based OAuth redirect URLs) may quickly get sidetracked by missing steps for which they need to lookup additional documentation, which in turn may lead users to believe they need to do much more setup (register an internet domain for their n8n instance, setup (D)DNS, do ISP router port forwarding, setup firewall rules, get an SSL certificate, etc.) than is strictly required as a minimum.

When working with AI agents, it is important to limit their access to OAuth backed APIs to the bare minimum required to do their tasks, in case they deviate from or misinterpret their instructions, or else (potentially massive) loss of data or damage to its integrity can occur. This can be done by defining properly restrictive OAuth access scopes.

Can you suggest a fix?
For some issues, like a broken link, it will help us resolve them faster if you can indicate what you think the correct information would be.

Key suggestions for change / improvement:

Local Development: Clarify that for local testing, users can safely use http://localhost (with the appropriate port) as their redirect URI in the Google Cloud Console. No public domain, SSL, or port forwarding is required unless deploying to production.
Relevant documentation for quoting or linking:

• https://support.google.com/cloud/answer/15549257?hl=en#zippy=%2Cweb-applications

Testing Mode: Emphasize that in Google Cloud’s default “testing” mode, users must add their Google account(s) as test users; only these accounts can complete the OAuth flow.
Relevant documentation for quoting or linking:

• https://developers.google.com/workspace/guides/configure-oauth-consent
  (in particular section 2.k regarding 'test users')

OAuth Scopes: Strongly recommend specifying the minimal necessary OAuth scopes for each workflow, with examples and links to Google’s scope documentation.
Relevant documentation for quoting or linking:

• https://developers.google.com/workspace/guides/configure-oauth-consent
  (section 3)
• https://developers.google.com/identity/protocols/oauth2/scopes

Troubleshooting: Add a section for common errors (e.g., “redirect_uri_mismatch”, “invalid_client”) with clear resolutions.

Documentation Structure: Consider a dedicated section contrasting local development and production setup requirements.