安全认证和微服务架构下的认证

目录

从单片应用程序体系结构到分布式应用程序体系结构再到微服务体系结构，对应用程序的安全访问不断进行测试. 为了适应架构的变化和需求的变化，身份认证和认证方案也在不断变化. 面对数十个甚至数百个微服务之间的调用，如何确保高效且安全的身份认证？面对外部服务访问，如何提供细粒度的身份验证解决方案？本文将解释微服务架构下的安全认证和认证方案.

随着微服务体系结构的兴起，身份认证和身份认证在传统的单个应用程序场景中的挑战日益增加. 在整体应用程序系统下，应用程序是一个整体，并且权限验证通常针对所有请求执行. 该请求通常由权限验证，并且在登录时将用户信息缓存在会话中，随后的访问将从缓存中获取用户信息.

在微服务架构下，一个应用程序将被拆分为多个微应用程序. 每个微应用程序都需要对访问进行身份验证，并且每个微应用程序都需要指定当前访问用户及其权限. 特别是当访问源不仅是浏览器，而且还包括其他服务的调用时，单片应用程序体系结构下的身份验证方法不是特别适合. 在服务体系结构下，必须考虑多种身份验证方案，例如外部应用程序访问方案，用户服务身份验证和服务服务身份验证.

David Borsos在伦敦微服务会议上提出了四种解决方案:

此方案意味着每个面向用户的服务都必须与身份验证服务交互，这将产生很多非常琐碎的网络流量和重复的工作. 当数十个微型应用程序经常使用时，该方案的缺点将更加明显.

分布式会话方案的原理主要是将有关用户身份验证的信息存储在共享存储中，以及通常通过使用用户会话作为密钥来实现的简单分布式哈希映射. 当用户访问微服务时，可以从共享存储中获取用户数据. 在某些情况下微服务之间调用安全，此解决方案非常好，用户登录状态不透明. 这也是一个高度可用且可扩展的解决方案. 该方案的缺点是共享存储需要某种保护机制，因此需要通过安全链接进行访问. 此时，解决方案的实现通常具有较高的复杂性.

令牌是在客户端上生成的，由身份验证服务签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份. 令牌将附加到每个请求，以提供微服务的用户身份验证. 该解决方案的安全性相对较好，但是身份验证注销是一个大问题. 减轻这种情况的方法可以使用短期令牌和经常检查认证服务等. 对于客户端令牌的编码方案，Borsos倾向于使用JSON Web令牌（JWT），它很简单并且库支持相对好.

此方案意味着所有请求都通过网关，从而有效地隐藏了微服务. 根据请求，网关会将原始用户令牌转换为内部会话ID令牌. 在这种情况下，注销不是问题，因为网关可以在注销时撤消用户的令牌.

HTTP基本身份验证（HTTP基本身份验证）是HTTP 1.0提出的身份验证机制. 这必须是每个人都熟悉的，因此我将不赘述. HTTP基本身份验证的过程如下:

客户端将HTTP请求发送到服务器.

由于请求中未包含Authorization标头，因此服务器将向客户端返回401 Unauthozied，并将信息添加到Response标头“ WWW-Authenticate”中.

客户端使用BASE64加密用户名和密码，并将其发送到授权标头中的服务器. 身份验证成功.

如果验证成功，服务器将使用授权标头中的用户名和密码进行验证

将根据请求将资源发送给客户端.

基于会话的身份验证应该是最常用的身份验证机制. 用户登录身份验证成功后，与用户相关的数据将存储在会话中. 在整体应用程序体系结构中，默认会话存储在应用程序服务器中，并且会话ID返回给客户端并存储在浏览器的Cookie中.

但是，在分布式体系结构中，会话存储在特定的应用服务器中，这自然无法使用. 通过会话复制或会话粘贴可以轻松解决此问题.

会话复制取决于应用程序服务器，这要求应用程序服务器具有会话复制功能，但是大多数应用程序服务器（例如Tomcat，JBoss和WebSphere）已经提供了此功能.

此外，会话复制的主要缺点是，当节点数相对较大时，大量的会话数据复制将占用更多的网络资源. 会话粘性是通过负载均衡器将统一的用户请求分发到固定服务器节点，以确保特定用户的会话数据始终正确. 但是，此解决方案取决于负载平衡器，只能满足水平扩展的群集方案，而不能满足应用程序分段后的分布式方案.

在微服务体系结构下，每个微服务拆分的粒度将非常好，不仅用户和微服务进行交互，而且微服务之间进行调用. 此时，以上两种方案均不能满足，这就要求必须将Session从应用服务器上剥离，并在外部存储以进行集中管理. 它可以是或分布式缓存微服务之间调用安全，例如Memchached，Redis等. 这正是David Borsos提出的第二种解决方案，即分布式会话解决方案.

随着Restful API和微服务的兴起，基于令牌的身份验证现在越来越普遍. 令牌和会话ID不同，而不仅仅是密钥. 令牌通常包含用户的相关信息，并且可以通过验证令牌来完成身份验证. Twitter，微信，QQ和GitHub等公共服务的API均基于此方法进行身份验证. 一些开发框架（例如OpenStack和Kubernetes内部API调用）也基于令牌认证. 基于令牌认证的典型过程如下:

基于令牌的身份验证的好处如下:

下面将重点介绍两种基于令牌的身份验证方案JWT / Oauth2.0.

JSON Web令牌（JWT）是基于JSON的开放标准（RFC 7519），用于在网络应用程序环境之间传递声明. JWT RFC 7519标准化的摘要: JSON Web令牌是一种紧凑的，URL安全的方式来表达要在双方之间传输的语句. JWT通常用于在身份提供者和服务提供者之间传递经过身份验证的用户身份信息，为了从资源服务器获取资源，还可以添加一些其他业务逻辑必需的附加声明信息，令牌也可以直接它用于身份验证，也可以加密.

JWT由三部分信息组成，第一部分是标题，第二部分是有效负载，第三部分是签名. 每个内容都是一个JSON对象. 每个JSON对象都使用BASE64进行编码，并使用编码后的内容. 该链接一起形成一个JWT字符串. 如下:

header.payload.signature

1. 标头

The

header用于描述有关JWT的最基本信息，例如其类型和用于签名的算法. 也可以将其表示为JSON对象.

标题表明签名算法是HS256算法.

2. 有效载荷

有效负载是存储有效信息的位置. 有效信息包括三个部分:

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-171242-1.html