如何配置Amazon Cognito实现用户仅访问自身资源的细粒度权限控制

首先明确核心误区：Amazon Cognito是身份认证提供方，仅负责签发携带合法用户身份声明的令牌，不存在“配置Cognito自动限制用户只能访问自身资源”的原生能力。这类越权问题的核心成因是之前的权限校验只做到了令牌是否合法有效，没有做令牌对应的用户身份与待访问资源的归属匹配，具体实现分三步落地：

1. 锚定Cognito令牌内的原生唯一身份标识 #

Cognito签发的JWT格式Bearer令牌，在通过签名、有效期校验后，解码出的payload中必然包含sub字段——这是Cognito为每个用户分配的全局唯一、不可篡改的用户ID，也就是你API路径中<user_Id>参数应该对应的真实值。

• 不要用自己业务层生成的自定义用户名、昵称作为路径的用户标识，全链路统一用sub作为用户唯一ID，从源头避免自定义属性被篡改的风险

2. 在API层强制做身份与路径参数的匹配校验 #

这是解决越权问题的核心动作，没有捷径：

• 如果你使用API Gateway的原生JWT授权器对接Cognito，校验通过后网关会自动把令牌的声明字段（claims）注入到请求上下文，可直接从$context.authorizer.claims.sub获取当前请求的认证用户ID
• 加一层路由判断逻辑：把上下文里的用户ID，和API路径参数中的user_Id做等值对比
  • 两者完全一致，才把请求转发给后端服务
  • 两者不一致，直接返回403 Forbidden响应，不触发后续的业务逻辑
• 如果你是在后端服务层做Cognito令牌校验，在接口前置拦截器中加完全相同的判断逻辑即可
  举个实际场景的校验流程：

用户Y拿着自己的合法令牌请求PUT /users/X/ITEM1接口

1. 令牌校验通过，从令牌中解析出当前用户的sub值为Y
2. 提取路径参数中的user_Id值为X
3. 两个值不匹配，直接拦截请求返回403，请求根本不会到达修改用户X数据的业务代码

3. 从数据层做权限兜底 #

即便路径参数的校验做了，也需要在数据查询层加归属判断：

• 存储资源时，把资源的创建/归属用户ID（直接存当前用户的sub值）作为必填字段写入数据库
• 所有修改/查询资源的请求，数据库查询条件中必须增加归属用户ID = 当前认证用户的sub的过滤规则，哪怕路径参数被篡改、路由校验漏判，也不会查到其他用户的资源

常见踩坑提醒 #

• 永远不要信任前端传递的用户ID参数，所有用户身份的取值都必须从校验通过的令牌中解析，不能依赖前端传参
• 接口级的“登录即可访问”校验，解决不了水平越权问题，必须落地到单资源的归属校验层

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