我需要在我目前正在设计的 SOA 中实现授权机制。
我们将拥有三个服务，每个服务都被强制使用它们的公共接口进行通信，因此任何类型的相互通信和后台处理都必须涉及对其他服务端点的授权。
另外，我们将在用户浏览器中运行一个客户端应用程序，当然，它也需要访问资源。
因此，我们将同时进行服务器到服务器和客户端到服务器的通信（当其中一个服务需要执行一些涉及由另一个服务公开的资源的任务时，将需要服务器到服务器）。
我目前正在寻求实施 OAuth2，因为我真的很想拥有一个标准的授权框架，更具体地说，我正在考虑实施客户端凭据以授权服务器到服务器，并为浏览器内的资源所有者密码凭据应用程序（它将在登录时发送用户数据，然后忘记密码以增强安全性）。
它应该运行良好，但似乎我发现规范的某些部分与此设计冲突，因为：
- 客户端凭据应该只允许客户端访问他们自己的资源（因此不作用于用户资源）
- 每个端点（在我的情况下为 3 个）都应该需要一个不同的令牌，而让浏览器客户端请求一个（并且只有一个）令牌一次，然后对所有后端服务使用相同的令牌（使用当前令牌过期时刷新令牌，使所有对最终用户透明，一旦会话（仅存在于客户端应用程序内部）过期，它将删除刷新令牌）。
- 2-legged oauth2 模式似乎也是处理客户端到服务器通信的好方法，但它似乎需要额外的永久密钥以及用户/密码，这对我来说似乎没有意义（如果我只有一个客户端，但期待创建新客户端，因此复制用户凭据以对用户进行身份验证以获取私钥是没有意义的）。
所以我的问题是：
- 我可以使用公开 API 的单独授权服务来拥有一个集中的 OAuth2 提供程序吗？
- 我可以/应该在客户端和所有后端之间共享一个令牌吗？
- 鉴于我会利用范围来限制当前客户的能力，谁应该在请求时实际检查范围？应该是授权服务还是资源服务器本身？
- 在这种情况下您将如何实现 OAuth2 提供程序的任何建议？
我真的很想避免服务到服务的自定义发布/密钥解决方案，期待可能的第 3 方实施（另外，开发团队将需要对 OAuth2 有深入的了解以用于其他目的，所以这真的很好也可以在内部使用它）。
PS我没有身份验证服务，客户端和资源所有者的身份验证将由授权框架本身执行，因为它封装了用户帐户。但我也有一个处理用户偏好的用户服务，因此也可以在那里导出资源所有者凭据验证。