What identity integration involves in n8n
SSO and LDAP in n8n are licensed features, available on the Business and Enterprise plans according to n8n's pricing page. The Business plan is currently listed as self-hosted only, so a team running n8n in Cloud would need Starter or Pro for hosting purposes, and the cloud plans do not include these features. Before you plan around identity, confirm the current plan terms with n8n directly and check that the edition you intend to run exposes SAML or LDAP settings in its user management area.
Identity integration becomes worth the effort when more than a few people build workflows, when people join and leave teams often, when auditors expect you to show who changed a production workflow, or when shared credentials can write to finance, customer or infrastructure systems. Under those conditions, individual local accounts stop scaling. You need a source of truth for who is active, a rule for what happens when someone leaves, and a record that ties each change to a named person.
Login is the easy part. The harder work is deciding how identity provider groups map to n8n instance roles, how projects separate one team's workflows and credentials from another's, and who can see credential names, values or the nodes that use them. Those choices should be written down and tested with real test accounts before go-live. Confirm with your installed version which SSO settings, provisioning options and role mappings it exposes, because they change between releases.
Identity also touches the encryption key. In queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can decrypt stored credentials. Rotating or changing the key without a plan can break credential access across the whole fleet, so the identity design and the key handling plan should be reviewed together.
Components and settings involved
Identity integration in n8n touches a small set of settings, roles and stored objects. Each one decides who can sign in, what they can see, and which credentials they can use, so review them together before enabling single sign-on.
SAML login settings
SAML single sign-on is available on the Business and Enterprise plans, and n8n publishes step-by-step guides for Okta Workforce Identity and Azure AD. Confirm the plan that covers your instance before you start, and record the identity provider metadata, attribute mapping and the login URLs your team will use during testing.
LDAP login settings
LDAP login is also included only on the Business and Enterprise plans. Check which directory fields n8n reads for the user's email and display name, and confirm how group membership will or will not affect the role a user receives. Test with a service account that has read-only directory access.
Instance user roles
Instance roles control what a person can do across the whole n8n instance, such as managing users and settings. Map your identity provider groups to these roles deliberately, and keep the number of owners and administrators small so that privilege does not spread through default provisioning.
Projects and project membership
Projects group workflows and credentials, and project membership decides which people can open and edit what is inside. Plan project boundaries before go-live, since moving people between projects later changes access for every resource they reach.
Credentials and their sharing
Credentials hold the secrets that workflows use to call external systems, and sharing a credential grants use of it without revealing the secret. Review which projects can use each credential, and treat sharing as an access decision rather than a convenience setting.
Instance encryption key
The encryption key protects stored credentials in the database, so losing it makes them unreadable and exposing it exposes them. Back it up separately from the database and restrict who can see it. In queue mode, the main instance's encryption key must also be shared with every worker and webhook processor so they can read credentials.
Identity provider configuration
The identity provider holds the users, groups and application assignments that n8n trusts. Confirm which tenant or directory, which groups and which user assignments feed n8n, and who owns changes to them, because n8n's access decisions follow what the provider sends at sign-in.
Decisions before configuration
Compares the choices to settle before configuring n8n SSO, with when each option fits and what it costs to run.
| Decision | Option | When it fits | Operational cost |
|---|---|---|---|
| Identity source | SAML | Your identity provider holds users and groups and you want browser sign-in. n8n documents Okta and Azure AD setups. | Attribute and group mappings must track identity provider changes. Confirm supported attributes in n8n's SAML documentation. |
| Identity source | LDAP | Your directory is the system of record and should govern sign-in. Confirm the directory type and setup steps with n8n first. | Directory group and filter maintenance needs a named owner. Confirm how removed directory accounts are deactivated in n8n. |
| Plan tier | Business or Enterprise | SSO and LDAP are included only on these plans, per n8n's pricing page. Confirm the plan covers your self-hosted needs. | Business is listed at 667 euros per month, billed annually (n8n pricing page). Enterprise pricing is custom. |
| Role source | Roles from the identity provider | Your identity provider already governs access and you want one place to change it. | Confirm when role changes take effect. Test a removed user's access before go-live. |
| Role source | Roles managed in n8n | Small teams or a few administrators who change roles directly in n8n. | Roles drift from the identity provider unless someone reviews both. Each joiner or leaver needs two updates. |
| Project mapping | One project per team | Teams own their workflows and credentials and need clear boundaries. | Project membership must follow team changes. Assign an owner who reviews the mapping at each reorganization. |
| Credentials | Shared per project | Workflows run on accounts a team uses together, such as a shared mailbox or service account. | Confirm what removing a member revokes. Rotate shared secrets when someone with access leaves. |
| Credentials | Personal | Each person connects their own accounts and workflows must follow their identity. | Workflows can break when the owner leaves. Plan ownership transfer and credential re-entry. |
| Recovery | Keep a local owner account | You need a way in if the identity provider or directory is unavailable during an incident. | The account needs a strong stored password, restricted use and periodic login tests. Confirm recovery steps for your setup. |
Build sequence
The sequence moves from confirming licensing and version to a tested SAML or LDAP login, then role mapping, user migration and credential lockdown, with a check closing each step.
Confirm plan, license and version
Confirm with your n8n account contact that the target plan includes SSO and LDAP, since the pricing page lists them only on Business and Enterprise. Confirm the exact version you will run in production and whether your deployment is single-main or multi-main. Check: a written note in the change record naming the plan, the version and the protocol (SAML or LDAP) you will configure.
Prepare the identity provider
Your identity team creates the n8n application (for SAML) or a read-only directory bind account (for LDAP), then defines the groups that will map to n8n roles and the attributes n8n needs, such as email and name. Keep the bind account's rights to the minimum needed to search users and groups. Check: a directory query run with the bind account returns the test users and their group memberships.
Set up a test instance
Build a non-production n8n instance on the same version, with its own database and a copy of your encryption key kept separate from production. Do not point it at production credentials. Use the vendor guide for your identity provider as the reference for URLs, certificates and attribute names. Check: the test instance starts, the owner account can sign in, and the SSO settings page saves without errors.
Configure SAML or LDAP from the vendor guide
Follow the n8n SAML guide for your provider (the guide covers Okta Workforce Identity and Azure AD) or the LDAP settings for your directory. Map the attributes and groups from the previous step. Confirm the assertion or directory fields with your identity team before enabling login for everyone. Check: a test login with a non-owner account succeeds and the user lands with the expected name and email.
Define the role and project model
Write down which identity groups map to which n8n global roles and which projects each team can access, and decide who may create credentials and who may only use them. Apply the mapping in the test instance first. Check: a group-to-role test with one account per group confirms each account sees only the projects and actions its role allows.
Migrate existing users and owners
Match existing local accounts to identity provider users by email, reassign workflow and project ownership to people who will remain, and decide how to handle the instance owner account, which should stay as a break-glass login. Plan this on a copy first and record each change. Check: every active workflow has a current owner who signs in through SSO, and the break-glass account is documented and tested.
Lock down credential sharing and confirm removals
Restrict credential sharing to the projects that need it, remove shares left over from individual users, and confirm that only the intended roles can view or edit stored secrets. Then disable a test user in the identity provider and confirm that the n8n session ends and login fails on the next attempt. Changes to the encryption key or the database are separate work and must be planned on their own. Check: the removed test user loses access, and the credential sharing review is signed off.
Effort and cost drivers
This table lists what changes the effort of an n8n SSO and identity project, how to keep each driver small, and where the cost comes from, so you can compare scopes and quotes.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Number of identity sources and providers | Each SAML or LDAP source needs its own attribute mapping, test accounts, failure handling and sign-in testing. Several directories that must agree on one user record add reconciliation work. | Confirm one authoritative identity source for n8n users. Retire or exclude secondary directories from the scope before the build starts. |
| Depth of group-to-role mapping | Every identity group that maps to an n8n role or project adds rules to define, review and test. Nested groups and exceptions multiply the test cases. | Agree a small role model first, usually a few instance roles plus project membership. Map only the groups that carry a real access decision. |
| Number of projects and shared credentials to review | Each project and shared credential needs an owner, a membership list and a check that the right users can see and use it. Large, untidy inventories take longer to review than the SSO configuration itself. | Reduce the number of projects before go-live. Keep a sanctioned credential inventory with a named owner for each credential, and remove credentials nobody uses. |
| Queue mode workers and multiple environments | In queue mode, the encryption key must be shared with all worker and webhook processor nodes. Multiple environments, such as development, test and production, each need consistent SSO settings and matching access rules, so every change is repeated. | Keep the number of environments to what the team truly needs. Manage SSO settings and the key distribution through the same change process for every node and environment. |
| Existing user migration | Accounts that already exist locally must be matched to identity provider accounts without duplicates or lost ownership of workflows and credentials. Mismatched email addresses or usernames are the usual source of rework. | Export the current user list and agree matching rules before the build. Decide in advance who keeps ownership of workflows that belong to departed or reassigned staff. |
| Compliance evidence requirements | Assessors often ask for proof of who has access, how access was approved and how changes were logged. Producing that evidence for SSO, roles and credentials adds documentation and test-run effort. | Ask the assessor or compliance lead which evidence they need, then define that list at the start. Keep access reviews and change records in one place to avoid rebuilding them later. |
| Licence tier and plan features | SSO and LDAP are included only in the Business and Enterprise plans, so the chosen tier decides whether the feature is available at all. Pricing is set by n8n and should be confirmed on its pricing page at the time of purchase. | Confirm the required feature list with n8n before choosing a tier. Keep the feature requirement limited to the controls you have agreed with your assessor. |
| Identity team time | The identity team defines the claims, group attributes, test accounts, provider application settings and sign-in approvals. Their availability often sets the schedule more than the n8n work does. | Name an identity owner and agree review windows at the start. Provide a complete group list and attribute description before the build begins. |
| n8n configuration and testing | Configuration covers SSO settings, role and project rules, key distribution and access tests across environments. Testing time grows with each role, project and environment that has to be checked. | Test a representative set of roles and projects rather than every combination. Document the expected result for each test so retesting after changes is quick. |
Differences by deployment model
A single main instance runs the editor, triggers, webhooks and executions in one process, so identity has one home. This is the simplest model to verify.
- One identity configuration: SAML or LDAP settings are entered once on the main instance and apply to every user session.
- Encryption key: the key stays with the one instance, so any restore must bring back the same key that protects stored credentials.
- Plan requirement: SSO and LDAP require the Business or Enterprise plan. Business is currently self-hosted only.
- Recovery test: confirm that sign-in still works after a restore to a rebuilt host, with the same identity settings and roles.
Queue mode separates the main instance, which handles triggers and webhooks, from workers that run executions. Identity settings still belong to the main instance, but workers and webhook processors also need the encryption key to read credentials from the database.
- Shared key: every worker and webhook processor must receive the same encryption key as the main instance, or stored credentials will fail to decrypt.
- Login path: confirm which process serves the editor and SSO callback routes in your version, and route those paths only to the main instance.
- Key rotation: change the key on all nodes in one planned window and restart each node.
- Design details: Redis, worker concurrency and sizing are covered in the queue mode and worker scaling topic.
Multi-main runs several main instances for high availability. It is restricted to Enterprise self-hosted deployments, and identity becomes a consistency problem across nodes.
- Identical identity settings: confirm that every main instance carries the same SAML or LDAP configuration, so a user receives the same role and access whichever node handles the login.
- Shared key: all main instances must use the same encryption key.
- Callback URLs: SAML metadata and assertion consumer URLs should point to the load balancer address that users reach, so the identity provider always returns to a healthy node.
- Failover test: sign in through each node and again after a simulated node failure. Also confirm that the Enterprise license covers your planned node count.
The Community edition is free and self-hosted, but SSO and LDAP are included only in the Business and Enterprise plans. Teams without a license manage users through local n8n accounts.
- No SAML or LDAP: federated sign-in is unavailable, so plan local account creation, role assignment and offboarding by hand.
- No multi-main: multi-main is unavailable on Community, so identity consistency across several main instances does not apply.
- Enterprise files: files with .ee in their name require a valid Enterprise license. Do not deploy them on a Community setup.
- Upgrade path: before licensing later, confirm how identity settings, users and roles carry over to the licensed configuration.
Access control and secrets handling
Single sign-on changes who can sign in, but it does not decide who can see or use the credentials n8n stores. These controls cover the identity-specific decisions to make before users and workflows go live.
Limit credential creation and sharing
Decide which n8n roles can create, view, edit and share credentials, and who can share them into projects. Shared credentials let project members run workflows against external systems without seeing the secret, so confirm that viewing and using are separate permissions in your n8n version. Test the roles with a non-admin account before rollout.
Keep a recovery owner outside the IdP
Keep at least one local owner account that does not depend on SAML or LDAP, with its password held in your break-glass store. If the identity provider is misconfigured or unavailable, this account is the only way back into the instance. Confirm how your version handles local login alongside single sign-on before you enforce it.
Protect the encryption key
n8n encrypts stored credentials with a key from the main instance, and queue mode workers need that same key to read credentials. Limit who can read the key, deliver it to workers through your secrets manager, and rotate it only with a planned re-encryption. Record every host that holds a copy.
Deprovision users and revoke sessions
When someone leaves or changes role, disable the user in the identity provider, remove them from n8n projects, and end active sessions rather than waiting for them to expire. Confirm how SSO-provisioned accounts are deactivated in your version, and test the offboarding steps on a staging instance first.
Protect the LDAP bind account
The bind account lets n8n query the directory, so give it read-only access limited to the users and groups n8n needs. Store its password in a secrets manager, rotate it on a schedule, and use LDAPS so credentials are not sent in clear text. Alert on failed binds, which often signal a stale or abused password.
Log administrative changes
Record changes to users, roles, projects, credentials and SSO settings, and send those records to a log store that administrators cannot edit. Confirm which events your n8n plan exposes through log streaming and which need the instance logs, then test that a role change appears in the destination. For transport and code execution controls, see the n8n security hardening topic.
Verification and failure testing
Test the access rules before go-live and again after every identity change, because a mapping that looks correct in the console can still grant the wrong access. Sign in once for each role and group mapping in your identity provider. Confirm that a user with no group mapping gets no access to the instance. Have a member of one project try to open a credential shared only with another project, and confirm it is refused. Remove a test user from the directory and confirm that sign-in and existing sessions end within the time your policy allows.
Recovery owner path. Confirm that a named local owner account can still sign in when SAML or LDAP is unavailable. Record who holds that account's credentials and where they are stored. In queue mode, also run a credential-using workflow through a worker after any change to identity settings, encryption keys or credential sharing, because workers must read the same stored credentials as the main instance. Keep the result with the change record.
Test the three failures most likely to lock out users. First, take the identity provider or directory offline in staging and confirm what happens to new sign-ins, active sessions and the recovery owner path. Second, load an outdated SAML certificate or metadata file after a simulated rotation, and check that sign-in fails in a way your support team can recognize and that your rollback steps restore access. Third, let the LDAP bind account's password expire in staging and confirm that sign-in and directory sync fail visibly and that someone is alerted. Confirm the exact behavior with the n8n version you run.
The handover should record three things. The mapping tables link each identity provider group to an n8n role and project. The test evidence holds dated results for each test above, with logs or screenshots kept with the change record. The owner register names who maintains each identity setting, including the SAML certificate and metadata, the LDAP bind account, group mappings and the recovery owner. Ask for these three items in the written scope so they are delivered and tested before handover.
Common questions about n8n identity integration
Does n8n SSO require the Business or Enterprise plan?
Yes. According to n8n's pricing page, SSO and LDAP are included only in the Business and Enterprise plans, and the SAML single sign-on setup is documented for those plans. The Business plan is currently self-hosted only, so it fits teams running n8n on their own servers. Enterprise is priced on request for self-hosted or cloud use. Check the current plan table before you budget, because plan contents can change.
Are Okta and Azure AD the only supported identity providers for n8n?
They are the two providers with step-by-step guides in n8n's SAML documentation, which covers Okta Workforce Identity and Azure AD. Other SAML 2.0 providers may work, but you should confirm support with n8n before you commit to one. Check the SAML section for your version to confirm required attribute mappings and any limits. Test the configuration in a non-production instance with your identity team before you plan a production cutover.
How long does n8n SSO integration take, and what drives the timeline?
Duration depends on your environment, so the timeline should come from a written scope rather than a general estimate. The main drivers are your identity provider, whether you use SAML, LDAP or both, and how many groups must map to n8n roles. The number of existing users and projects to reconcile matters too, as does whether n8n already runs in queue mode. Change control, test sign-ins for each role, and the production approval process also add time.
What does the n8n SSO project need from our identity team?
Your identity team owns the provider side of the integration. They create the SAML application or LDAP bind account, configure the redirect and entity details n8n provides, and define which attributes or groups carry role information. They also need admin access for test sign-ins and an agreed change window for production. Expect them to review how users are deprovisioned and to approve role mappings. Confirm these steps against the setup guide for your provider and n8n version.
Can our own team set up n8n SSO without a partner?
Yes, if your team has administrators comfortable with both n8n and the identity provider, since the setup guides are public. The harder parts are usually role mapping, testing every user type, and documenting a rollback if sign-in fails. Test in a staging instance with a copy of your configuration first. A partner is worth considering when the team lacks time or experience with SAML or LDAP troubleshooting, or when SSO is part of a wider queue mode or security rollout. Ask any partner for a fixed-scope written proposal.
How does n8n control who can use shared credentials?
Access is controlled through user roles and project access, which determine who can see and use credentials shared within a project. Credentials are stored encrypted, and in queue mode the main instance's encryption key must be shared with worker and webhook processes so they can read them. That makes key handling part of the access design. Confirm the exact permissions for each role in the documentation for your version, and test with a non-admin account before go-live.
How DeployOpen scopes and hands over identity work
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and n8n SSO and identity integration follows the same fixed-scope approach. We agree the identity design, the configuration and the acceptance tests in writing before build work starts.
How we scope
- We confirm which n8n edition and license your deployment uses, since SAML and LDAP require the Business or Enterprise plan.
- We record your identity provider, directory, group structure and the SAML or LDAP attributes that map to n8n roles.
- The written scope lists role mappings, project access rules, credential sharing policy and the users and test cases in the acceptance plan.
How we build
- We configure SAML single sign-on against your identity provider, following the vendor setup steps for your chosen provider.
- We set up LDAP sync where your directory is the source of truth, and test deprovisioning of users who leave.
- We test each role and project boundary with named test accounts, and confirm shared credentials are visible only to the intended users.
How we hand over
- We deliver a runbook covering the SSO configuration, role mapping table, certificate and metadata renewal dates, and owners.
- We document the access model for projects and credentials so your administrators can review who has access and why.
- We walk your administrators through adding users, changing group mappings and rotating identity provider certificates.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We retest SSO and role mappings after each n8n upgrade, since release changes can affect sign-in and permission behavior.
- Support scope, response expectations and reviews are set out in the written agreement before the retainer starts.
