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

Question

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

我们将提供三种服务，每种服务仅用于使用其公共接口进行通信，因此任何类型的相互通信和后台处理都必须涉及对其他服务端点的授权。

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

因此，我们将同时进行服务器到服务器和客户端到服务器的通信（当其中一个服务需要执行涉及另一个服务公开的资源的某个任务时，将需要服务器到服务器。） / p>

我目前正在寻求实施OAuth2，因为我真的想拥有一个标准的授权框架，更具体地说，我正在考虑实现Client Credentials来授权服务器到服务器，{{3浏览器中的应用程序（它将在登录时发送用户数据，然后忘记密码以增强安全性）。

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

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

所以我的问题是：

1. 我可以使用公开API的单独授权服务来拥有一个集中式OAuth2提供程序吗？
2. 可以/我应该在客户端和所有后端之间共享一个令牌吗？
3. 鉴于我利用范围来限制当前客户应该在请求时检查范围的能力？应该是授权服务还是资源服务器本身？
4. 有关在这种情况下如何实施OAuth2提供程序的任何建议？

我真的想避免为服务到服务提供自定义的发布/密钥解决方案，期待可能的第三方实施（另外，开发团队需要深入了解OAuth2以用于其他目的，因此它会非常好在内部使用它。）

P.S。我没有身份验证服务，客户端和资源所有者的身份验证将由Authorization框架本身执行，因为它封装了用户帐户。但我也有一个用户服务处理用户首选项，因此也可以在那里导出资源所有者凭据验证。