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

Questions
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.