n8n Webhook Authentication Guide

An n8n Webhook node with no authentication enabled will run for anyone who has the URL. By default, that is exactly how a new webhook node comes configured: no password, no token, no check at all. It works immediately, which is convenient during development and a real problem the moment a workflow touches a CRM, sends messages, or writes to a database in production.

I turn on authentication as one of the last steps before activating any client-facing webhook, right after the workflow logic itself is working. This post covers the three built-in authentication methods n8n gives you on the Webhook node, when to reach for each one, and how they differ from the custom signature verification you would build for a specific provider like Retell or Stripe.

Why n8n Webhooks Need Authentication

A webhook URL that is publicly reachable and unauthenticated can be triggered by anyone who finds it, whether that is through a leaked screenshot, a scan, or simple guessing if the path is not random. An unauthenticated webhook sitting in front of a workflow that writes to your CRM or sends messages on your behalf is an open door, not just a theoretical risk. The fix is built directly into the node, and it takes a couple of minutes to configure once you know where it lives.

Basic Authentication

The simplest option. The caller has to include a username and password in the request's Authorization header, base64-encoded, the same standard mechanism browsers use for basic HTTP auth prompts. n8n checks the incoming credentials against what you configure and rejects anything that does not match with a 401.

This works well when the sending system supports basic auth natively in its own webhook configuration, which many platforms do. It is quick to set up and easy to test with a tool like Postman before going live.

Header Authentication

Instead of a username and password, Header Auth checks for a specific header name and value you define, commonly used as an API-key-style pattern: a header like X-API-Key with a secret value only your systems know. This is the option to reach for when the sending platform lets you set a custom header on its outgoing webhook but does not support basic auth specifically. It is just as easy to implement on custom backends and widely supported by platforms that allow custom webhook headers.

JWT Authentication

The most advanced of the three built-in options. The caller signs a JSON Web Token with a shared secret or key, and n8n verifies the signature (and can check claims like expiry) before allowing the request through. This adds tamper-evidence and expiry to the authentication, which basic and header auth do not give you on their own.

JWT is worth the extra setup for high-security workflows where you specifically need a token that expires and cannot be replayed indefinitely. For most everyday webhook use cases, Basic Auth or Header Auth is enough, and JWT is more configuration than the situation usually calls for.

IP Restrictions

Beyond the three authentication methods, the Webhook node also supports an IP allowlist option, restricting which source IPs are allowed to reach the endpoint at all, specified as CIDR ranges. This is a network-layer filter that works well alongside authentication rather than instead of it. If the sending platform publishes a fixed set of outbound IPs, as many CRM and telephony providers do, an allowlist adds a layer that rejects everything else before the request even reaches your authentication check.

Test vs Production Webhooks

Worth repeating here because it interacts directly with authentication: every Webhook node has a separate test URL and production URL. The test URL only responds while you have the editor open and are actively listening for a test event. The production URL is what goes live once the workflow is activated. Configure authentication before you hand the production URL to the sending system, not after, since a webhook running unauthenticated in production even briefly is enough for something to find and hit it.

Common 401 and 403 Problems

401 immediately after enabling auth. Almost always a credential mismatch between what you configured in n8n and what the sending system is actually sending. Test with Postman first, sending the exact header or basic auth credentials you configured, before assuming the sending platform's side is broken.

Works in testing, fails in production. Check that you updated the sending system's configuration to use the production URL, not the test URL, and confirm the same authentication credentials were carried over. It is easy to configure auth against the test URL during development and forget the production URL needs the same setup.

JWT rejected even with a correct-looking token. Usually a claims issue, most commonly expiry, rather than a signature problem. Check the token's expiry window against how long it might realistically sit before the request reaches n8n, particularly if there is any queueing or delay on the sending side.

Production Security Checklist

Before a webhook goes live with real data flowing through it: authentication is enabled using one of the three built-in methods appropriate to what the sender supports, an IP allowlist is configured if the sender publishes fixed outbound IPs, the production URL (not the test URL) is what the sending system actually points to, and the workflow itself does not trust the payload blindly even after authentication passes, since authentication confirms who is calling, not that the specific data inside the request is valid.

For providers that sign their payloads with their own HMAC scheme on top of whatever transport authentication you use, like Retell AI or Stripe, that signature verification is a separate, additional check built with a Code node rather than something the built-in authentication options handle. n8n Webhook Tutorial covers building that HMAC verification step alongside routing and filtering incoming events, and n8n Credentials Security covers keeping the secrets themselves safe once you have them configured. If you are running this at meaningful volume, n8n Queue Mode covers scaling the infrastructure behind a busy authenticated webhook.

Getting webhook authentication configured correctly the first time, matched to what your specific sending platform actually supports, is exactly the kind of setup work I take on for clients. If you have a production n8n webhook that needs to be locked down properly, book a free 30-minute call and bring the platform sending to it, and we will get the right method configured.

Frequently Asked Questions

How do I secure an n8n webhook?

Enable one of the three built-in authentication methods on the Webhook node: Basic Auth, Header Auth, or JWT. Add an IP allowlist as an additional layer if the sending platform publishes fixed outbound IP ranges.

Does n8n support JWT webhook authentication?

Yes, it is one of the three built-in options on the Webhook node's authentication setting, alongside Basic Auth and Header Auth. It adds token expiry and tamper-evidence that the other two methods do not provide on their own.

What is the safest n8n webhook authentication method?

JWT is the strongest of the three built-in options because tokens can expire and are harder to replay. For most webhook use cases, Header Auth with a strong secret value is sufficient and simpler to configure and debug.

What is the difference between test and production webhook URLs?

The test URL only responds while the editor is open and actively listening for a test event. The production URL is what goes live once the workflow is activated, and it is what any real sending system should be configured to use.

How do I fix a 401 error on an n8n webhook?

Check that the credentials or header value configured on the Webhook node exactly match what the sending system is actually sending, and confirm you are testing against the correct URL, test or production, for the stage you are in.

Can I restrict n8n webhooks by IP?

Yes, using the IP allowlist option on the Webhook node, specified as CIDR ranges. This works as a network-layer filter alongside authentication rather than replacing it.

Is built-in authentication enough, or do I still need signature verification?

For most webhooks, the built-in options are enough. For providers like Retell AI or Stripe that sign each payload with their own HMAC scheme, add that as a separate verification step, since it confirms payload integrity rather than just who is allowed to call the endpoint.

If you would rather have this configured than configure it yourself, I take on n8n and automation security work through Fiverr.