Authentication

Why it's node-based, not a config option

Authentication isn't one setting you flip on for a whole backend — different endpoints often need different rules: a public signup route, a JWT-protected dashboard API, an API-key-gated webhook receiver. Modeling auth as nodes means each endpoint's protection is visible right there on the canvas, not buried in a middleware file you have to open separately to know whether a route is actually guarded.

The Auth node

Place an Auth node in front of any endpoint that needs to check who's calling. Its authType field picks the mechanism:

• • jwt (default) — verify a bearer token.
• • oauth — delegate to a provider, set in authProvider (Google, GitHub…).
• • apikey — check a static key on the request.
• • basic — username/password on the request itself.

The node has two outputs: valid (with the decoded user info) and invalid (a 401 with the reason — missing token, expired, wrong signature). A request that fails the check never reaches the nodes downstream on the valid path — wire the invalid output straight to a Response node so callers get a real error instead of the request just stalling.

Signing & verifying tokens

The JWT node has two modes, set via jwtMode: sign to issue a new token, verify to check one — the same operation the Auth node performs internally when authType is jwt, exposed on its own for cases like refreshing a token. Set jwtExpiresIn explicitly — a typical login endpoint checks credentials, then signs a token:

API Endpoint  (POST /login)
   ↓
SQL           (SELECT * FROM users WHERE email = {{email}})
   ↓
Hash          mode: verify — compare {{password}} against the stored hash
   ↓
JWT           mode: sign, expiresIn: "7d"
   ↓
Response      200 { token }

Hashing passwords

Never store a password in plain text. The Hash node has its own hashMode — hash on sign-up, verify on sign-in — with a configurable number of rounds. On verify, it has the same valid/invalid output pattern as Auth — connect invalid to a 401 response, the same way you would for a failed Auth check.

Storing session data

The Local Storage node keeps short-lived data — a session token, a rate-limit counter — available to the rest of the workflow without round-tripping to the database on every request. It's shared across every workflow in the project, not per-request state, so a value set by one execution is visible to the next one.

As with any sensitive value, tokens, hashes and secrets are automatically masked in execution logs — see Debugging.

Interactions with the rest of the platform

• • Store JWT signing secrets and OAuth client secrets in Environment Variables, never on the node itself.
• • Pair Auth with Database nodes to look up the authenticated user's record on every protected request.
• • An assistant connected via MCP calls tools through its own scoped token — it never goes through your Auth node's flow.

Limitations

• • There's no built-in refresh-token rotation — build it explicitly with a second JWT node and your own expiry logic if you need it.
• • OAuth mode handles the token exchange; it doesn't manage the provider-side app registration (client id/secret) for you — that still happens on the provider's dashboard.