n8n Login Failures: What to Check Before SSO or LDAP
When n8n login suddenly fails on a self-hosted instance, the fix is rarely SSO or LDAP. This guide covers the causes to check first.
Checked against the cited sources on .
Why n8n Login Breaks on a Self-Hosted Instance: Three Everyday Causes
When n8n login suddenly fails for a whole team on a self-hosted instance, the instinct is often to reach for a bigger fix: single sign-on, LDAP, or some other identity layer. In most cases that's the wrong first move. n8n login failures on a self-hosted instance usually trace back to three mundane configuration issues: a secure-cookie and HTTPS mismatch, a misconfigured reverse proxy, or a user-management setup error.
Each cause has its own signal and its own fix, summarized below before we work through them in detail.
| Cause | Example signal | Likely fix |
|---|---|---|
| Secure-cookie / HTTPS mismatch | Login page reloads or rejects valid credentials when reached over HTTP | Serve n8n over real HTTPS with a matching N8N_PROTOCOL and N8N_WEBHOOK_URL |
| Reverse-proxy misconfiguration | Forwarded-header errors, repeated logouts, or a broken interface | Set N8N_PROXY_HOPS and make sure the proxy forwards the required headers |
| User-management setup error | Invites or password resets never arrive, or a provisioned owner can't log in | Configure SMTP and supply a bcrypt-hashed owner password |
Sources: Security | Deploy | n8n Docs, Configure webhook URLs with reverse proxy | Deploy | n8n Docs, Constantly logged out after less than a minute - Questions - n8n Community, Set up SSL | Deploy | n8n Docs, User management | Deploy | n8n Docs, User management and 2FA | Deploy | n8n Docs
Cause 1: Secure-Cookie / HTTPS Mismatch
By default, n8n marks its login cookie as HTTPS-only, a setting documented in n8n's own environment-variable reference as N8N_SECURE_COOKIE. That means reaching the instance over plain HTTP, or over an HTTPS address that doesn't match what n8n believes it is running on, can stop the login cookie from being set at all, so the login screen appears to reject valid credentials.
This is also the fastest thing to rule out, and the one we'd check first on any login report, since it rarely needs a deep proxy investigation. Writing about this exact error in a Coolify and Docker deployment, one independent IT specialist pushed back against disabling the secure-cookie setting as the fix:
One self-hosted user working with Nginx Proxy Manager hit exactly this error and worked around it by disabling the secure cookie, only to discover the real problem was the reverse proxy not routing their subdomain correctly in the first place. Disabling N8N_SECURE_COOKIE can mask a routing problem rather than fix it, and that problem tends to resurface.
Sources: Security | Deploy | n8n Docs, Solution for the Error: "Your n8n server is configured to use a secure cookie, however, you are visiting this via an insecure URL" - Daniel Lautenbacher, Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari - Questions - n8n Community
Cause 2: Reverse-Proxy Misconfiguration (Webhook URL, Proxy Hops, Headers, CSP, SSE)
If HTTPS and cookies check out, look next at the reverse proxy sitting in front of n8n. n8n's own SSL documentation recommends terminating TLS at a reverse proxy such as Traefik or a network load balancer rather than passing certificates into n8n directly, and its reverse-proxy guidance calls for setting N8N_PROXY_HOPS to 1 when running behind a single proxy hop.
Get this wrong and the symptoms can look exactly like a login problem even though the proxy is the real cause. In one community report, a user traced repeated, unexplained logouts to a missing forwarded-header validation setting, and setting N8N_PROXY_HOPS to 1 resolved it; the thread dates from 2024 and isn't a documented general mechanism, so treat it as a lead rather than a guarantee.
Two older community threads flag related but distinct symptoms: a reverse proxy that adds its own Content-Security-Policy header can break the n8n interface, since n8n itself sets no CSP, and a proxy not configured for Server-Sent Events can leave the UI stuck on a persistent 'Connection lost' message rather than an outright login failure. Both reports are several years old, from 2024 and 2020 respectively, and are flagged as stale, so we'd treat their specific fixes as a starting point to test, not a settled diagnosis for every setup.
Sources: Configure webhook URLs with reverse proxy | Deploy | n8n Docs, Constantly logged out after less than a minute - Questions - n8n Community, Set up SSL | Deploy | n8n Docs, Cors issue on self hosted with reverse proxy - #2 by netroy - Questions - n8n Community, /!\ Connection lost with http reverse proxy Apache - #2 by jan - Questions - n8n Community
Cause 3: User-Management Setup Errors (SMTP, Owner Provisioning, JWT/2FA)
The third everyday cause sits inside n8n's own user-management setup rather than the network path. n8n's documentation describes SMTP as optional starting with n8n 0.210.1, but still necessary for password resets and invite emails to actually arrive; before that point, the intended flow is to create the instance owner through the in-app signup screen and invite other users afterward.
It's also worth knowing what no longer works: n8n removed support for basic auth and JWT-based authentication in n8n 1.0, and current versions have no supported way to turn the login screen off entirely.
Two more setup details cause real lockouts. If you pre-provision the instance owner through environment variables, the password must be supplied as a bcrypt hash; a plaintext value breaks login outright. n8n also enables two-factor authentication by default through N8N_MFA_ENABLED, and separate JWT session-duration and refresh settings control how often users get logged out and asked to sign in again.
Sources: User management | Deploy | n8n Docs, User management and 2FA | Deploy | n8n Docs
A Practical n8n Login Check Order Before Adding SSO or LDAP
Once you know the three usual suspects, the practical question is what order to check an n8n login issue in. The sequence below follows likelihood and speed, not alphabetical order.
Sources: Security | Deploy | n8n Docs, Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari - Questions - n8n Community, Configure webhook URLs with reverse proxy | Deploy | n8n Docs, Constantly logged out after less than a minute - Questions - n8n Community, Cors issue on self hosted with reverse proxy - #2 by netroy - Questions - n8n Community, User management | Deploy | n8n Docs, User management and 2FA | Deploy | n8n Docs
When to Escalate to SSO or LDAP Instead of Chasing These Basics
SSO and LDAP add a new identity layer on top of the same cookie and proxy plumbing described above; they don't replace it. If a team's login problems are really about HTTPS, proxy headers, or SMTP, adding SSO will not fix them, and the same symptoms tend to resurface in the new flow.
Once you've genuinely ruled out these everyday causes and the real issue is managing many accounts, roles or an external directory across a growing team, that's when the SSO or LDAP conversation is worth having. We think that's the right moment to invest in SSO or LDAP, but it's not a substitute for fixing a broken cookie or proxy setup first.
Sources: Security | Deploy | n8n Docs, Configure webhook URLs with reverse proxy | Deploy | n8n Docs, Set up SSL | Deploy | n8n Docs
