假设我们有许多(无状态、基于 HTTP)(微)服务和一堆“守护进程”，它们通过实际使用所述服务来执行各种后台处理。
现在，我希望有一种方法可以让服务和守护进程能够相互验证和授权。例如，执行订单全文索引的守护进程需要:
- 对订单、客户的只读访问权限(其本身需要对公司具有只读访问权限服务)和库存服务
- 对 OrdersSearch 服务的读写访问权限，以便能够更新全文索引。
还有一些应用程序“代表”用户运行。例如，Inventory Web 应用需要对 Inventory 服务进行读写访问权限，但 Inventory 服务本身需要验证用户操作的权限应用程序。
综上所述，我如何实现我刚才描述的目标？我不想使用庞大的企业框架或标准。根据我的阅读，两条腿的 OAuth2 是我所需要的，但我不太确定。
我正在考虑建立一个授权服务，该服务将用于回答诸如“嘿，我是库存服务。客户有什么权限 现在正在给我打电话的服务有给我的吗？”，但这有两个主要的弱点，即分发共享 secret 。
最佳答案
身份验证:
我想象一个身份验证服务，其中请求 API 使用已建立的协议(protocol)签署其请求:例如将请求的各个部分与可过期 NONCE 和应用程序 ID 连接起来，然后对其进行哈希处理以创建签名。然后使用私钥对该签名进行加密。所有请求都必须包含此加密签名和 NONCE 以及应用程序标识符。然后，接收服务查找请求应用程序的公钥。验证 NONCE 尚未过期后，接收服务使用公钥解密摘要并验证签名是否有效(通过重复签名过程并得到相同的签名)。需要一个服务来获取公钥。服务可以将应用程序 ID 缓存到公钥映射。
授权:
这可以使用某种 role based access control 来完成方案。另一个服务可用于查找请求服务是否有权访问所请求的资源。
我认为授权和认证都可以在内部完成，具体取决于时间和金钱以及特化的需要。如果您使用 Java，请查看 Spring Security 。如果您决定创建自定义代码，请向您的经理证明其合理性并获得支持。在线彻底搜索任何其他解决方案，并在您的文章中说明为什么它不适合以及仍然需要自定义解决方案。
关于authentication - 跨微服务授权与认证，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30209442/