Issue with OAuth Redirect URL being locked for self-hosted n8n

Questions
1

Summary of the Problem

I am running a self-hosted n8n instance (Docker + reverse proxy) and using OAuth2 integrations for both Google Sheets and Charles Schwab.

The issue is that n8n locks the OAuth Redirect URL inside credentials once it is generated, making it impossible to update when the base URL changes (for example, switching between localhost, a custom local domain, or HTTPS).

This causes serious problems when working with OAuth providers that have strict redirect URL validation, especially Schwab.

Why this is a problem

1. Different OAuth providers have different requirements

Provider Behavior
Google Allows HTTP, localhost, and multiple redirect URIs
Schwab Requires HTTPS and exact string match on redirect URI

To support both providers locally, I need to switch between:

  • http://localhost:5678/... (Google)

  • https://localhost/... or https://n8n.localhost/... (Schwab)

However, once a credential is created, n8n hard-codes the redirect URL based on environment variables at creation time and does not allow editing it later.

2. Changing the redirect URL requires recreating credentials

Because the redirect URL is locked:

  • Any base URL change forces credential deletion

  • OAuth providers (especially Schwab) often require manual approval (up to several business days) for redirect changes

  • This makes local development extremely slow and fragile

3. This breaks valid workflows

Real-world consequences:

  • OAuth providers reject callbacks due to mismatched redirect URLs

  • Credentials appear “Unauthorized” even though the OAuth app is valid

  • Secure cookies fail if HTTPS cert trust changes

None of these issues are user misconfiguration — they stem from the redirect URL being immutable inside n8n.

What I’m requesting from n8n

Allow OAuth Redirect URLs to be editable

Specifically, one of the following solutions:

Option A (Best)

Allow the OAuth Redirect URL field to be manually editable in credentials.

Option B

Allow multiple redirect URLs to be defined per credential.

Option C (Minimum)

Allow the redirect URL to be regenerated when:

  • N8N_EDITOR_BASE_URL

  • N8N_HOST

  • N8N_PROTOCOL
    change — without requiring credential deletion.

Why this matters

  • Self-hosted n8n is a core offering

  • OAuth providers increasingly enforce HTTPS + strict validation

  • Local development requires flexibility

  • Locking redirect URLs makes legitimate setups fail unpredictably

This is not specific to Google or Schwab — it affects any OAuth2 provider with strict redirect rules.

Current workaround (not ideal)

The only workaround today is:

  • Running multiple local domains

  • Using reverse proxies

  • Re-registering OAuth apps repeatedly

  • Waiting days for provider approvals

This is fragile and unnecessary if redirect URLs were editable.

Environment (for reference)

  • n8n: self-hosted (Docker)

  • Reverse proxy: Caddy

  • Providers affected: Google Sheets OAuth2, Charles Schwab OAuth2

  • OS: Windows

  • Browser: Chrome

Closing

This is not a configuration error but a product limitation that significantly impacts OAuth workflows in self-hosted environments.

I’d appreciate guidance on whether:

  • This is expected behavior

  • There’s a roadmap item to make redirect URLs editable

  • A supported workaround exists

Thank you.

2

I, too, self-host, but do not yet do what you do. I was interested in the solution, as I have to tunnel from laptop to server to do anything with n8n creds, due as well to the relative ‘localhost’ (justified) situation.

But since you are touching on such specifics, and nobody has answered, I ran it (as-is) past ChatGPT, hoping that something in it’s response might lead to a solution for you:

What you’re running into is real and (today) is largely expected behavior in n8n: the OAuth callback/redirect URL shown in a credential is derived from instance URL settings and is not meant to be edited per-credential in the UI. That design becomes painful the moment you have one provider that tolerates flexible redirects (Google) and another that demands HTTPS + exact string match (Schwab).

What n8n is doing (and why it “locks”)

n8n computes its public-facing URLs from environment variables and uses those URLs when it needs to tell an external service “call me back here.”

