Auth & RBAC

Relevant source files

The following files were used as context for generating this wiki page:

• packages/cli/test/integration/access-control/resource-access-matrix.test.ts
• packages/frontend/editor-ui/src/features/roles/project/ProjectRoleView.test.ts
• AGENTS.md
• packages/nodes-base/AGENTS.md
• CONTRIBUTING.md

The Authentication and Role-Based Access Control (RBAC) system manages user identities and regulates access to n8n resources based on defined permissions and roles. This system ensures that users only perform actions permitted by their assigned scopes within specific project or global contexts.

Architecture Overview

The RBAC architecture utilizes a scope-based permission model. Roles consist of a collection of scopes that define allowed operations (e.g., read, write, delete) on specific resources like workflows and credentials.

Key Components

Component	Description
User	An identity within the system, such as an Owner or Member.
Project	A container for resources (Workflows, Credentials) that defines a boundary for RBAC.
Role	A named set of scopes assigned to a user within a project or globally.
Scope	A specific permission slug (e.g., workflow:read) representing an allowed action.

Sources: packages/cli/test/integration/access-control/resource-access-matrix.test.ts:25-50, packages/frontend/editor-ui/src/features/roles/project/ProjectRoleView.test.ts:47-80

Permission Flow

This diagram illustrates how the system evaluates access when a user attempts to interact with a resource.

Project Roles and Scopes

Users are linked to projects with specific roles. Roles are either system-defined (e.g., Project Admin) or custom-created to meet specific security requirements.

Role Types

1. System Roles: Pre-defined roles like project:admin, project:editor, and project:viewer.
2. Custom Roles: User-defined roles created by combining specific scope slugs.

Sources: packages/frontend/editor-ui/src/features/roles/project/ProjectRoleView.test.ts:47-80

Resource Access Matrix

The system enforces strict boundaries based on scopes. For example, a "Workflow Read-Only" role prevents modification or execution but allows viewing.

Operation	Required Scope(s)	Role Example: Read-Only	Role Example: All-Ops
GET /workflows	workflow:list	Allowed	Allowed
POST /workflows	workflow:create	Forbidden (400/403)	Allowed
PATCH /workflows/:id	workflow:update	Forbidden (403)	Allowed
DELETE /workflows/:id	workflow:delete	Forbidden (403)	Allowed
POST /workflows/:id/run	workflow:execute	Forbidden (403)	Allowed

Sources: packages/cli/test/integration/access-control/resource-access-matrix.test.ts:110-210

Scope Dependencies and Coupling

Certain permissions are logically coupled. The UI and backend enforce these dependencies to ensure functional consistency.

• Workflow Execution: Checking workflow:execute automatically requires and checks workflow:read.
• Execution Visibility: execution:read follows the state of workflow:read.
• Cleanup: Unchecking workflow:read automatically unchecks dependent scopes like execution:read and execution:delete.

Sources: packages/frontend/editor-ui/src/features/roles/project/ProjectRoleView.test.ts:400-480

Security Boundaries

n8n implements several layers of security to protect sensitive data and system integrity.

Encryption Boundary

The system uses a strict encryption boundary. New code must encrypt and decrypt data only through the Cipher service (cipher.encryptV2() / cipher.decryptV2()). Direct use of raw AES classes outside of packages/core/src/encryption/ is prohibited. Deployment keys are never deleted to prevent data from becoming unreadable; they are only deactivated.

Sources: AGENTS.md:200-220

Resource Isolation

Each project serves as an isolation boundary. A user's role in one project does not grant permissions in another. Operations like transfer or share require specific scopes (e.g., workflow:share) that are distinct from standard CRUD operations.

Sources: packages/cli/test/integration/access-control/resource-access-matrix.test.ts:210-240

Implementation Details

Credential Security in Nodes

In node development, user input is treated as untrusted. Developers must use safety helpers from n8n-workflow to prevent prototype pollution when using untrusted values as computed object keys.

import { setSafeObjectProperty, isSafeObjectProperty } from 'n8n-workflow';

if (isSafeObjectProperty(table) && acc[table] === undefined) {
    setSafeObjectProperty(acc, table, {});
}

Sources: packages/nodes-base/AGENTS.md:120-140

Management of Sensitive Fields

The credential system identifies sensitive fields (e.g., API keys, passwords) and enforces their protection.

• OAuth2 credentials must follow specific naming conventions (including OAuth2 in class names and display names).
• Fields with sensitive names must have typeOptions.password = true enabled.

Sources: packages/@n8n/eslint-plugin-community-nodes/README.md:20-50

Conclusion

The Auth & RBAC system provides a granular, project-based permission model. By enforcing scope-level checks at the API layer and implementing strict encryption and node-level security boundaries, n8n maintains a secure environment for workflow automation while allowing flexible user management.