生产环境如何配置Hasura从Authorization头JWT提取角色信息

关于生产环境x-hasura-role请求头的风险与处理 #

生产环境下Hasura并非默认禁止传递x-hasura-role请求头，但你担心的越权漏洞只会在配置错误时出现，核心校验逻辑如下：

• Hasura在JWT认证模式下，对所有角色做白名单校验：无论请求头传入什么x-hasura-role值，最终生效角色必须存在于JWT内https://hasura.io/jwt/claims下的x-hasura-allowed-roles列表中，不在列表内的角色值会直接触发403权限错误，不会生效。
• 普通用户的JWT中绝对不要加入admin角色到允许列表，admin角色对应的管理员密钥仅用于服务端内部调用，严禁下发到前端代码或用户侧。
• 如果不需要支持用户在合法角色范围内切换（比如普通用户切换为内容编辑角色），你可以直接在Hasura JWT配置中关闭请求头角色覆写能力，此时Hasura会完全忽略客户端传入的x-hasura-role头，统一使用JWT中预设的x-hasura-default-role作为当前请求角色。
• 只要正确配置HASURA_GRAPHQL_JWT_SECRET、关闭匿名访问权限，用户手动伪造x-hasura-role=admin请求完全不会生效，不存在越权可能。

关于JWT角色自动解析的配置说明 #

你不需要手动在前端解析JWT提取x-hasura-role再通过Apollo Client传递，Hasura原生支持自动从Authorization头携带的合法签名JWT中提取Hasura Claims，无法正常读取通常是配置偏差导致：

• 首先确认Auth0签发的JWT结构符合要求：Hasura自定义Claims必须放在你配置的命名空间路径下（你示例中使用的https://hasura.io/jwt/claims是标准格式，需确认Auth0的规则配置确实将所有x-hasura-*字段挂在该路径下，而非JWT根目录或其他自定义路径）。
• 检查Hasura端JWT配置中的claims_namespace参数，必须和JWT中Hasura Claims的路径完全一致，路径不匹配时Hasura无法读取到内置角色声明，会出现异常信任客户端请求头的问题。
• 如果你确实需要支持合法范围内的角色切换，前端传递x-hasura-role请求头是安全的：Hasura会对传入值做白名单校验，用户无法伪造JWT允许列表外的角色，不存在篡改风险。
• 注意JWT本身是带签名的，用户篡改JWT内容后签名校验会直接失败，Hasura会拒绝整个请求，不存在前端篡改JWT内角色声明的可能。

内容的提问来源于stack exchange，提问作者Loren Kuich