AWS托管HTML/CSS/JS站点如何用Cognito令牌在前端控制菜单显隐？

需引入的前端依赖脚本 #

• 不需要从零开发JWT校验、令牌自动刷新的底层逻辑，引入官方维护的轻量认证SDK即可，分两种场景适配：
  • 如果是有前端构建工具的纯静态项目：按需引入@aws-amplify/auth模块，避免全量Amplify包带来的不必要体积增加
  • 如果是无构建流程的原生HTML/CSS/JS站点：直接引入对应版本的aws-amplify浏览器可执行脚本，加载完成后会在全局挂载可直接调用的Amplify、Auth方法

服务端校验逻辑迁移到前端的落地步骤 #

1. 用现有配置初始化认证模块 #

将你已经获取的Pool Id、App client id、Pool所在AWS区域参数填入初始化配置，代码示例：

Amplify.configure({
  Auth: {
    region: '对应Cognito资源的AWS区域',
    userPoolId: '已获取的Pool Id',
    userPoolWebClientId: '已获取的App client id',
    mandatorySignIn: false
  }
})

2. 对齐校验规则，替换原服务端的身份判断逻辑 #

原服务端的流程是“校验请求携带的认证令牌合法性 → 提取用户权限属性 → 判断内容展示范围”，迁移到前端后逻辑完全对齐，不需要重写权限判断规则：

• 调用SDK内置的Auth.currentAuthenticatedUser()方法，该方法会自动完成令牌签名校验、过期校验、自动静默刷新的全流程，无需手动解析JWT、实现校验规则；且该方法的校验逻辑和Cognito服务端的校验规则完全一致，返回的用户身份、权限属性和服务端直接解析令牌得到的结果没有差异
• 从返回的用户对象中提取权限字段，直接复用原服务端的判断逻辑：
  • 读取user.signInUserSession.idToken.payload['cognito:groups'] 可获取用户所属的Cognito用户组，替换原服务端的组权限判断逻辑
  • 读取idToken中存储的自定义属性（如自定义用户角色、权限标记），替换原服务端的自定义权限判断逻辑

3. 实现菜单显隐控制 #

• 在页面DOM加载完成、且SDK完成当前用户身份校验后，遍历所有带权限标记的菜单元素：对不匹配当前用户权限的元素，直接设置display: none或从DOM树中移除
• 绑定SDK提供的认证状态变更回调：当用户登录、登出、令牌完成刷新时，自动重新执行一遍权限判断逻辑，避免多账号切换、令牌过期场景下的菜单显示错误

关键注意事项 #

前端实现的菜单显隐控制仅用于优化交互体验，绝对不能替代服务端的权限校验逻辑：所有受保护的接口、静态资源，即便前端隐藏了对应菜单，只要存在可直接访问的路径，服务端仍必须做完整的令牌合法性校验、权限匹配校验，杜绝越权访问风险。
禁止手动解码本地存储的JWT令牌做权限判断：必须使用SDK经过签名校验后返回的payload值作为权限判断依据，避免用户篡改本地存储内容伪造权限。

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