OpenId/OAuth 2流程选型及AWS Cognito场景落地相关问题咨询

流程1与流程3相关问题解答 #

• 只要你获取的访问令牌（Access Token）的aud（受众）声明、scope（权限范围）覆盖了所有需要访问的BFF及微服务，就可以传递同一个令牌进行交互。注意不要将仅用于客户端身份认证的ID Token作为访问令牌传递给后端服务。
• 后端侧token校验的正确流程如下：
  1. 优先校验令牌签名：提前缓存Cognito用户池公开的JWKS公钥，用公钥校验令牌签名是否被篡改，无需每次请求都向Cognito拉取公钥，仅在缓存过期时更新即可。
  2. 校验核心声明字段：确认exp（过期时间）未超时、iss（签发者）为你的Cognito用户池地址、aud（受众）属于后端服务允许的客户端ID范围，同时令牌包含访问对应接口所需的权限scope。
  3. 如有细粒度权限控制需求，可额外校验令牌中携带的自定义用户属性，比如角色、租户ID等信息。

流程2相关问题解答 #

根据调用场景选择对应最优方案即可：

• 如果是无用户参与的纯机器类API调用场景，强烈推荐使用Client ID/Client Secret走客户端凭证（Client Credentials）流程，这是OAuth2针对机器客户端设计的标准安全方案。相比用户名密码模式，Client Secret可单独做权限管控、定期轮换，即使泄露也仅影响对应客户端的权限，不会涉及具体用户的账号安全，也避免了用户名密码被硬编码到调用方配置、代码中的风险。
• 如果是需要关联真实用户身份、对应用户权限的API调用场景，也不建议继续使用用户名密码获取token的密码模式，该模式已在OAuth2.1标准中被正式废弃，安全风险极高。可优先引导调用方使用授权码流程，无浏览器环境的客户端可使用设备授权流程；如果确实需要兼容存量老系统可做临时过渡，但必须增加严格的限流、密文存储限制，同时排期逐步替换为标准安全流程。

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