【问题标题】:AWS Cognito Resource server identifier and scopes Resource server bringsAWS Cognito 资源服务器标识符和范围 资源服务器带来
【发布时间】:2022-01-07 05:46:31
【问题描述】:

我读过docsthis。努力将 Cognito + API GW + OAuth2 组合在一起。我的问题:

  1. 我是否正确理解资源服务器范围的流程和使用:客户端应用程序向 Cognito 用户池询问 JWT 令牌(发生登录/授权)。令牌请求包含自定义范围 A,以便 Cognito 返回 JWT 访问令牌。之后,客户端应用程序使用获得的令牌对“资源服务器”(例如,对我们配置的 API GW 端点)进行 REST API 调用。 API GW 端点设置为使用我们的 Cognito 用户池作为授权方 + 范围设置为自定义范围 A。因此,此处的范围就像“角色”或“权限”:如果客户端具有有效的 JWT 令牌 + 此令牌有一个自定义范围 A inside + API GW 端点设置为使用该范围 - 然后客户端应用程序被授权调用 API GW 端点。实际上,它就像端点的“基于资源的 IAM 策略”,但此处不涉及 IAM。
  2. 我是否正确理解 AWS Cognito 资源服务器标识符是任意字符串?它不是实际“资源服务器”(我们的 API GW)的 URI。 URI 格式纯粹用于唯一性,并且在 Cognito 资源服务器标识符很重要或以某种方式检查/验证的情况下,流程中没有位置?此外,资源服务器标识符似乎不会影响 JWT 令牌生成或令牌内容?

感谢您的澄清。

【问题讨论】:

  • 我会把你的问题分开,否则它可能会被标记为缺乏焦点
  • @ErmiyaEskandary,谢谢。改写了一下。我想澄清资源服务器 id + 范围的使用。

标签: oauth-2.0 amazon-cognito scopes


【解决方案1】:
  1. 应用范围不应与用户权限混淆。范围定义应用程序对用户资源的访问权限。因此资源访问是两者的重叠:

    • 检查用户是否有访问权限
    • 检查应用程序是否具有范围(访问用户访问权限)
  2. 正如您所指出的,通过要求 URI,AWS 似乎强制执行抗冲突标识符。这不是一种常见的做法,也没有真正的安全优势,AWS 也没有验证您控制资源。

【讨论】:

  • 安德鲁,谢谢。也许你可以为我了解scopes。想象一下,对于第一个问题,我们不使用 API GW,但我们实现了自己的 REST 端点 + 我们自己的传入令牌的授权和验证。传入令牌中仅存在 scope=A 是否被视为客户端应用有权访问端点的证明?
  • @Max 我更新了一些细节。范围不是证明自己可以访问的东西。您必须考虑令牌主体/委托人的访问权限。
  • @Max 这取决于您的应用程序。不要引入 AWS IAM,这是不同的,它严格处理对 AWS 资源的访问。对于您的应用程序,您定义访问要求。举个简单的例子,如果用户拥有 s3 对象,请在前缀中包含主题 ID,并在授予访问权限之前将其与令牌中的 sub 值进行比较。如果用户在数据库中有记录,请确保 sub 值与 owner 列匹配。
  • @Max 是的,这是自定义授权人的一种可能性。然而,在您的 api 网关和您的处理程序之间拆分授权检查更为常见。 This blog post 有更多信息。
  • @Max 没问题。 OAuth(特别是范围)可能会令人困惑,所以我很高兴能帮助您理解它。如果您有兴趣了解更多信息,我建议您阅读 Aaron Parecki 的一些资料,地址为 oauth.net/articles
猜你喜欢
  • 1970-01-01
  • 2021-01-29
  • 2021-12-02
  • 2021-02-05
  • 1970-01-01
  • 1970-01-01
  • 2018-05-01
  • 2013-08-24
  • 2019-10-27
相关资源
最近更新 更多