Every n8n node that connects to an external service relies on a credential—an encrypted authentication object stored in the database using AES‑256‑CBC encryption with an instance‑unique key. TheICredentialType interface defines the authentication blueprint for each service, supporting 8 authentication schemes: OAuth2, API Key, Basic Auth, Bearer Token, Header Auth, Query Auth, Digest Auth, and SSL Client Certificates. OAuth2 credentials use the @n8n/client-oauth2 package for automatic token refresh; API keys are stored as encrypted password fields; and enterprise deployments can off‑load all secrets to external vaults via $secrets expressions[reference:0][reference:1].

How do you configure OAuth2 credentials for SaaS platforms in n8n?

OAuth2 credentials in n8n extend a base OAuth2 class from the @n8n/client-oauth2 package with service‑specific parameters: Client ID, Client Secret, Authorization URI, Access Token URI, Scopes, and Grant Type. The OAuth2CredentialController manages the full authorization lifecycle—initiating the redirect flow, handling callbacks, and exchanging authorization codes for access tokens with automatic refresh[reference:6].

To configure an OAuth2 credential, navigate to Credentials → New Credential, select the service type (e.g., “Google OAuth2 API” or “Microsoft Azure Monitor OAuth2 API”), enter the Client ID and Client Secret obtained from the service’s developer console, and click “Connect my account”. n8n then presents a consent screen; after approval, it stores the resulting access and refresh tokens encrypted in the database[reference:7]. Properties are defined using theICredentialType interface with service‑ specific extensions—for example, MicrosoftAzureMonitorOAuth2Api credentials extend the base oAuth2Api type and add Tenant ID, Grant Type, and Scope fields[reference:8]. For the callback URL, n8n uses https://<your-n8n-domain>/rest/oauth2-credential/callback which must be registered in the service’s allowed redirect URIs. The client‑side OAuth2 implementation stores token data in memory and auto‑refreshes expired tokens using the refresh token—if no refresh token is returned, users must manually re‑connect credentials. For enterprise deployments with custom OAuth2 providers, configure the Credential OAuth2 endpoints via environment variables documented in the n8n Node Security Hardening guide.

How do you securely store and manage API key credentials in n8n nodes?

API key credentials in n8n are the simplest authentication scheme: generate a key from the service’s dashboard, then enter it in n8n’s credential form. The key is stored as an encrypted password field in n8n’s database using AES‑256‑CBC encryption—the system redacts the value to *** in UI displays and execution logs, preventing accidental exposure[reference:9]. Users should never hardcode keys in Code nodes or workflow descriptions because raw strings in those locations appear in plain text in execution logs[reference:10].

Best practices include: rotating API keys every 90 days, using environment variables in credential fields for automation workflows, and keeping separate keys per n8n instance (production, staging, development)[reference:11]. The credential system allows API keys to be created with the universal button, from the Overview page, or directly when configuring a node that requires credentials[reference:12]. For granular access control, API key credentials can be shared with specific projects using n8n’s role‑based sharing model—owners and project admins can manage credential sharing from the Credentials panel. For organizations using dynamic credential selection at runtime, a Switch node can route traffic to dedicated HTTP Request nodes each configured with a different Header Auth credential per client, keeping all secret API keys securely in the n8n vault without hardcoding[reference:13]. For the complete credential lifecycle management strategy including access control patterns, see the n8n Node Security Hub.

How do you integrate external vaults like HashiCorp Vault and AWS Secrets Manager with n8n?

n8n’s External Secrets feature—available on Enterprise plans—supports integrating with 6 secret providers: 1Password (via Connect Server), AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault (self‑hosted and HCP), and Infisical (deprecated from v2.10.0) . n8n does not support HashiCorp Vault Secrets (the HCP‑only SaaS offering)[reference:14]. From version 2.10.0, multiple vaults per secret provider can be connected; from version 2.13.0, project editors can use external secrets within their projects[reference:15].

