使用OAuth2/OpenID Connect和微服务进行身份验证和授权

Question

以下是不同的情况：

我的微服务A接收通过API网关并携带有效访问令牌的最终用户发起的请求(JWT，其作用域/声明对应于最终用户：用户名、id、电子邮件、权限等）。这个案子没问题。微服务拥有处理请求的所有信息。

第一个问题：如果微服务A需要调用微服务B会发生什么？

null

null

例如，微服务B中被调用的方法需要用户id才能工作。用户id值可以设置为查询字符串。如果使用用户访问令牌调用该方法，则微服务B可以验证查询字符串中的用户id值是否等于JWT令牌中的用户id值。如果使用服务访问令牌调用该方法，则微服务B无法验证查询字符串值，需要信任微服务A。

对于这个cas，我从OAuth2中听说了“令牌交换”草案。这个想法很有趣。它允许微服务A将用户访问令牌转换为另一个权限较小但为微服务A伪造的访问令牌。

第二个问题：如果微服务A向RabbitMQ推送消息，而微服务B接收到此消息，会发生什么？

null

null

你怎么看？还有其他更好的解决办法吗？

提前谢了。

Answer 1

挺直截了当的。总有两个用例我们将称为最终用户和App2App。总是要两样都搞定。

考虑一个简化的体系结构：

         Internet                
User ----------------> Service A +-------> Service B
      HTTP request               |
                                 +-------> Service C

假设用户通过令牌进行了身份验证。jwt或其他任何东西都不重要。

         Internet                
User ----------------> Service A +-------> Service B --------> SQL Database
      HTTP request               |
                                 +-------> Service C --------> Kafka Queue
                                                                    |
                                                                    |
                                           Service X <--------------+
                                           Service Y <--------------+
                                           Service Z <--------------+

传递JWT用户令牌不适用于不能在最终用户基础上工作的中间件。尤其是数据库和队列。

数据库不处理基于最终用户的访问（队列也有同样的问题）。它通常需要专用的用户名/密码或SSL证书进行访问，这两个证书在数据库实例之外都没有任何意义。对每个表的访问是完全的读/写或只读，不可能有精细权限（有行级权限的概念，但让我们忽略它）。

因此，服务B和服务C需要分别获得对SQL数据库和Kafka队列具有写权限的功能帐户。