谁应该是资源所有者?

时间:2019-10-11 21:24:27

标签: oauth oauth-2.0

我正在设计一个API,并且对谁应该是访问令牌的资源所有者有一个设计问题。

API

这大致就是API的组织方式:

  • 资源被分组到工作空间中。
  • 用户有很多工作区。
  • 用户可以邀请其他用户作为协作者进入这些工作空间。
  • 用户是简单的实体,可以进行身份​​验证并可以访问许多工作区。

有两种类型的客户端连接到此API,如下所示:

                       +-----------------------------+
                       |                             |
                +------|   API / Identity Provider   |------+
                |      |                             |      |
                |      +-----------------------------+      |
                |                                           |  
     +--------------------------+          +--------------------------+
     |        Web Client        |          |    Server Agent/Client   |   
     |      Scope: global       |          |     Scope: workspace     |
     |   User + All Workspaces  |          |    Specific workspace    |
     +--------------------------+          +--------------------------+

前端网络客户端

授予用户具有 global 范围的访问令牌,前端客户端使用该令牌访问此帐户下API的所有资源和工作空间。

服务器安装的代理

用户可以在Web服务器上安装代理,这些代理可以将环境中的信息共享到特定的工作区。

由于用户可以访问不同公司可能拥有的工作区,因此代理应仅限于旨在进行通信的工作区。

例如,一名顾问开发人员可以以团队成员的身份访问三个不同公司的工作空间:A,B和C。这三个工作空间显示在他的帐户下。公司A要求开发人员在服务器中安装代理,该服务器仅消耗与工作区A相关的API资源。

允许该代理也访问公司B和C的工作区是不明智的。这可以通过使用Resource Indicators来完成。

从外观上看,授权服务器的授权页面允许选择工作空间来授权客户端,如下所示:

                  Where do you want to install this agent?
                     Select the workspace to connect.


                       +----------------------------+
                       |  Workspace A           [√] |
                       |----------------------------|
                       |  Workspace B           [ ] |
                       |----------------------------|                       
                       |  Workspace C           [ ] | 
                       +----------------------------+                       

                       +----------------------------+        
                       |          CONTINUE          |
                       +----------------------------+       

在前端的工作区的 Settings 中有一个 Apps 页面,其中显示了已连接的应用程序列表。

情况

代理已获得授权并与工作区A通信。

明天公司决定将开发人员从其团队中删除。

问题1:是否也应撤销代理对API的访问?如果资源所有者是工作区或开发人员,则即使开发人员对工作区的访问权限已删除,他也可以在发生这种情况之前从代理那里获取访​​问/刷新令牌,然后再中继/模拟到API。除此之外,还有其他选择吗?我看不出如何防止这种情况发生,因为他本来也可以抓住客户的秘密。

我认为此流程是期望的和期望的:公司A雇用有能力的开发人员代表他们安装代理(因为他们可能不知道如何安装),因此他们邀请他们作为团队成员进入工作区,然后开发人员安装了代理,他们将其从团队中删除。如果从安全的角度来看这意味着撤回对代理的访问权限以防止可能的冒名顶替,那么有什么替代方法可以使代理不断开连接呢?保持联系是他们雇用他的原因。

问题2:是否可以根据上下文拥有两种不同类型的资源所有者?假设授权服务器通过范围和一些其他参数来解决这个问题。

例如,在前端客户端上,资源所有者是用户,因此客户端传递global范围,对于代理,资源所有者是特定的工作空间,方法是将{ {1}}范围和一个附加参数,即workspace

这还将使在工作区应用程序设置内列出所有已连接的应用程序更加容易。

这种想法是否正确,或者我缺少什么?

0 个答案:

没有答案