Key points from n8n’s own docs:

  • By default, n8n composes URLs from N8N_PROTOCOL, N8N_HOST, and N8N_PORT. (n8n Docs)

  • If you’re behind a reverse proxy, n8n explicitly recommends setting WEBHOOK_URL so it can “display it in the editor UI and register the correct webhook URLs with external services.” (n8n Docs)

  • N8N_EDITOR_BASE_URL is the public editor URL (also used for some auth-related redirects like SAML). (n8n Docs)

For OAuth credentials specifically, community guidance has long been: the OAuth redirect URL is based on WEBHOOK_URL if set. (n8n Community)

So the behavior you’re seeing is consistent: once a credential exists, the UI shows a redirect URL derived from the instance base URL at that time, and n8n does not provide a supported “edit this one field” path.

The “supported workaround” (what n8n expects you to do)

The supported path is essentially:

  1. Decide the canonical public URL for your n8n instance (scheme + host + any path prefix).

  2. Set the relevant environment variables (WEBHOOK_URL, and often N8N_EDITOR_BASE_URL, plus proxy settings).

  3. Restart n8n.

  4. Recreate OAuth credentials if they were created under a different base URL.

That’s consistent with n8n’s reverse-proxy guidance around WEBHOOK_URL. (n8n Docs)

This is exactly what breaks down with providers like Schwab that require manual redirect approval.

The pragmatic fix for your Google + Schwab split: stop switching URLs

The cleanest solution is to make one stable HTTPS hostname that works for both providers, and never change it again.

A good pattern for self-hosted LAN dev

  • Pick a stable name like: https://n8n.local or https://n8n.lan

  • Make it resolve to your n8n reverse proxy IP (e.g., via:

    • your internal DNS, or

    • a Windows hosts entry)

  • Terminate TLS at Caddy and trust the CA on your workstation (Caddy “internal” CA or mkcert workflow)

Then configure n8n so it always believes its public URL is that stable HTTPS name:

  • WEBHOOK_URL=https://n8n.local/ (most important behind proxies)

  • N8N_EDITOR_BASE_URL=https://n8n.local/ (good when editor/public differ; otherwise harmless)

  • N8N_PROXY_HOPS=1 (per n8n reverse proxy doc)

Why this solves your specific provider mismatch:

  • Schwab: gets a strict, HTTPS, stable redirect URI forever.

  • Google: you can register that same HTTPS redirect URI as an allowed redirect; you don’t need http://localhost if you have a trusted local HTTPS name.

In other words: instead of trying to make n8n “toggle” redirect identities, give it one identity that satisfies the strictest provider.

If you truly need multiple base URLs (two identities)

If your workflow genuinely requires different public identities (not just “it’s convenient”), the only robust approach is isolation:

  • Run two n8n instances (two docker-compose stacks):

    • different WEBHOOK_URL / hostname

    • separate database (or at least separate encryption key + credential store)

    • separate OAuth apps at providers

That way you’re not constantly invalidating previously-approved redirect URIs.

Is there a roadmap item / feature request?

There’s clear evidence the community has been asking for exactly what you’re requesting (custom/editable redirect URLs) for a while:

  • A feature request explicitly proposing a custom redirect URL field in OAuth2 credentials exists (and even included a suggested implementation).

  • A GitHub issue (Apr 25, 2025) reports the same core problem (“field … cannot be modified”) and is tagged as having an internal tracking item (“created in Linear for internal review”), but it does not indicate a public ETA or committed solution.

So: it’s not “just you,” and it’s on n8n’s radar—but I can’t honestly tell you it’s scheduled for a specific release based on what’s publicly visible in those threads.

A tight way to frame this to n8n (so it lands)

Your write-up is already strong. If you want it to hit hardest with product/engineering, the core ask that tends to resonate is:

  • Decouple “instance base URL” from “OAuth redirect URL” per-credential
    (or allow overriding it), because OAuth providers enforce different redirect constraints.

That aligns perfectly with the existing feature request.

[And of course, the obligatory:] If you tell me what URL you want to standardize on (e.g., https://n8n.local vs https://n8n.yourDomain.lan) and whether your n8n is accessed from only your workstation or multiple LAN clients, I can give you a concrete Caddy + env-var configuration that keeps OAuth stable and stops the credential churn.