将已登录用户角色存储在Vuex中是否安全、符合最佳实践？搭配Firebase自定义声明场景

方案合理性判断 #

这套架构整体是Firebase角色权限场景下的常规成熟实践，核心逻辑是合理的：

• Custom Claims 是Firebase官方为轻量角色/权限管控设计的功能，仅包含admin、viewer两种角色的场景完全适配，无需额外引入数据库存储角色，开销极低
• 仅通过Cloud Function修改用户Claims的逻辑符合安全规则，因为Custom Claims仅支持服务端修改，前端无法直接篡改，权限边界清晰
• 前端将角色存入Vuex用于UI展示控制，是前端状态管理的常规操作

注：如果你的应用对外开放注册，「新用户注册默认加admin声明」的逻辑需要调整，避免任意用户注册即可获得管理员权限；如果是封闭内部使用、仅允许指定人员注册的场景则无问题。

安全隐患说明 #

将role: 'admin'存入Vuex甚至持久化到LocalStorage本身不会带来核心安全风险，但你需要明确一个前端权限管控的基本原则：

所有前端层面的权限控制（包括UI隐藏、前端路由拦截）都仅用于优化用户体验，绝对不能作为实际的权限管控依据。

• 前端存储的所有数据（包括Vuex状态、LocalStorage值）用户都可以通过控制台手动篡改，比如将存储的viewer改成admin，就能看到管理员专属的UI。但只要你的后端资源（Firestore、Storage、Cloud Function受保护接口）全部直接校验用户请求携带的ID Token中的Custom Claims，而非信任前端传递的role参数，就算用户篡改了前端存储的角色值，也无法执行任何管理员权限的操作，所有越权请求都会被Firebase安全规则拦截。
• 仅有的小风险是用户篡改本地存储后会看到不属于自己的UI，属于体验问题，不涉及实际数据安全。

标准架构优化建议 #

这套方案已经属于非常典型的Firebase+前端框架的权限架构，只需要补充几个最佳实践即可：

• 所有后端资源必须加对应的权限校验：比如Firestore的管理员操作路径，安全规则要加request.auth.token.role == 'admin'的校验；Cloud Function的受保护接口也要先解析用户ID Token，校验Claims中的角色后再执行逻辑。
• 前端获取角色时，统一使用Firebase官方提供的getIdTokenResult()方法解析，不要手动解码JWT，示例代码如下：

  const idTokenResult = await firebase.auth().currentUser.getIdTokenResult()
  const role = idTokenResult.claims.role
  

• 每次应用冷启动、ID Token刷新时，都要重新解析ID Token中的Claims更新Vuex状态，不要完全信任LocalStorage持久化的角色值，既避免用户篡改的本地值长期生效，也能同步管理员在后台修改的用户角色。
• 如果想避免用户看到不属于自己的UI，可以在路由跳转时重新校验一次ID Token中的角色，和Vuex存储的值做比对，不一致就更新状态。

内容的提问来源于stack exchange，提问作者Jim Jones