n8n Webhook 安全指南：三种认证方式保护你的工作流

n8n Webhook 安全指南：三种认证方式保护你的工作流 n8n Webhook 安全指南：三种认证方式保护你的工作流 Modified July 22, 2025 Code block JSON Copy echo YWRtaW46c2VjdXJlMTIz|base64 d admin:secure123% 这就是为什么说 Basic Auth 一定要配合 HTTPS 使用——因为它只是编码，不是加密！ 🎯 优势： 几乎所有工具都支持，包括 Postman、curl 命令行，甚至浏览器都能直接弹窗让你输入。对接老系统特别友好。 安全提醒： 一定要用 HTTPS！Basic Auth 的凭据只是 base64 编码，不是加密。 三、JWT Token Authentication JWT 不只是认证，还能携带用户信息、权限等数据。 1、配置步骤 1. 选择 JWT Auth 2. 配置密钥类型为 "Passphrase"（对应对称加密） 3. 配置签名算法（推荐 HS256） 4. 填入密钥，比如 a string secret at least 256 bits long 2、理解 JWT 的组成 我们可以用 jwt.io 来理解 JWT 是怎么工作的。一个完整的 JWT 包含三部分： • Header：指定算法和类型 Code block JSON Copy { "alg": "HS256", "typ": "JWT" } • Payload：存放用户数据和权限信息 Code block JSON Copy { "sub": "1234567890", "name": "林月半子", "admin": true, "iat": 1516239022 } • Secret：用于签名的密钥，确保 token 没被篡改 3、客户端调用示例 在 jwt.io 上，你可以看到当你填入相同的密钥（比如 a string secret at least 256 bits long）后，会生成类似这样的 JWT： Code block Plain Text Copy eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Iuael aciOWNiuWtkCIsImFkbWluIjp0cnVlLCJpYXQiOjE1MTYyMzkwMjJ9.KD4YF5yBE2v43w6j9CXZB8ZNwd4F8ut6jn4RuvQ rhE 客户端需要把这个 JWT 作为 Bearer Token 发送： Code block JSON Copy curl location 'http://localhost:5678/webhook test/58920fb3 8cab 407e 97b8 96a194f15d67' \ header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Iuael aciOWNiuWtkCIsImFkbWluIjp0cnVlLCJpYXQiOjE1MTYyMzkwMjJ9.KD4YF5yBE2v43w6j9CXZB8ZNwd4F8ut6jn4RuvQ rhE' \ form 'message="hello"' 结果：{"output":"Hello! How can I assist you today?"} 使用 JWT 认证后，n8n 会自动解析 JWT 中的 payload 信息，你可以在工作流中直接使用这些用户数据： 这样你就能根据不同用户的身份和权限，执行不同的业务逻辑。 🎯 适用场景： • 多用户系统，需要区分不同权限 • 微服务架构中的服务间认证 • 需要追踪用户行为的场景 四、怎么选？ 还记得文章开头的那个决策流程图吗？现在我们已经详细了解了三种认证方式，来看看具体怎么选择： 快速原型阶段： Header Auth，简单粗暴，够用。 企业内部系统对接： Basic Auth，兼容性好，IT 部门容易接受。 复杂业务场景： JWT，功能强大，扩展性好。 实际案例： 如果你在做一个客户服务系统，不同客户只能看到自己的数据，那 JWT 就很合适。在 token 里放客户 ID，工作流收到请求后就知道该返回哪个客户的数据。 记住：安全和便捷往往需要平衡，选择最适合你当前需求的方案就是最好的。 写在最后 webhook 的安全防护确实容易被忽视，但一旦出问题，损失可能很大。花点时间配置好认证机制，既能防止恶意攻击，也能避免误操作。 最重要的是：安全不是一次性的事情，需要持续关注和维护。今天配置好了，明天还要记得检查和更新。 希望这篇文章能帮你的 n8n 工作流更安全一些！ 我是林月半子，关注我，带你一起挖掘工作流自动化的无限可能。 林月半子的AI笔记 jwt.io jwt.io 这就是为什么说 Basic Auth 一定要配合 HTTPS 使用——因为它只是编码，不是加密！ 🎯 优势： 几乎所有工具都支持，包括 Postman、curl 命令行，甚至浏览器都能直接弹窗让你输入。对接老系统特别友好。 安全提醒： 一定要用 HTTPS！Basic Auth 的凭据只是 base64 编码，不是加密。 优势： 几乎所有工具都支持，包括 Postman、curl 命令行，甚至浏览器都能直接弹窗让你输入。对接老系统特别友好。 安全提醒： 一定要用 HTTPS！Basic Auth 的凭据只是 base64 编码，不是加密。 三、JWT Token Authentication JWT 不只是认证，还能携带用户信息、权限等数据。 1、配置步骤 1. 选择 JWT Auth 2. 配置密钥类型为 "Passphrase"（对应对称加密） 3. 配置签名算法（推荐 HS256） 4. 填入密钥，比如 a string secret at least 256 bits long 2、理解 JWT 的组成 我们可以用 jwt.io 来理解 JWT 是怎么工作的。一个完整的 JWT 包含三部分： jwt.io • Header：指定算法和类型 • Payload：存放用户数据和权限信息 • Secret：用于签名的密钥，确保 token 没被篡改 3、客户端调用示例 在 jwt.io 上，你可以看到当你填入相同的密钥（比如 a string secret at least 256 bits long）后，会生成类似这样的 JWT： jwt.io 客户端需要把这个 JWT 作为 Bearer Token 发送： 使用 JWT 认证后，n8n 会自动解析 JWT 中的 payload 信息，你可以在工作流中直接使用这些用户数据： 这样你就能根据不同用户的身份和权限，执行不同的业务逻辑。 🎯 适用场景： • 多用户系统，需要区分不同权限 • 微服务架构中的服务间认证 • 需要追踪用户行为的场景 适用场景： • 多用户系统，需要区分不同权限 • 微服务架构中的服务间认证 • 需要追踪用户行为的场景 四、怎么选？ 还记得文章开头的那个决策流程图吗？现在我们已经详细了解了三种认证方式，来看看具体怎么选择： 快速原型阶段： Header Auth，简单粗暴，够用。 企业内部系统对接： Basic Auth，兼容性好，IT 部门容易接受。 复杂业务场景： JWT，功能强大，扩展性好。 实际案例： 如果你在做一个客户服务系统，不同客户只能看到自己的数据，那 JWT 就很合适。在 token 里放客户 ID，工作流收到请求后就知道该返回哪个客户的数据。 记住：安全和便捷往往需要平衡，选择最适合你当前需求的方案就是最好的。 写在最后 webhook 的安全防护确实容易被忽视，但一旦出问题，损失可能很大。花点时间配置好认证机制，既能防止恶意攻击，也能避免误操作。 最重要的是：安全不是一次性的事情，需要持续关注和维护。今天配置好了，明天还要记得检查和更新。 希望这篇文章能帮你的 n8n 工作流更安全一些！ 我是林月半子，关注我，带你一起挖掘工作流自动化的无限可能。 🔗 原文链接：https://mp.weixin.qq.com/s/xuuZA1kbLiGCipjkozBnOA 作者：林月半子的AI笔记 在自动化流程中，webhook 是连接外部服务和 n8n 工作流的重要入口，但如果没有做好安全防护，极易被滥用，导致数据泄露或高额 API 费用。前段时间看到群里有小伙伴说，他的 n8n webhook 被人恶意刷了好几千次，API 费用直接爆炸。这事听着就心疼！ 最近看了 Nate Herk 的这个视频，对 n8n webhook 的安全配置讲得特别清楚。今天就结合视频内容，来聊聊 n8n webhook 的三种认证方式。 Nate Herk 的这个视频 其实 webhook 的安全问题很常见。n8n 生成的 webhook URL 是公网可访问的，任何人拿到这个链接都能触发你的工作流。 虽然 n8n 会为 webhook 生成一个很长的随机路径（比如 58920fb3 8cab 407e 97b8 96a194f15d67），理论上很难被猜到，但如果 URL 意外泄露——比如出现在日志文件、错误报告或者被无意中分享出去，那就麻烦了。 如果不做防护，后果可想而知： 📌 • 被人疯狂刷接口，服务器扛不住 • API 调用费用蹭蹭往上涨 • 工作流里有敏感操作的话，数据可能被搞走 • 被人疯狂刷接口，服务器扛不住 • API 调用费用蹭蹭往上涨 • 工作流里有敏感操作的话，数据可能被搞走 所以除了保护好 webhook URL 不被泄露外，配置认证机制是最稳妥的做法——即使 URL 被人知道了，没有正确的认证信息也无法触发你的工作流。 一、Header Authentication 这种方式就是在请求头里加个"暗号"。 1、配置步骤 1. webhook 节点选择 Header Auth 2. 自定义一个 header 名称，比如 api key，设置对应的值，比如 my secret 123 2、客户端调用示例 ❌ 未带认证信息（错误）： ✅ 正确调用方式： 客户端请求时必须带上这个 header 🎯 什么时候用： 适合内部系统集成，或者和可信任的第三方对接。配置简单，效果立竿见影。 注意事项： 密钥要定期换，一旦泄露就得赶紧改。 什么时候用： 适合内部系统集成，或者和可信任的第三方对接。配置简单，效果立竿见影。 注意事项： 密钥要定期换，一旦泄露就得赶紧改。 二、Basic Authentication 用户名+密码的经典组合，虽然"老土"但兼容性一流。 1、配置步骤 1. 选择 Basic Auth 2. 设置用户名（比如 admin）和密码（比如 secure123） 2、客户端调用示例 客户端用标准的 HTTP Basic 认证发请求 ✅ 客户端正确调用方式： Basic Auth 原理解释： 其实 YWRtaW46c2VjdXJlMTIz 这串看起来神秘的字符，就是 admin:secure123 经过 base64 编码的结果。你可以验证一下：