Rest OAUTH 2范围设计

我们有一个支持中心应用程序，其中包含一些rest api

票证、联系人、用户设置->（工作流、用户、部门、配置文件和基于角色的授权）、其他服务 集成数据api

我们正试图为这些定义Oauth范围。我们发现困难的主要问题是：

• OAuth范围应该是多细粒度的，细粒度范围和粗粒度范围的权衡是什么

• 我们可以将多个作用域关联到单个api端点吗？ 例如1:GET/workflow scope=“自动化，设置”。 在这种情况下，那些有权访问其中一个作用域的人可以访问api
  买/买票？include=“contacts”scope=“票据、联系人” 这里的ticket是主要数据，contact是可选的。不是所有的api请求都会询问contact的信息，但是如果是这样的话 他们需要有联系人访问权限。在这种情况下，资源服务器必须拒绝请求或过滤数据 基于范围

• 如何定义集成数据在我们这边持久化或从其他资源服务器获取的范围
  例如：GET/contacts/{id}/associatedCrmContact
  我们这边的联系人映射到crm应用程序中的相同联系人。要获取此数据，我们提供上述端点

• 我们已经有了应用程序级别的授权。这是一个配置文件，基于角色的授权，可以重新配置 由支持管理员在任何时候。我们也有真正细粒度的现场级授权。问题再次出现 这是 1.此动态用户授权应如何适应新的OAuth2范围。 2.在应用程序级别没有票证添加权限的人不能将其提供给计算机/应用程序。 3.我们是否应该应用用户级配置文件检查，而不考虑机器或用户

• 如何定义端点中包含复合数据的作用域
  Eg1:GET tickets/{Id}/threads，GET tickets/{Id}/comments，GET tickets/{Id}/conversation 线程和注释都按时间排序
  获取/订阅源，订阅源有票证、联系人、用户、部门信息