Public API auth strategies made pluggable
The n8n CLI now supports a chain of authentication strategies for its public API, moving beyond the single hardcoded API key approach. Developers can register custom auth handlers that run in sequence until one applies to a request.
The public API previously handled authentication through a single, hardcoded mechanism. Adding new authentication methods meant modifying existing code and coupling strategies together. This approach becomes unwieldy as authentication requirements grow more complex.
Two new files in the CLI services layer establish an extension point for authentication. An AuthStrategy interface defines the contract: each strategy returns null to abstain and let the next strategy try, false to reject the request immediately, or true on successful authentication. An AuthStrategyRegistry service maintains an ordered list of strategies and evaluates them in sequence, stopping at the first non-null result.
This architecture means teams can add scoped JWT support or other authentication methods without any strategy needing to know about the others. The registry handles the orchestration logic. The first non-null result wins, and if all strategies abstain, the request is treated as unauthenticated.
The change is currently unused in the auth middleware itself—that wiring arrives in a follow-up ticket (IAM-463). Existing API key authentication continues to work unchanged.
View Original GitHub Description
Summary
Adds AuthStrategyRegistry — a pluggable auth strategy chain for the public API.
The public API currently has a single hardcoded auth mechanism (API key). This PR introduces the extension point needed to support additional strategies (e.g. scoped JWTs from the token exchange flow) without any strategy needing to know about the others.
Two new files in packages/cli/src/services/:
auth-strategy.types.ts— AuthStrategy interface. Strategies return boolean | null: null to abstain and pass to the next strategy, false to fail fast, true on success.auth-strategy.registry.ts— @Service() registry. Strategies are registered in order; the first non-null result wins. If all abstain, the request is unauthenticated.
No existing behaviour changes — the registry is wired into the public API auth middleware in the next ticket (IAM-463).
Related Linear tickets, Github issues, and Community forum posts
https://linear.app/n8n/issue/IAM-458/2b1-authstrategyregistry-pluggable-auth-strategy-chain
Review / Merge checklist
- PR title and summary are descriptive. (conventions) <!-- **Remember, the title automatically goes into the changelog. Use `(no-changelog)` otherwise.** -->
- Docs updated or follow-up ticket created.
- Tests included. <!-- A bug is not considered fixed, unless a test is added to prevent it from happening again. A feature is not complete without tests. -->
- PR Labeled with
Backport to Beta,Backport to Stable, orBackport to v1(if the PR is an urgent fix that needs to be backported)