微服务的API授权
我有一个多租户项目，它将调用多个微服务来执行特定任务。
我希望微服务从发送的请求中了解要使用哪个DB，因为每个租户都将使用微服务，但是，租户将拥有自己的DB。我有另一个解决方案，它有一个处理API密钥管理的Web项目。
比方说，API密钥管理位于域:portal.example.com
当 tenant.example.com 在 microservice.example.com 调用微服务时，我希望一些中间件侦听微服务端的请求并从请求中获取 APIKey，通过检查 portal.example.com 服务来验证它，如果 APIKey 有效，则获取此 API 密钥的租户并确定要用于微服务的连接字符串。
我觉得这不是很有效，因为它需要太多的调用来确定要使用的连接字符串，有人能想到更好的方法来确定连接字符串并验证APIKey吗？
共有1个答案
这个问题的本质似乎需要更多关于业务决策和架构决策的信息。
但是根据您到目前为止提供的信息，我想说您提到的连接字符串也可能是数据泄漏的问题。假设授权服务中存在发送错误连接字符串的错误，则可能会意外地将客户端连接到另一个数据库，而不是发出请求的实际客户端。第二点是，它还使授权服务成为单点故障。如果失败或恶意用户访问它，则所有租户都会受到影响。
与其让体系结构来处理这一点，有一点可能值得评估，那就是使用OAuth的客户端凭据来验证不同的应用程序；每个应用程序反映一组不同的数据库参数。在OAuth身份验证阶段，它会将用户重定向到正确的应用程序。总之，为每个租户部署了一组应用程序，租户通过OAuth进行身份验证。
另一种略有不同的方法是，使用一个租户各自的数据库凭证，为另一个租户部署和复制您为其使用的整个堆栈。只有当你受到开发资源的限制时，我才会提倡这样做。
-
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处，比如：负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是，我应该在网关层还是在每个微服务endpoint单独实现授权？例如，在网关上验证用户，并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的，并且节省了处理时间。然而，授权逻辑实际上是单个服务
-
让我们说，我正在开发博客平台，用户可以注册帐户，支付订阅和创建自己的博客。平台由以下微服务组成： 帐户-服务 auth-service 订阅-服务 博客-服务 API-网关 我正在考虑实现api-gw模式，其中除了api-gw之外的所有微服务都将部署到专用网络中（在那里，它们将能够通过message broker直接以同步或异步方式相互通信），并且它们将只通过api-gw公开可用。 null 我的
-
我有两个Spring启动应用程序。后端部分-可以访问数据库，它用作Rest API和管理面板。前端部分-使用Rest API为客户端显示信息。 因此，我对客户端（前端）的配置安全性有问题，对管理面板也有问题，授权是通过会话实现的。以前，客户端部分的授权是通过JWT令牌实现的，但我不太明白如何为每个客户端存储令牌，并在向Rest API发送请求时使用它。 这是我的安全配置： 那么，可以使用JWT令牌
-
我最近读了不少关于微服务的文章，尤其是关于AuthN和Authz的文章。在很大程度上，这一切都很有意义，我可以看到这一切应该如何工作。 （注意--现在我只实现了客户端凭据授予和资源所有者密码凭据授予，因为我只是想看看它是如何工作的，而且用curl调用它们更容易。但我不知道这有什么不同）
-
我决定第一次尝试实现微服务架构，而不是单一架构，并遇到了授权问题。在一个整体架构中，当访问挂有[Authorize]属性的控制器时，我只是在头中传递令牌，并对照当前的单个数据库检查它。但是在微服务架构中，每个微服务都有自己的数据库，你如何在访问其他微服务时检查令牌，我听说过API Gateway中的check的实现，但我认为，无论如何，每个微服务都应该有自己的check，因为，如果用户没有被授权，
-
我正在研究使用GMail API为我们的一个系统以编程方式发送电子邮件。我认为我需要创建一个服务帐户，然后将其设置为具有域范围的访问权限，以便授权发送电子邮件（因此电子邮件似乎来自实际用户，而不是我的程序）。我的问题是，如果我走这条路，有没有办法阻止某些用户，这样服务帐户就不能为他们“委派”？例如，我希望能够为我们的销售团队生成和发送电子邮件，但我不希望api能够为我们的高级管理人员生成任何电子邮