Authentication proves an identity; authorization limits what that identity may do. n8n credentials help store connection secrets, but the workflow, provider account, scopes, sharing, rotation, and execution data determine the real boundary.
Choose the Provider-Supported Pattern
- API key: simple service identity; scope and rotate if provider supports it.
- Bearer/access token: short-lived or static token; protect audience and expiry.
- OAuth 2: delegated access through provider flow; request least scopes and handle refresh/revocation.
- basic/custom auth: only when the API officially requires it and transport is HTTPS.
Never invent OAuth or forward a token issued for one resource to another. Use the n8n credential type or HTTP credential mechanism recommended by current official docs.
Operate Credentials
Inventory owner, provider account, scopes, environment, workflows using it, creation/expiry, rotation procedure, recovery, and revocation. Separate development and production. Restrict who can edit/view workflows that use credentials; n8n plan features and sharing behavior vary.
Keep secret values out of expressions, node names, notes, code, exports, execution output, and screenshots. Rotate immediately if exposed.
Worked Example
A CRM integration needs to read leads and create DRAFT notes. The client creates a dedicated app identity with only those scopes. OAuth redirect/base URLs match the client-owned n8n instance. Production credential is unavailable in the developer lab.
An operator leaves. Their n8n user is removed, but the service credential continues because it is company-owned. A quarterly drill rotates the client secret, updates the credential, verifies a synthetic test, and revokes the previous secret.
Failure Cases to Diagnose
- Personal admin token used: create a service identity with minimal scope.
- Credential shared across clients: isolate tenancy and ownership.
- Secret pasted into Code node: rotate and move to credential store.
- OAuth asks for every scope: request only workflow needs.
- Revoked operator still owns provider app: transfer and audit recovery.
- No rotation test: document and rehearse.
🇵🇰 Pakistan Angle
Do not ask clients to send API keys, wallet credentials, or OTPs over WhatsApp. Use an approved credential-entry session and make the client the owner. Never store bank PINs or OTPs in n8n.
For agencies, document offboarding before launch: who revokes your access, exports workflows, rotates secrets, and takes over billing. A client should not depend on your personal email or phone.
Hands-On Exercise
- Create the credential inventory.
- choose a dedicated least-scope test identity.
- connect without exposing values.
- test forbidden scope and expired/revoked credential.
- perform rotation and offboarding drill.
Completion Rubric
- Identity is provider-supported and least-privilege.
- Dev/prod and clients are isolated.
- Secrets never appear in workflow/log/export.
- Ownership and recovery are organizational.
- Expiry, refresh, rotation, and revocation are tested.
- Authorization failure cannot be bypassed.
Sources
- n8n Docs — Credentials
- n8n Docs — HTTP Request credentials and OAuth options
- OWASP — Secrets Management
Key takeaway: credentials are governed identities: least scope, company ownership, isolated environments, no secret leakage, and tested rotation/revocation.