How can we dynamically use stored OAuth tokens in n8n to access multiple Gmail inboxes?

Below is an overview of n8n’s current OAuth handling and some considerations for your use case:

---

How n8n Handles OAuth Credentials

n8n is built with a credential system that is designed to store and manage OAuth tokens (client ID, client secret, access token, refresh token) for a single credential instance. Generally, when you set up an OAuth2 credential in n8n (whether using the GitHub-supported “OAuth2 single service” or “OAuth2 generic” methods), you do so once per credential. The OAuth dance (sign in / token refresh) is managed automatically by n8n for that credential instance when you trigger the “Sign in with…” button during configuration.

---

Using Dynamically Stored Tokens

n8n does not natively support pulling in or overriding OAuth tokens dynamically from an external database during workflow execution. In typical setups, the OAuth tokens are stored internally in n8n’s credential storage. This means that for each integration (for example, a Gmail node) you would create a credential entry in n8n where the OAuth tokens reside. As such, n8n expects the tokens to be provided at design-time rather than injected dynamically at runtime based on the end-user.

Options to Consider:

• Custom Nodes or Workflows: One possibility is to write a custom node (or wrapper) that retrieves the tokens from your database and then makes API calls to Gmail using those tokens. This, however, means bypassing n8n’s built-in OAuth management.
• Credential Overwrites via Code: Alternatively, you might consider if there’s a way to programmatically update credentials in n8n’s database prior to workflow execution. This requires custom code and careful handling of token refresh cycles outside of n8n’s built-in processes.

---

OAuth Token Refresh Handling

For credentials configured within n8n, the built-in OAuth mechanism does handle token refresh automatically. This is possible because when you click “Sign in with Google” (or the corresponding button for the service), n8n registers the refresh token and uses it as needed without further user interaction.

However, if you were to try to use stored tokens from an external source on a per-user basis, n8n would not automatically manage the refresh flows for tokens injected externally. In that case, you’d be responsible for ensuring tokens remain valid (or refreshed) prior to workflow execution.

---

Inherent Limitations in n8n

• Designed Credential Model: n8n’s credential system is designed to assume a single set of tokens per credential instance. There is no built-in multi-tenancy support for dynamic credential selection based on a runtime context.
• Security and Storage: Since n8n treats credential configuration as a secure, static step, it does not provide a native mechanism to substitute external tokens during execution.
• Token Lifecycle Management: Although token refresh works seamlessly for n8n-managed credentials, relying on external token injection means you’d need a custom solution to consistently track and refresh tokens.

---

Summary

• Dynamic Use of Tokens: Out of the box, n8n cannot dynamically pick up OAuth tokens stored externally for each user. Credentials must be configured within n8n.
• Token Refresh Handling: n8n will manage token refresh for tokens configured via its credential system. If you inject tokens externally, n8n will not refresh them automatically.
• Limitations: The lack of native support for per-user dynamic token injection means you’d need to implement a custom solution (e.g., a custom node or pre-execution credential syncing) if you want to avoid additional user authorization steps within n8n.

---

Given these points, while your overall approach is technically feasible with custom development, n8n’s current design centers around static credential instances rather than dynamic, external OAuth token injection for every user.