Web services 在SOA体系结构中集成OAuth2提供程序-需要信息

我需要在我目前正在设计的SOA中实现授权机制

我们将有三个服务，每一个都被强制使用它们的公共接口进行通信，因此任何类型的内部通信和后台处理都必须涉及对其他服务端点的授权

另外，我们将在用户浏览器中运行一个客户端应用程序，当然，它也需要访问资源

因此，当其中一个服务需要执行涉及另一个服务公开的资源的任务时，需要服务器到服务器和客户端到服务器的通信

我目前正在考虑实现OAuth2，因为我真的希望有一个标准的授权框架，更具体地说，我想实现服务器到服务器的授权，以及浏览器内应用程序，它将在登录时发送用户数据，然后忘记密码以增强安全性

它应该运行良好，但我似乎发现规范的某些部分与此设计相冲突，因为：

客户端凭据应仅允许客户端访问其自己的资源，因此不会对用户资源进行操作 在我的情况下，每个端点3都应该需要不同的令牌，而让浏览器客户端请求一个且仅请求一个令牌一次，然后在当前令牌过期时使用刷新令牌将相同的令牌用于所有后端服务，这对最终用户来说更为合理，会话（仅存在于客户端应用程序中）过期后，它将删除刷新令牌。 两条腿的oauth2模式似乎也是处理客户机到服务器通信的好方法，但它似乎需要额外的永久密钥以及用户/密码，这对我来说似乎没有意义，如果我只有一个客户机，但是期待着创建新的客户端，为了获得私钥而复制用户凭据来验证用户是没有意义的。 因此，我的问题是：

我可以使用一个单独的授权服务公开API来拥有一个集中的OAuth2提供程序吗？ 我是否可以/应该在客户端和所有后端之间共享一个令牌？ 考虑到我会利用作用域来限制当前客户端的能力，谁应该在请求时实际检查作用域？应该是授权服务还是资源服务器本身？ 在这种情况下，您将如何实现OAuth2提供程序？ 我真的希望避免为服务对服务定制发布/密钥解决方案，期待可能的第三方实现，另外，开发团队还需要对OAuth2有深入的了解，以便在内部使用它

另外，我没有身份验证服务，客户端和资源所有者的身份验证将由授权框架本身执行，因为它封装了用户帐户。但我也有一个用户服务来处理用户偏好，因此也可以在那里导出资源所有者凭据验证