// docs / baas security / auth0 hardening

Auth0 安全清单:22 项

Auth0 是一个表面巨大的身份即服务平台 — 应用程序、API (资源服务器)、租户、动作、规则 (旧版)、连接和授权。其中任何一项的配置错误都是身份验证绕过。本清单是涵盖应用程序、回调 / 注销允许列表、令牌和刷新轮换、自定义动作、RBAC、异常检测和持续监控的 22 项审计。每项都可在 Auth0 仪表板中在 10 分钟内验证。

有关 Clerk 上的等效清单,请参阅 Clerk 安全清单。有关身份层配置错误是 AI 工具盲点的背景,请参阅 AI 编码工具为何留下安全漏洞。

应用程序类型和授权类型

应用程序类型和启用的授权类型是 Auth0 中影响最大的设置。出错会打开任何数量的前端代码都无法关闭的攻击类别。

对仅浏览器应用使用 Application Type = Single Page Application,对服务端渲染应用使用 Regular Web Application。错误的类型允许错误的授权类型 — 例如启用了 SPA 授权的 Regular Web App 启用无 PKCE 的 Implicit 流,它通过 URL 片段泄漏令牌。
在每个应用程序上禁用 Implicit 授权类型。仪表板 → Application → Advanced Settings → Grant Types → 取消勾选 Implicit。Implicit 流在 URL 片段中返回令牌,它们会被记录在浏览器历史和分析中。使用带 PKCE 的 Authorization Code。
除非你有文档化的需求,否则禁用 Password 授权。Resource Owner Password Credentials (ROPC) 授权要求你自己处理用户密码 — 这就违背了你购买 Auth0 的大部分理由。除非集成旧系统,否则禁用它。
在每个公共客户端上启用带 PKCE 的 Authorization Code。仪表板 → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256,OIDC Conformant = 已启用。PKCE 是移动应用和 SPA 防止代码拦截所必需的。

回调和注销 URL 允许列表

OAuth 回调路径上的开放重定向是一种令牌窃取原语。Auth0 的允许列表是你唯一的防御。

将 Allowed Callback URLs 设置为你确切的生产回调路径 — 无通配符。 https://yourapp.com/callback,而非 https://yourapp.com/*。通配符回调让攻击者能将令牌重定向到你域名上的任意子路径。
将 Allowed Logout URLs 设置为有限列表。同样规则:仅显式 URL。开放注销重定向让攻击者能制作看起来像你注销后状态的钓鱼页面。
将 Allowed Web Origins 设置为仅你的生产源。用于静默身份验证 (通过隐藏 iframe 进行令牌续订)。通配符源让攻击者页面能针对你的租户执行静默身份验证。
为 API 端点 (而非应用程序) 设置 Allowed CORS origins。Tenant Settings → Advanced → Allowed CORS origins。默认是空 (受限);只添加你控制的显式源。

令牌和刷新轮换

令牌寿命、刷新轮换和签名算法决定任何令牌泄漏的影响范围。

启用 Refresh Token Rotation。Application → Refresh Token Settings → Rotation。每次刷新都会发行新刷新令牌并使旧令牌失效。结合绝对过期,这能遏制令牌窃取。
将 Refresh Token Reuse Interval 设置为 0 (或你的重放容忍度允许的最低值)。重用间隔让令牌可在同一窗口内使用两次 — 除非你有特定原因保留它,否则关闭它。
将 Absolute Refresh Token Expiry 设置为 14-30 天,而非无限。Application → Refresh Token Expiration → Absolute Expiration。Auth0 默认仅 Inactivity,这意味着闲置会话可持续多年。
将 JWT Signature Algorithm 设置为 RS256。Application → Advanced → OAuth → JsonWebToken Signature Algorithm。RS256 使用非对称签名,因此客户端无法伪造令牌。对客户端面向的应用程序绝不使用 HS256。
验证你的 API 接收的每个 JWT 上的 aud 和 iss 声明。在服务端使用官方 Auth0 SDK — 它自动验证这些。手写的 JWT 解析通常跳过受众验证,这是身份验证绕过。

动作和自定义代码

Auth0 Actions (和旧版 Rules) 在登录和其他生命周期事件中在服务端运行。它们可以访问整个请求上下文。这里的不安全代码是一个租户范围的漏洞。

绝不将 event.user 或 event.transaction 作为整个对象记录。这些包含电子邮件地址、IP 地址和其他 PII。仅使用字段级日志记录,并且只记录你需要的。
对任何 API 密钥或 webhook URL 使用机密存储。Actions → Edit → Secrets。绝不在动作代码中将 API 密钥内联为字符串字面量 — 代码对租户上拥有动作编辑器访问权限的任何人都可见。
在将输入持久化为 user_metadata 或 app_metadata 之前验证它们。将 event.body.name 写入 user.user_metadata.display_name 的自助服务动作是一个存储型 XSS 向量,如果你的前端在不转义的情况下渲染该字段。

RBAC 和资源服务器

如果你使用 Auth0 RBAC,角色到权限的映射就是你的授权层。出错则任何已认证用户都能访问管理员端点。

在 Auth0 仪表板中明确定义资源服务器 (API),而不是即时定义。每个 API 都有一个标识符 (audience)、作用域和签名设置。没有注册的 API,所有令牌都为隐式的「Auth0 管理 API」发行 — 错误的受众。
每个 API 配置权限,并在代码中用 scope 声明要求它们。不要在应用程序逻辑中检查角色成员资格;检查访问令牌中的作用域。作用域是 OAuth 原生授权机制。
测试没有所需角色 / 作用域的已认证用户无法访问特权端点。以普通用户登录,尝试调用 POST /api/admin/users/delete。响应必须是 403。

异常检测和租户日志

Auth0 发出高信号事件。设置它们向你的团队告警,而不仅仅放在日志缓冲区中。

启用攻击保护:Bot Detection、Brute Force、Suspicious IP Throttling。仪表板 → Security → Attack Protection。每项在免费层上默认关闭;对生产将它们全部打开。
将租户日志流式传输到 SIEM 或你的应用程序日志。仪表板 → Monitoring → Streams。Auth0 在大多数套餐上保留日志 30 天;长期保留需要流入你自己的系统。
对 fcoa (失败的跨源身份验证) 和 fp (失败的登录) 激增告警。这些在短时间窗口内的爆发是凭据填充。路由到你的待命频道。

后续步骤

对你的生产 URL 运行 FixVibe 扫描 — baas.clerk-auth0 检查会标记打包在 JavaScript 中的 Auth0 客户端机密和其他身份提供商暴露类别。有关 Clerk 上的等效,请参阅 Clerk 安全清单。对于 BaaS 提供商的总览,请阅读 BaaS 配置错误扫描器。