n8n SSO options: SAML, OIDC and LDAP on self-hosted

Community edition n8n has no single sign-on. SAML and LDAP are unlocked by a Business or Enterprise self-hosted licence, OIDC's own setup page lists it under Enterprise, and nothing you put in an environment variable changes that on a free instance. That's the short answer to "does n8n support SSO for self-hosted deployments", and it's the same answer the n8n feature table has given since projects and SSO were split off into paid tiers.

The rest of this page is about what each method looks like once you do have a licence, what a community instance has in its place and the proxy-based workaround that gets you most of the convenience of SSO for the editor without a licence, along with the two or three places where people get stuck.

Which licence unlocks which SSO method

The docs are a little scattered on tiers, so here is what the individual pages say as of September 2026. The SSO environment variable reference states single sign-on is available on self-hosted Business and Enterprise; the SAML setup page says Business and Enterprise; the LDAP page says Business and Enterprise; the OIDC setup page says Enterprise. n8n's pricing page lists "SSO, SAML and LDAP" under Business. If OIDC on a Business licence matters to you, get that in writing from n8n sales before signing, because the docs disagree with each other and I'm not going to guess which one the licence server believes.

The licence itself arrives as an activation key that you paste into Settings > Usage and plan or set through N8N_LICENSE_ACTIVATION_KEY. The instance then contacts n8n's licence server, so an air-gapped Business instance needs a conversation with n8n first.

SAML: metadata, redirect URL and attribute claims

Under Settings > SSO, n8n shows you a Redirect URL (the ACS URL in SAML terms) and an Entity ID; the SAML setup docs have the current screenshots of that screen. Those two values go into the SAML application you create in Okta, Entra ID, Keycloak or whatever your IdP is. In the other direction you give n8n the IdP's metadata, as an XML paste or as a Metadata URL that n8n fetches. The IdP has to map three attributes or logins fail with a user that has no name: email to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, first name to the matching .../claims/firstname URI and last name to .../claims/lastname. Select Test settings before you save; it runs a real login round trip and tells you what came back.

OIDC: discovery endpoint, client ID and secret

OIDC asks for less: the provider's discovery endpoint (the .well-known/openid-configuration URL), a client ID and a client secret. n8n's callback for the IdP side is /rest/sso/oidc/callback on your instance URL. Role provisioning from IdP claims exists from 1.122.2 and in-app rule mapping from 2.19.0, per the OIDC page. An owner or admin account is required to configure it.

LDAP: directory sync and what happens on disable

LDAP lives under Settings > LDAP and needs the instance owner to set up. Users sign in with their directory credentials, n8n creates the matching account on first login and a sync removes access for anyone deleted from the directory. Two rules from the docs worth keeping in mind before you enable it. The owner account can't be converted into an LDAP account, which is your break-glass login by design. And turning LDAP off later converts every LDAP user into an email user on their next login and forces a password reset for each of them, so switching it off on a Friday afternoon generates Monday tickets. If the settings themselves are broken beyond repair, n8n ldap:reset from the CLI clears them.

Managing SSO from environment variables

Set N8N_SSO_MANAGED_BY_ENV=true and the UI configuration is replaced by these:

N8N_SSO_SAML_LOGIN_ENABLED=true
N8N_SSO_SAML_METADATA_URL=https://idp.example.com/metadata.xml
# or N8N_SSO_SAML_METADATA=<xml string>

N8N_SSO_OIDC_LOGIN_ENABLED=true
N8N_SSO_OIDC_DISCOVERY_ENDPOINT=https://idp.example.com/.well-known/openid-configuration
N8N_SSO_OIDC_CLIENT_ID=...
N8N_SSO_OIDC_CLIENT_SECRET=...

N8N_SSO_USER_ROLE_PROVISIONING=disabled

N8N_SSO_USER_ROLE_PROVISIONING accepts disabled, instance_role or instance_and_project_roles, and the SSO environment variables page also lists N8N_SSO_OIDC_PROMPT and N8N_SSO_OIDC_ACR_VALUES for IdPs that need those parameters. Read the warning on the SAML page twice before moving off disabled: once a provisioning mode is on, any access a user was granted inside n8n that the IdP response doesn't also carry is removed at that user's next login. n8n suggests downloading the CSV of current access first. I'd go further and run it against a staging instance with a copy of the production database, because "removed at next login" on a team of forty is a lot of Slack messages.

