Possible to do multi-tenant workflows that can reference credentials dynamically?

Questions
17

Multi-Tenant OAuth Solution for n8n - Production-Ready Implementation

Great discussion everyone! I’ve been tackling this exact challenge in production environments and wanted to share three working solutions that solve multi-tenant OAuth credentials in n8n.

TL;DR - The Working Pattern

The key insight is using an external OAuth service + n8n HTTP requests for dynamic credential fetching:

User Frontend → OAuth Service → Third-party APIs
      ↓              ↓              ↓
   n8n Workflows ← Token API ← Secure Storage

Production Solutions (Choose Based on Your Stack)

:fire: Firebase Auth + Firestore (Recommended for GCP users)

Setup time: 2-3 days | Cost: $5-50/month depending on scale

// n8n HTTP Request node:
GET https://your-region-project.cloudfunctions.net/getUserCredentials/{{ $parameter.user_id }}/google
Authorization: Bearer YOUR_API_KEY

// Response:
{
  "access_token": "ya29.a0...",
  "expires_at": "2025-05-25T15:30:00Z"
}

// Use in subsequent nodes:
Authorization: Bearer {{ $node["Get User Token"].json.access_token }}

Why Firebase:

  • Native GCP integration (perfect if you’re already on Google Cloud)
  • Built-in OAuth handling with Cloud Functions
  • Automatic token refresh via scheduled functions
  • Firestore for secure, encrypted token storage
  • Minimal operational overhead

:office: Auth0 + Custom Backend (Enterprise-grade)

Setup time: 1-2 weeks | Cost: $70-200/month

Why Auth0:

  • Enterprise security (SOC2, HIPAA, GDPR)
  • 30+ OAuth providers out-of-the-box
  • Advanced user management and MFA
  • Professional support and SLAs
// Your custom API endpoint for n8n:
GET https://your-backend.com/api/credentials/{{ $parameter.user_id }}/google
Authorization: Bearer YOUR_N8N_API_KEY

// Auto-refreshes tokens, handles all OAuth complexity

:rocket: Supabase (Fast MVP, Open Source)

Setup time: 1 day | Cost: $0-25/month initially

// Direct Supabase REST API call in n8n:
GET https://your-project.supabase.co/rest/v1/user_credentials
Authorization: Bearer SUPABASE_SERVICE_KEY
user_id: eq.{{ $parameter.user_id }}
provider: eq.google

Key Implementation Details

1. OAuth Flow Architecture

// 1. User initiates OAuth from your frontend
https://your-oauth-service.com/auth/connect/google?user_id=user123

// 2. OAuth service handles provider flow, stores encrypted tokens
// 3. n8n fetches fresh tokens via HTTP Request
// 4. Automatic refresh happens in background

2. Security Best Practices

  • Token encryption at rest (use GCP KMS, AWS KMS, or similar)
  • API authentication between n8n and your OAuth service
  • User isolation - each user only accesses their own tokens
  • Audit logging for compliance

3. n8n Workflow Pattern

// Standard pattern in every multi-user workflow:

1. [Get User Credentials] HTTP Request node
   ↓
2. [Check Token Valid] IF node 
   ↓
3. [Use API with Token] Your actual API calls
   ↓
4. [Handle Results] Continue workflow

4. Error Handling

// In your n8n workflows:
if (!$node["Get User Token"].json.access_token) {
  const oauthUrl = $node["Get User Token"].json.oauth_url;
  throw new Error(`User needs to authorize: ${oauthUrl}`);
}

Real-World Usage Examples

Gmail Automation per User

// 1. Get user's Gmail token
HTTP Request: GET /credentials/user123/google

// 2. Fetch user's emails  
HTTP Request: GET https://gmail.googleapis.com/gmail/v1/users/me/messages
Authorization: Bearer {{ $node["Get Token"].json.access_token }}

// 3. Process emails specific to this user
// 4. Trigger user-specific actions

Multi-Provider Workflows

// Same user, multiple providers:
// Get Google token for Drive access
// Get Microsoft token for Teams notifications  
// Get Slack token for messaging
// All dynamically resolved per user

Why This Approach Works

  1. Scales infinitely - Each user has isolated credentials
  2. Provider agnostic - Works with any OAuth provider
  3. Automatic refresh - No manual token management
  4. n8n native - Uses standard HTTP Request nodes
  5. Security compliant - Enterprise-grade encryption and isolation

Business Impact

This moves n8n from “internal automation tool” to “customer-facing platform.” You can now build:

  • SaaS products where customers automate their own accounts
  • White-label automation platforms
  • Multi-tenant workflow solutions
  • Customer self-service automation

@jaredshelly @JazzyJohn @everyone - This addresses the core multi-tenant credential challenge you’ve been discussing. I’m happy to share more implementation details or help with specific provider integrations.

Has anyone else implemented similar patterns? What challenges did you face?

Update: I’m working on a comprehensive blog post with full code examples for all three solutions. Will share when complete!

6 Likes