Dify 工作流 API 接口默认使用 API Key 进行鉴权，请求头需携带 Authorization: Bearer <api_key>。防止未授权访问的关键在于区分密钥类型并通过外部网关限制访问来源。
先说结论：Dify 接口安全依赖 API Key 保密性，应用层无法单独防止密钥泄露后的滥用，需配合网络层策略。
- 先判断：确认使用的是应用级 API Key 而非控制台管理 Key。
- 优先做：在 Nginx 或云网关层配置 IP 白名单限制 API 路径。
- 再验证：使用无效 Key 请求接口确认返回 401 状态码。
命令速用版
使用 curl 命令测试鉴权配置是否生效，替换 <your_api_key> 和 <app_id> 为实际值。
curl -X POST https://<your_dify_host>/v1/chat-messages \
-H "Authorization: Bearer <your_api_key>" \
-H "Content-Type: application/json" \
-d "{\"inputs\": {}, \"query\": \"test\", \"response_mode\": \"blocking\"}"若鉴权生效，不带 Key 或 Key 错误时应返回 HTTP 401 Unauthorized。
为什么会这样
Dify 采用无状态的 Token 鉴权机制，服务端仅验证请求头中的 Key 是否匹配数据库记录。这种设计方便集成，但意味着一旦 Key 泄露，持有者即可冒充合法用户调用接口。Dify 开源版本身不提供应用级 IP 白名单功能，因此必须依赖部署环境的安全策略来弥补网络层访问控制。
分步处理
步骤 1：获取正确的 API Key
登录 Dify 控制台，进入具体应用页面，点击“访问 API”或“概览”获取 API Key。确保使用的是该应用专属的 Key，不要使用控制台账户的 Personal Access Token。
步骤 2：配置请求头
在客户端代码中，将 Key 放入 HTTP 请求头的 Authorization 字段，格式为 Bearer <key>。避免将 Key 硬编码在前端代码或公开仓库中。
步骤 3：部署网关限制（可选但推荐）
若为自托管部署，在 Nginx 配置中限制 /v1/ 相关路径仅允许受信任 IP 访问。若使用云服务，配置安全组或 WAF 规则限制来源 IP。
步骤 4：密钥轮换
定期在 Dify 控制台重置 API Key。重置后旧 Key 立即失效，需同步更新所有调用方配置。
怎么验证是否生效
使用错误 Key 发起请求，检查响应状态码是否为 401。查看 Dify 应用日志，确认未授权请求被记录。若有网关层限制，尝试从非白名单 IP 请求，确认连接被拒绝或返回 403。
常见坑
前端直接暴露 Key：浏览器端代码可见所有请求头，切勿在 Web 前端直接调用 Dify API，应通过后端中转。
混淆 Key 类型：控制台 API Key 权限过高，仅限运维使用；应用 API Key 权限受限，适合业务调用。
日志泄露：检查服务器日志配置，确保不打印完整的 Authorization 头信息。
常见问题
API Key 泄露了怎么办？
立即在 Dify 控制台重置该应用的 API Key，旧 Key 会即刻失效，然后更新业务代码中的新 Key。
支持 OAuth 或 SSO 鉴权吗？
公开资料中没有看到可靠的量化数据说明原生支持 OAuth 对接工作流 API，通常需通过中间件转换令牌。
如何限制 API 调用频率？
Dify 应用设置中可配置配额限制，但更建议在网关层使用限流插件控制 QPS。
参考来源
- Dify Official Documentation, API Authentication, https://docs.dify.ai/v/zh-hans/develop/api-docs/auth
- Dify GitHub Repository, Issues regarding API Security, https://github.com/langgenius/dify