To connect, navigate to Settings → External Secrets → Add secrets vault, enter a unique vault name, choose the provider, and enter the provider‑specific credentials (e.g., for AWS: Access Key ID, Secret Access Key, Region, with at minimum secretsmanager:GetSecretValue permission)[reference:16]. After configuration, reference secrets in credential fields using the syntax: {{ $secrets.<vault-name>.<secret-name> }}. n8n resolves secrets at runtime, not when the credential is saved, meaning external secrets are decoupled entirely from n8n’s internal database—ideal for SOC2, ISO 27001, and HIPAA compliance workloads requiring centralized secret rotation without ever touching individual workflow editors[reference:17][reference:18]. A critical caveat: secret names must contain only alphanumeric characters and underscores—no spaces, hyphens, or special characters—and n8n only supports plaintext values, not JSON objects or key‑value pairs[reference:19]. For providers requiring specific Vault name identifiers such as AWS Secrets Manager → awsSecretsManager, HashiCorp Vault → vault, and Infisical → infisical, refer to the official external secrets documentation. For the complete provider‑by‑provider setup walkthroughs and IAM permission requirements, see the n8n Node Security Hub.

How does the AES‑256‑CBC encryption protect n8n credentials, and how do you rotate the encryption key?

When Credentials.setData() receives a plaintext object, it validates the data is an object literal, calls Cipher.encrypt() to encrypt the entire JSON payload using AES‑256‑CBC, and stores the resulting encrypted string in the data column of the credentials table. On retrieval, Credentials.getData() decrypts and returns the original plaintext; if decryption fails, it throws a CredentialDataError[reference:21].

The encryption key lives either in the N8N_ENCRYPTION_KEY environment variable or in the .n8n/config file. If no key is explicitly set, n8n generates one randomly and stores it in .n8n/config— for Docker deployments without a mounted volume for the n8n home directory, this file lives inside the container and is lost on container destruction[reference:22]. Generating a strong key uses openssl rand -hex 32 (32‑byte hex string). The safe rotation procedure follows six steps: (1) back up everything (VPS snapshot + PostgreSQL dump + workflow export); (2) export current credentials with n8n export:credentials --all --output=credentials.json; (3) stop n8n; (4) set the new environmental variable value; (5) restart n8n and re‑import credentials; and (6) verify by testing key integrations like Slack, Stripe, or Postgres[reference:23]. Never change the key without exporting first, and always test after rotation. The key must remain identical across all instances in a queue‑mode cluster (main, workers, webhook instances)[reference:24]. For production security, store the key in a secrets manager and keep .env files out of version control[reference:25].

How do you use environment variables and expressions to inject secrets into credential fields?

n8n supports injecting secrets into credential fields through two runtime‑evaluated expression mechanisms: environment variables ($env:VARIABLE_NAME) for self‑hosted instances, and external vaults ($secrets.vault-name.secret-name) for enterprise deployments. Both are evaluated at credential retrieval time, not at credential creation—meaning secrets never appear in the n8n database, credential exports, or workflow JSON[reference:26].

For self‑hosted users, add the variable to the Docker container (e.g., -e MY_API_KEY=sk-abc123) and reference it in any credential field as $env:MY_API_KEY. For file‑based secrets, use the _FILE suffix convention—when n8n encounters an environment variable named MY_SECRET_FILE containing a file path, it reads the file contents and injects them. Users can also override entire credentials via the CREDENTIALS_OVERWRITE_DATA environment variable using the JSON schema { CREDENTIAL_NAME: { PARAMETER: VALUE }}, though this is not recommended for production because environment variables in n8n are not fully protected from user exposure[reference:27]. For the complete self‑hosted credential hardening blueprint covering N8N_BLOCK_ENV_ACCESS_IN_NODE, NODES_EXCLUDE, and reverse‑proxy TLS termination, see the n8n Node Security Hardening guide.

How does n8n’s credential sharing and role‑based access control (RBAC) manage authentication across projects?

n8n implements a project‑based credential sharing model with two role levels: credential:owner (full control) and credential:user (read/use only). Each credential is owned by exactly one project; it can be shared with additional projects with user‑level access. Personal project credentials are accessible only by their owner unless explicitly shared; team project credentials inherit the project’s RBAC permissions for all members[reference:28].

The permission hierarchy across account types defines different credential visibility and editing rights: Instance Owners and Admins can view, edit, share, and create all credentials; Members can only view and share their own credentials; Project Admins can manage credentials within their projects (view, edit, share); Project Editors can view and edit but not share; and Project Viewers have view‑only access. When used in conjunction with external vaults, enterprise organizations can also define vault scope—global vaults can be shared across the whole n8n instance, while project‑scoped vaults restrict secrets to a single project’s credentials[reference:29][reference:30]. This architecture forms the foundation of the security model covered in the n8n Node Security Hub.