Authentication & RBAC
Relevant source files
The following files were used as context for generating this wiki page:
Authentication and Role-Based Access Control (RBAC) form the security foundation of the n8n ecosystem, ensuring that only authorized users can access the platform and that their actions are restricted based on defined permissions. The system manages user identities, session security, and granular access to resources like workflows, credentials, and projects.
The architecture separates identity management (Authentication) from permission enforcement (RBAC). This ensures that security layers are applied consistently across the Express server, REST API, and internal services.
Sources: packages/cli/src/auth/auth.service.ts, cubic.yaml:52-87
Authentication Architecture
Authentication is handled via a centralized service that manages user login, session persistence, and security headers. The system supports various authentication flows, including standard email/password login and Enterprise-level features such as SSO (SAML/OIDC).
Core Authentication Components
| Component | Description |
|---|---|
| AuthService | Manages user authentication logic, including password verification and session creation. |
| Session Security | Enforces cookie flags like HttpOnly, Secure, and SameSite to prevent XSS and CSRF. |
| MFA Enforcement | Handles Multi-Factor Authentication requirements for user accounts. |
| JWT Validation | Manages token-based authentication for specific API contexts. |
Sources: packages/cli/src/auth/auth.service.ts, cubic.yaml:69-77
Login Flow
The following diagram illustrates the sequence for a standard user authentication request:
The authentication process includes rigorous validation of user-provided credentials against stored hashes before granting session access.
Sources: packages/cli/src/auth/auth.service.ts, cubic.yaml:69-72
Role-Based Access Control (RBAC)
n8n utilizes a tiered RBAC system that operates at both the Global and Project levels. Permissions are checked against the authenticated user's assigned roles before allowing execution of any restricted operation.
Global vs. Project Scopes
The system distinguishes between permissions granted at the instance level and those specific to shared projects:
- Global Scope: Roles like
Owner,Admin, andMemberdefine instance-wide capabilities. - Project Scope: Roles like
project:adminandproject:editordefine access within a specific project's boundaries.
Sources: packages/@n8n/permissions/src/roles/all-roles.ts, packages/testing/playwright/tests/e2e/projects/project-settings.spec.ts:133-155
Permission Checks
Permission enforcement is implemented through a checkAccess utility that evaluates whether a user's role set contains the required permission for a specific resource action.
The authorization layer ensures that even authenticated users cannot access resources belonging to other users or projects unless explicitly shared.
Sources: packages/@n8n/permissions/src/check-access.ts, cubic.yaml:79-87
Project-Based Permissions
Projects provide a mechanism for collaboration where owners and admins can invite members and assign specific project roles.
Project Member Roles
| Role | Description |
|---|---|
| Project Admin | Can manage project settings, add/remove members, and edit all resources. |
| Project Editor | Can view and edit workflows and credentials within the project. |
| Project Viewer | Read-only access to project resources. |
Sources: packages/testing/playwright/tests/e2e/projects/project-settings.spec.ts:133-155, packages/testing/playwright/tests/e2e/projects/projects.spec.ts:25-33
Resource Migration and Access
When a workflow is moved from a "Personal" (Home) project to a "Team" project, its access requirements change. Credentials used by the workflow must also be accessible to the project members; otherwise, nodes may enter an "inaccessible" state for members who do not own the credentials.
Sources: packages/testing/playwright/tests/e2e/projects/projects.spec.ts:40-108
Security Implementation Guidelines
The codebase enforces strict security patterns to prevent common vulnerabilities within the Authentication and RBAC modules:
- Credential Handling: Sensitive information must never be logged or exposed in error messages.
- Input Validation: Controller endpoints must use DTO classes (Zod-based) for runtime validation to prevent injection.
- Decorator Order: Route decorators must be followed by
@Licensed(if applicable) and then Scope decorators (@ProjectScope,@GlobalScope). - Insecure Defaults: TLS certificate validation (
rejectUnauthorized: false) is restricted.
Sources: cubic.yaml:57-67, cubic.yaml:139-158, cubic.yaml:184-189
Summary
The Authentication & RBAC system in n8n provides a multi-layered security approach. It handles identity verification through a centralized AuthService and enforces granular permissions via a scoped RBAC model. By distinguishing between Global and Project levels, the platform supports both individual user privacy and complex team collaboration, while maintaining strict guardrails against session hijacking, unauthorized resource access, and data injection.