Azure B2C微服务认证和GraphQL层
我们几乎没有UI使用的微服务。AzureB2C是我们的身份验证提供程序。每个微服务（API）都需要访问令牌，并且需要与数据库进行授权。此数据库具有基于角色的门禁权限。
今天的情况是这样的：
在这方面，我们有两个问题：
- 由于AzureB2C不允许将多个资源的作用域添加到一个访问令牌中，我们必须获得多个访问令牌。
- 我们现在处于这样一个阶段，用户界面需要调用两个或更多的API来在一个页面上显示数据。
我们希望使用GraphQL作为API网关。大概是这样的：
所有的微服务都放在一个专用的vnet中，只有GraphQLAPI才允许与它们对话。GraphQL层处理所有身份验证和授权。
现在的问题是：
- 你认为这种方法有什么问题吗
- 在GraphQL层和其他API之间使用客户端和secret进行通信可以吗？或者Azure B2C中是否有规定可以在不请求单独访问令牌的GraphQL层的情况下执行此验证
- 将Azure API管理添加到此应用程序中（除了日志记录、分析、速率限制等）还有哪些其他优势？我需要担心SSL终止吗
共有1个答案
选项2看起来是一个不错的架构。
一种常见的模式是UI调用专用的“入口点”API，然后它在专用网络中协调对微服务的调用，如第二张图所示。
- 例如一个在线销售UI只调用一个在线销售API
这也有助于将特定于UI的需求排除在微服务之外，并保持职责的整洁。
在OAuth术语中，正如您所说，将有一个单一的资源——切入点API——并且您应该只需要一个访问令牌。
然后，切入点API的令牌（或其声明）可以直接转发到微服务，并在需要时用于识别那里的用户。
我会避免为微服务获取额外的令牌，而只是根据用户数据库中的角色强制执行授权。
在某些情况下，强制执行诸如“不允许在线销售API调用Payroll microservice”之类的规则也是有意义的。
就我个人而言，我会使用与微服务相同的技术开发切入点API。
-
我想知道每种方法的利弊是什么。例如，在graphQL中包含所有内容似乎有点多余，因为我们将在每个服务中复制模式的部分。另一方面，我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗？我们都没有使用GraphQL的经验，所以这里是否有一些明显的利弊我们可能会遗漏？ 提前道谢！
-
我正在尝试设计一个JAAS微服务，它处理多个J2EE应用程序的用户身份验证。目前，我们有多个应用程序，它们根据LDAP进行身份验证，并具有独立的角色系统。现在我一直在设计应用程序和认证后端之间的接口。 通过自定义登录模块：设计一个自定义登录模块，使用我们登录服务中的非安全EJB接口进行身份验证和授权，但我记得读到登录模块不能注入EJB/使用EJB。 这是正确的起点，还是我有其他可能性从我们的应用程
-
我很难为微服务架构选择一个体面的/安全的身份验证策略。我在这个主题上找到的唯一的SO帖子是这样的：微服务架构中的单点登录 在这里，我的想法是在每个服务（例如身份验证、消息传递、通知、配置文件等）中都有一个对每个用户的唯一引用（从逻辑上讲，然后是他的)，并且如果登录，可以获得当前用户的。 从我的研究中，我看到有两种可能的策略： null
-
我最近读了不少关于微服务的文章，尤其是关于AuthN和Authz的文章。在很大程度上，这一切都很有意义，我可以看到这一切应该如何工作。 （注意--现在我只实现了客户端凭据授予和资源所有者密码凭据授予，因为我只是想看看它是如何工作的，而且用curl调用它们更容易。但我不知道这有什么不同）
-
帮助用户解决关于认证源、域、组、用户、项目、角色、权限等方面的问题。 认证服务包含哪些内容？ 主要包括认证源、域、组、用户、项目、角色、权限等方面内容。 如何调整域配额和项目配额？ 调整域配额 若用户是系统管理员，可直接在管理后台-系统配置-域中调整配额大小。 若用户是域管理员，若平台启用域配额申请工单流程后，可在控制面板处申请调整域配额大小，等待工单审批通过后，域配额将自动调整。 调整项目配额：
-
我将使用Laravel框架构建micrservices。我有用户微服务，它处理客户端凭证并验证它们(为客户端创建JWT)。此外，还有另一种需要用户认证的微服务。 问题是，如果秘密访问令牌密钥仅在用户微服务中，我如何验证客户端在微服务（用户微服务除外）中的访问令牌？或者，我应该在每个微服务中保留密钥吗？