Env management is also the cleanest kill switch. If a metadata change locks everyone out, flip the *_LOGIN_ENABLED value to false in the compose file, restart and you're back on email and password.

What the community edition has instead

Owner account created on first launch, users invited by email with N8N_EMAIL_MODE=smtp and the N8N_SMTP_* variables or by copying the invite link out of the UI if you'd rather not configure mail (then nobody can reset a password, so do configure it). Two-factor authentication with any TOTP app, on by default and free. Projects with project-level roles once you register the instance with an email address, which costs nothing; the number of projects depends on the plan. API keys per user under Settings > n8n API, with an expiry you choose. That's the whole identity feature set, and for a team of five it's fine. The pain starts at the point where someone leaves the company and you realise n8n isn't in the offboarding checklist because it isn't behind the IdP, which is the real thing SSO buys you.

Identity-aware proxy in front of the editor

The workaround for a community instance is to put an authenticating proxy in front of the editor paths and leave the webhook paths open. Authelia, Authentik, Pomerium and Cloudflare Access all do this, and all of them can enforce your IdP's MFA and group membership before a browser ever reaches n8n's login page. You still log into n8n afterwards, since the proxy can't create an n8n session for you, so it's two logins. What you gain is that a departed employee's IdP account being disabled blocks them at the door regardless of whatever n8n password they still know.

The split matters. Webhook URLs are called by Stripe, GitHub, cron jobs and browsers that have no proxy cookie, so those locations bypass the auth check. Here's the Nginx shape, with auth_request standing in for whichever mechanism your proxy uses:

location /webhook/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location /webhook-waiting/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location /webhook-test/ {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

location / {
    auth_request /authelia/api/verify;
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_buffering off;
}

Add locations for any other public trigger you use, the Form Trigger and the MCP Server Trigger both have their own paths, and keep /webhook-test/ open if external providers ever call the test URL while you're building. The websocket upgrade headers only belong on the editor location; n8n's push backend needs them for the "Connection lost" banner to stay away, and the whole server block with certificates is in the n8n Nginx reverse proxy guide. If the editor is only ever used from the office, a WireGuard tunnel with the editor bound to the tunnel interface is a simpler version of the same idea, and there's a WireGuard VPS template if you don't want to set that up from scratch. The same split works with Caddy's forward_auth and with Cloudflare Access by excluding the webhook paths from the Access application.

One limitation I ran into: the proxy sees every request to /rest/, including the ones the editor makes in the background, so a proxy session that expires while a workflow is open produces a silent failure to save rather than a redirect to log in. Set the proxy session lifetime longer than a working day, or accept the occasional lost edit.

Common mistakes

/rest/oauth2-credential/callback is the redirect URI for OAuth2 credentials that nodes use, Google Sheets, Slack and the rest. It has nothing to do with logging into n8n, and registering it as the login callback in an IdP produces an error that looks like an SSO problem but isn't one. The login callbacks are the SSO ones under /rest/sso/.

Workers in queue mode never serve the editor, so there's no session to share between them and no sticky-session or Redis session store to configure. The one layout where sessions could matter is multi-main, an Enterprise feature that the n8n high availability article covers, and even there the requirement is sticky sessions at the load balancer, not a shared session store. The editor is served by the main process only.

Keep an owner login you can use without the IdP. Test SSO from a second browser while the owner stays logged in with a password in the first, and don't enable provisioning modes until the second browser works. If everything goes wrong anyway, n8n user-management:reset returns the instance to its pre-setup state and removes every user account, after which the first visit shows the owner signup screen again.. workflows and credentials survive it, but it is the nuclear option and you should have a database backup before you press it.

SAML metadata contains a signing certificate with an expiry date, and when the IdP rotates it, logins fail with a signature error until n8n has the new metadata. A Metadata URL instead of a pasted XML blob avoids most of this because n8n re-fetches it. I haven't checked how often the refetch happens, so a calendar reminder a week before the certificate's expiry is still the safer bet.