Is it possible to connect public users Oauth2 connection to the n8n workflow and run automations on their google drive that they logged in with?

Questions
1

Describe the problem/error/question

Is it possible to connect public users Oauth2 connection to the n8n workflow and run automations on their google drive that they logged in with? Meaning I have an automation where (in a perfect world) a user would log into through the website using google Oauth2 and is stored in supa base. then I would take the users google credentials and connect them to the workflow and run the automation. only issue is that n8n doesn’t allow (seemingly) for the credentials to replace the credentials that were only previsouly established before hand. Any idea on how to solve it?

What is the error message (if any)?

The workflow naturally works, just want to connect the users to the workflow.

Please share your workflow

{
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "revunote-intake",
        "responseMode": "lastNode",
        "responseData": "firstEntryBinary",
        "options": {
          "binaryPropertyName": "file"
        }
      },
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2.1,
      "position": [
        480,
        -16
      ],
      "id": "",
      "name": "Upload File",
      "webhookId": "44428cf2-a7ee-4d92-b724-055dfbaba5ef"
    },
    {
      "parameters": {
        "resource": "fileFolder",
        "searchMethod": "query",
        "queryString": "=mimeType = 'application/vnd.google-apps.folder'",
        "returnAll": true,
        "filter": {},
        "options": {}
      },
      "type": "n8n-nodes-base.googleDrive",
      "typeVersion": 3,
      "position": [
        1248,
        -16
      ],
      "id": "",
      "name": "Search files and folders",
      "alwaysOutputData": true,
      "notesInFlow": false,
      "credentials": {
        "googleDriveOAuth2Api": {
          "id": "u9ajJ6QE7LBIWuuW",
          "name": "Google Drive account"
        }
      }
    },
    {
      "parameters": {
        "resource": "image",
        "operation": "analyze",
        "modelId": {
          "__rl": true,
          "value": "models/gemini-2.0-flash-exp-image-generation",
          "mode": "list",
          "cachedResultName": "models/gemini-2.0-flash-exp-image-generation"
        },
        "text": "",
        "imageUrls": "={{ $json.fileUri }}",
        "options": {}
      },
      "type": "@n8n/n8n-nodes-langchain.googleGemini",
      "typeVersion": 1,
      "position": [
        1040,
        -16
      ],
      "id": "",
      "name": "Analyze an image",
      "credentials": {
        "googlePalmApi": {
          "id": "",
          "name": "Google Gemini(PaLM) Api account 2"
        }
      }
    },
    {
      "parameters": {
        "resource": "file",
        "inputType": "binary",
        "binaryPropertyName": "file0"
      },
      "type": "@n8n/n8n-nodes-langchain.googleGemini",
      "typeVersion": 1,
      "position": [
        864,
        -16
      ],
      "id": "",
      "name": "Upload a file",
      "credentials": {
        "googlePalmApi": {
          "id": "IUTxxPbV8Mebe9Qr",
          "name": "Google Gemini(PaLM) Api account 2"
        }
      }
    },
    {
      "parameters": {
        "tableId": "user_connections",
        "dataToSend": "autoMapInputData"
      },
      "type": "n8n-nodes-base.supabase",
      "typeVersion": 1,
      "position": [
        688,
        -16
      ],
      "id": "6263e8a4-141c-419d-afbf-192259f7ddd4",
      "name": "Get User",
      "credentials": {
        "supabaseApi": {
          "id": "q3o8MyNYWE4mc9pO",
          "name": "Supabase account"
        }
      }
    }
  ],
  "connections": {
    "Upload File": {
      "main": [
        [
          {
            "node": "Get User",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Search files and folders": {
      "main": [
        []
      ]
    },
    "Analyze an image": {
      "main": [
        [
          {
            "node": "Search files and folders",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Upload a file": {
      "main": [
        [
          {
            "node": "Analyze an image",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Get User": {
      "main": [
        [
          {
            "node": "Upload a file",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "pinData": {},
  "meta": {
    "templateCredsSetupCompleted": true,
    "instanceId": ""
  }
}
The rest is not required for the question

Information on the n8n Setup:

  • n8n version: 1.122.4
  • Database (default: SQLite): N/A
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): render.com
  • Operating system: mac
2

Google OAuth and I are oft-engaged enemies. I can’t solve this with my experience. But when I saw that nobody has replied yet, I asked ChatGPT and it offered some insight that may make you think of a solution. I did not send it any JSON, just the issue:

HTH

Yes — what you’re describing can be built, but it doesn’t “just work” in n8n the way people expect, because n8n credentials are not runtime-dynamic in the sense of “swap the credential based on the incoming user.” In n8n today, most nodes resolve credentials by a static credential reference (an internal ID) that’s chosen at design/config time.

a) Why it doesn’t work (and should it work?)

Why it doesn’t work (the core issue)

  • In n8n, a node typically points to one credential entity stored inside n8n.

  • During execution, the node does not accept “here’s a refresh token/access token in the incoming item, use that instead.”

  • So your workflow can’t simply “replace credentials on the fly” per user. This is the exact multi-tenant wall people hit.

Should it work?

Conceptually, yes, for SaaS/multi-tenant. Practically, n8n’s credential model was designed around:

  • a workspace/team owning credentials, and

  • workflows using those credentials consistently.

n8n does have “credential overwrites” — but that’s mainly to hide client configuration fields (client id/secret, auth URLs) so users can click “Connect” without seeing internals. It is not “per-run token swapping.”

Security / gatekeepers you’re running into (Google + platform)

Even if n8n let you swap tokens freely, Google adds real constraints:

  • If you request sensitive/restricted scopes, Google can require verification and possibly a security assessment. (Drive scopes often fall into “sensitive,” and some are “restricted” depending on scope choice.)

  • For Google Workspace tenants, admins can restrict which OAuth apps can access Workspace data; allowlisting and scope controls apply.

Those don’t prevent your design, but they do affect “public users onboarding on-the-fly” if your scopes trigger review requirements.

b) If it can work, how?

You have three workable architectures. Pick based on whether you want n8n to be the credential store, or just the orchestrator.

Option 1 — n8n as the credential store (best if you want “native Google nodes”)

Pattern: Create one n8n user (or project/workspace separation) per tenant/user, have them OAuth-connect inside n8n, then run workflows in that context.

How it works:

  1. You embed or expose n8n credential-creation UX so the user clicks “Sign in with Google.”

  2. You hide your Google OAuth app settings using credential overwrites so users don’t see/alter client details.

  3. Each tenant ends up with their own stored credential in n8n, and workflows run using that credential.

Pros:

  • Uses official Google nodes directly.

  • n8n manages refresh tokens internally.

Cons:

  • Multi-tenant isolation becomes your responsibility (separate users/projects, permissions/RBAC, operational overhead).

  • Harder to do “one shared workflow for all users” without careful mapping.

Option 2 — Programmatically create/update n8n credentials via the n8n API (good if you need automation at scale)

Pattern: Your app performs OAuth (Google login on your site), stores the tokens, then uses the n8n REST API to create a credential entity per user and wire it to the workflow.

Notes:

  • n8n supports API authentication and API keys (plan/features vary).

  • There are community discussions and workflow templates around automating Google OAuth credential creation inside n8n.

Pros:

  • You can keep one “template workflow” and stamp out per-user credentials + mappings.

  • Fully automatic onboarding.

Cons:

  • You’re now building a credential provisioning system (and must secure it).

  • Still not “runtime swap” inside a single node execution; you’re swapping by changing which credential the workflow/node references (or by executing per-tenant copies).

Option 3 — Don’t use n8n credentials for user OAuth at all (most SaaS-friendly)

Pattern: Your site handles OAuth, stores refresh tokens (e.g., Supabase), and n8n calls your backend “token broker” to get an access token at runtime, then uses HTTP Request nodes to call Google APIs.

Flow:

  1. User logs in with Google on your site (you request offline access, store refresh token securely).

  2. n8n workflow receives a user/tenant id.

  3. n8n calls your backend: “give me an access token for user X” (backend uses refresh token to mint access token).

  4. n8n uses that access token as a Bearer token in HTTP requests to Google Drive / Docs.

Pros:

  • True multi-tenant runtime behavior.

  • n8n stays stateless about user OAuth.

  • Easier to rotate keys, revoke, audit, and centralize security controls.

Cons:

  • You won’t use the “nice” Google nodes directly (unless you wrap this into a custom node).

  • You must implement token refresh + secure storage correctly.

This option is usually the cleanest if you’re building a public SaaS.

Which option fits your exact “Supabase + website OAuth + run workflow” vision?

Your description matches Option 3 most naturally.

Because your requirement is: “User authenticates on my site; I store credentials; then n8n runs actions on their Drive.”
That is exactly “external OAuth + token broker + HTTP Request” territory, and it avoids fighting n8n’s static credential resolution.

…and of course it offers (you can follow up if you think there is value):

About your partial node JSON

You’re right: it’s usually not needed unless we’re doing one of these:

  • identify where credential IDs are referenced in the workflow export,

  • show how to parameterize HTTP headers/body for Google API calls,

  • or wire in a “token broker” step cleanly.

If you paste it, I can tell you precisely where the credential binding is happening and which of the 3 architectures your current workflow most closely matches.

If you tell me which Google actions you’re automating (Drive list/download, Docs create/update, Sheets, Gmail, etc.) and whether you’re on n8n Cloud vs self-hosted, I’ll recommend the best option and give you a concrete build blueprint (OAuth scopes, token storage fields, and the exact n8n node chain).