未来可以维持的粒度授权

Granular level Authorization which can sustain in future

提问人：nidhi vyas 提问时间：7/12/2023 最后编辑：Brian Tompsett - 汤莱恩nidhi vyas 更新时间：7/14/2023 访问量：34

问：

目前，我们将 OAuth2 作为微服务的授权，其工作方式如下：

  1. 客户端需要注册 clientName、范围信息并获取客户端 ID 和客户端密码。
  2. 若要访问任何 API，请使用代理 API 从授权服务器获取令牌
  3. 使用此令牌调用实际的 API，在 API 代码中，我们通过调用另一个代理 API 来验证令牌
  4. 此代理 API 建立在实际的 OAuth 进程 API （PingFederate API） 之上

问题：

  1. PingFederate API 不会隐式验证范围，我们将在代理中添加显式逻辑来验证范围
  2. 我们不希望验证代理 API 位于代码中，代码上方应该有安全层
  3. 更好的客户管理

我们想要一个解决方案，它提供对资源的细粒度访问，它不与代码一起使用，并具有更好的客户端管理流程。

REST 安全 OAuth-2.0 授权

评论

0赞 akdombrowski 7/12/2023
您能详细解释一下验证范围的含义吗？你对细粒度有什么想法？需要一个示例用例或其他东西。此外，更好的客户管理尚不清楚。您目前在客户管理方面的痛点是什么？你认为它如何理想地工作？这里有许多可能的途径可以采取，从更改您的配置和流程到查看 rbac、abac、pebac 和许多其他类型的基于 x 的访问控制
0赞 nidhi vyas 7/12/2023
在验证令牌以访问特定资源时，应验证该时间是否是使用此资源所需的特定范围生成的令牌。例如，令牌是在资源和访问写入资源上具有 READ 作用域生成的。目前，这种情况正在发生，因为 OAuth 在验证令牌时不会验证范围。对于客户端管理，目前，我们需要提交工单来注册、更新和删除客户端。该票证转到 Ops，然后是所有者，然后是创建客户端。我们怎样才能使这个过程变得顺利。
0赞 akdombrowski 7/14/2023
这就是 OAuth 2 范围声明的用途。“令牌表示特定的访问范围和持续时间，由资源所有者授予，并由资源服务器和授权服务器强制执行。”你所指的是通过资源服务器强制执行。rfc-editor.org/rfc/rfc6749.html#section-1.4

答：

0赞 Gary Archer 7/14/2023 #1

听起来您在设置中缺少一些定义：

API 网关

这应该在调用 API 之前执行工作。它应该处理特定于客户端的安全差异，然后将 JWT 访问令牌转发到 API。

蜜蜂属

每个 API 都应验证 JWT 访问令牌并执行基于声明的授权。但是他们不需要处理浏览器cookie之类的方面。应该不需要 API 来调用代理 API，这感觉像是一个瓶颈。

授权服务器

客户应在此处注册。API 也与此组件交互，至少用于下载令牌签名公钥。

权利管理

如果您希望访问控制位于代码之外，请查看 Open Policy Agent 等系统。API（或网关）可以转发其 JWT 或声明有效负载，以便将某些授权决策外部化。

最后

当 OAuth 解决方案难以管理时，这通常源于尝试管理通用安全组件中的易失性域逻辑。最好的解决方案使用智能设计，找到良好的平衡......

上一个：在我的程序代码中向 REST API 发出 HTTP 请求是否不安全

下一个：限制通过 URL 发送参数的标准 API 安全做法是什么？