当转向微服务时，可以得出结论，与专着应用程序相比，需要以不同的方式解决保护微服务的问题。在设计解决方案时，诸如“我在哪里以及如何实现身份验证和授权？”之类的问题。出现。和“如何授权用户执行特定操作？”可以弹出。在本文中，提出了解决这些问题的方法。首先，将解释认证和授权之间的区别。其次，将引入OpenIDConnect和OAuth2作为微服务架构集中认证授权的解决方案。最后，将解释授权的两个实现选项。身份验证和授权有什么区别？在谈论保护应用程序时，会弹出术语身份验证和授权。尽管这些术语可以互换使用，但它们代表了保护应用程序范围内的不同目的。在谈论身份验证时，它是验证他/她/声称的实体身份的过程。在谈论授权时，它是验证实体是否有权访问特定信息或执行某些操作的过程。关于整个安全过程，这两个原则都适用，并且组合仍然可以使请求失败。在规则上，认证在前，授权在后。当用户通过认证但未被授权时，请求仍然会失败。在微服务这样的分布式系统架构中，OpenIDConnect和OAuth无法通过传统方式实现身份验证和授权。使用单体方法，签名会话通常存储在内存中或分布式会话存储中，以在单体应用程序实例之间共享会话。由于微服务是单独隔离的应用程序，因此不可能共享不同应用程序的内存存储。不建议集中和共享分布式会话存储。这在微服务之间创建了紧密耦合，并为微服务之间的逻辑泄漏打开了大门。记住微服务架构，每个微服务都应该单独负责它的单一业务逻辑，无论它是小逻辑还是有限上下文。在这种情况下，身份验证是一个交叉问题，不应成为微服务本身的一部分。这个问题的一个广泛使用的解决方案是实现一个单独的身份服务器。该服务负责托管集中式身份验证和授权。有多种解决方案，例如WSO2IdentityServer(Java)、IdentityServer4(.NET)和OAuth2orize(Node.js)。所有这些框架都支持使用OpenIDConnect和OAuth2进行身份验证和授权。什么是OpenID连接？OpenIDConnect是一种身份验证协议，是OAuth2之上的简单身份层。它允许客户端身份验证通过外部授权服务器（例如Google、Facebook）或身份服务器中的嵌入式登录系统对用户进行身份验证。流程是什么样的？用户请求访问应用程序。应用程序确定用户未通过身份验证，并将用户重定向到身份服务器。用户向身份服务器进行身份验证。身份服务器在身份验证成功后向用户发送访问令牌/ID令牌。此令牌由加密密钥签名。用户可以使用此令牌在应用程序上进行身份验证。应用程序通过检查公共加密密钥以查看签名密钥是否由身份服务器签名来验证签名密钥。在这种情况下，用户已经成功认证！对于令牌，使用JSONWeb令牌(JWT)。JWT由header、payload和signature组成。标头包含用于签署令牌的算法。有效负载本质上是一个JSON对象，可以向其添加有关用户的其他属性。由于令牌由身份服务器签名，因此消费应用程序可以信任该信息。应用程序可以根据身份服务器用于签署令牌的证书的公钥来验证令牌。>用户、应用程序和身份服务器之间的高级流程什么是OAuth2？在解释OpenIDConnect时，术语OAuth2已被删除。OAuth2是一种行业标准授权协议。它为Web应用程序、桌面应用程序、移动电话和客厅设备提供特定的授权流程（在规范中称为授权）。OpenIDConnect解释中描述的流程实际上使用了一种受支持的授权类型，准确地说是授权代码授权类型。通过这个流程，用户被重定向到身份服务器，在那里处理身份验证和授权。客户端（请求用户信息的应用程序）获得用户对所需信息的授权。这是通过配置正确的范围来完成的。范围类似于特定客户端可以访问的数据类型。范围的示例是电子邮件和地址，它们分别类似于用户的电子邮件地址和地址。应用程序在身份验证过程中请求范围。当用户在身份服务器上对自己进行身份验证时，用户也可以为所请求的数据授予应用程序授权。一旦获得授权，数据就会被添加到令牌的有效负载中并传递给应用程序。在身份服务器中，可以保留与用户相关的角色。可以为公司所有员工设置身份服务器。这些员工根据他们在公司中的角色具有不同的角色。身份服务器可以将分配的角色共享给令牌中的特定用户。这样，它就可以与正在使用的应用程序共享。应在何处构建应用程序特定的授权逻辑？上一节已经提倡在单独的、集中负责的服务中构建身份验证的选项。对于特定于应用程序的授权逻辑，这变得更加困难。在微服务架构中，服务本身不应直接暴露给消费应用程序。管理与所有微服务的连接变得难以管理。实施API网关为消费者创建了一个单一的入口点进行通信。API网关将请求路由到上游微服务。>API网关与其他组件的关系当有多个消费者在消费时，创建一个特定的API网关可能是为每个消费者创建单独的特定端点的解决方案。这种变体被称为“前端后端”模式。这样，端点仅为每个消费者专门实施。这样做的缺点是它为每个需要维护的消费者添加了另一个单独的服务。在网关中处理特定于应用程序的授权处理特定于应用程序的授权的一种解决方案是在API网关中实现此功能。通过这种方式，可以限制对特定端点的请求。在APIGateway中实现授权的缺点是它只能是基于角色的端点访问。对特定域对象的访问实施额外的检查将需要在API网关内创建特定的域逻辑，因此会导致域逻辑泄漏。此外，在为前端/API网关引入多个后端时，管理授权变得越来越困难。在微服务中处理特定于应用程序的授权的更好解决方案是让微服务负责处理授权。API网关应该将JWT连同请求一起传递给微服务。如前所述，JWT将包含分配给用户的角色。由于API网关仍然负责身份验证，因此当微服务收到请求时，令牌的验证已经完成。通过为执行请求的用户分配角色，微服务现在可以确定用户是否有权执行所需的请求。这样，特定于应用程序的实现只需要在一个地方实现。这样做的一个缺点是授权将分布在多个服务中。当许多角色频繁变化时，管理起来会变得乏味。结论在微服务中实现身份验证和授权时，这个过程比传统的单体架构要复杂得多。尽管身份验证和授权都是保护应用程序的术语，但它们涵盖的范围不同。身份验证是关于验证实体声称是谁。授权是确定是否允许实体执行特定操作或访问特定数据的过程。微服务架构中对应用程序的身份验证和授权通常在负责此的集中式服务中实现。有多种解决方案，例如WSO2IdentityServer(Java)、IdentityServer4(.NET)和OAuth2orize(Node.js)。这些服务支持OAuth2和OpenIDConnect，它们是用于授权和身份验证的底层行业标准协议。实施身份验证检查应该在API网关内部终止。授权可以在API网关或微服务中实现。为了启用广泛的特定于应用程序的授权检查，授权应该在特定的微服务中处理。这可以通过将JWT与请求一起传递来完成。这样，域对象的特定于应用程序的授权不会泄漏到API网关。
