一种基于微服务架构的统一认证授权方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种基于微服务架构的统一认证授权方法及装置。

背景技术

目前大型的单体系统都逐步改造成为微服务架构，每个系统都存在多个微服务，当有外部请求要访问后端微服务时，需要对请求进行安全认证。

目前，现有的微服务认证授权的技术方案都是在API网关完成，下游的微服务不需要进行认证授权。网关接收到客户端请求所携带的认证令牌后，对该认证令牌进行解密和校验，然后将解密出来的用户信息转发给下游微服务。采用这样的方案的话，一旦API网关被攻破或者通过某些方式越过网关访问微服务，会导致网络安全性降低。

因此，如何提高网络安全性成为了急需解决的问题。

发明内容

有鉴于此，本申请的主要目的在于提供一种基于微服务架构的统一认证授权方法，以提高网络安全性。

本申请第一方面提供了一种基于微服务架构的统一认证授权方法，该方法应用于认证授权系统，该认证授权系统包括网关、统一认证授权中心以及微服务，该方法包括：

网关接收客户端发送的登录请求；

网关判断登录请求是否携带认证令牌，如果登录请求携带认证令牌，则将登录请求发送至微服务；如果登录请求未携带认证令牌，则将登录请求发送至统一认证授权中心；

统一认证授权中心接收登录请求，对登录请求进行身份认证；

当登录请求通过身份认证时，统一认证授权中心向网关发送认证令牌，以便网关将认证令牌转发至客户端。

在本申请第一方面的一些实现方式中，该方法还包括：

微服务接收登录请求，并将认证令牌进行反编码，以得到客户端的用户账号；

微服务在本地缓存中查找客户端的用户账号对应的公钥；

微服务利用公钥和认证令牌生成签名，并对签名进行验签以生成验签结果。

在本申请第一方面的一些实现方式中，该方法还包括：

当验签结果为通过时，微服务根据用户账号在本地缓存中查找客户端的用户账号对应的第一资源标识符。

在本申请第一方面的一些实现方式中，该方法还包括：

微服务从登录请求中解析出第二资源标识符；

微服务对第一资源标识符与第二资源标识符进行比对，并生成比对结果；

如果对比的结果为相等，则微服务向客户端发送登录成功消息。

在本申请第一方面的一些实现方式中，该方法还包括：

微服务判断本地缓存中是否包含客户端的用户账号对应的公钥；

如果本地缓存中未包含客户端的用户账号对应的公钥，则微服务向统一认证授权中心发送公钥分配请求；

统一认证授权中心接收公钥分配请求，为客户端的用户账号分配公钥，并将公钥发送至微服务；

微服务接收公钥，并将公钥写入本地缓存中。

在本申请第一方面的一些实现方式中，该方法还包括：

微服务判断本地缓存中是否包含客户端的用户账号对应的第一资源标识符；

如果本地缓存中未包含客户端的用户账号对应的第一资源标识符，则微服务向统一认证授权中心发送资源标识符分配请求；

统一认证授权中心接收资源标识符分配请求，为客户端的用户账号分配第一资源标识符，并将第一资源标识符发送至微服务；

微服务接收第一资源标识符，并将第一资源标识符写入本地缓存中。

本申请第二方面提供了一种认证授权系统，该认证授权系统包括网关、统一认证授权中心以及微服务；

网关，用于接收客户端发送的登录请求；

网关，还用于判断登录请求是否携带认证令牌，如果登录请求携带认证令牌，则将登录请求发送至微服务，如果登录请求未携带认证令牌，则将登录请求发送至统一认证授权中心；

统一认证授权中心，用于接收登录请求，对登录请求进行身份认证；

统一认证授权中心，还用于当登录请求通过身份认证时，统一认证授权中心向网关发送认证令牌，以便网关将认证令牌转发至客户端。

在本申请第二方面的一些实现方式中；

微服务，用于接收登录请求，并将认证令牌进行反编码，以得到客户端的用户账号；

微服务，还用于在本地缓存中查找客户端的用户账号对应的公钥；

微服务，还用于利用公钥和认证令牌生成签名，并对签名进行验签以生成验签结果。

在本申请第二方面的一些实现方式中；

微服务，还用于当验签结果为通过时，微服务根据用户账号在本地缓存中查找客户端的用户账号对应的第一资源标识符。

本申请第三方面提供了一种电子设备，该电子设备包括至少一个处理器、以及与处理器连接的至少一个存储器、总线；其中，处理器、存储器通过总线完成相互间的通信；处理器用于调用存储器中的程序指令，以执行如本申请第一方面中的基于微服务架构的统一认证授权方法。

相对于现有技术，本申请所提供的技术方案具有如下有益效果：

本申请通过网关接收客户端发送的登录请求；网关判断登录请求是否携带认证令牌，如果登录请求携带认证令牌，则将登录请求发送至微服务；如果登录请求未携带认证令牌，则将登录请求发送至统一认证授权中心；统一认证授权中心接收登录请求，对登录请求进行身份认证；当登录请求通过身份认证时，统一认证授权中心向网关发送认证令牌，以便网关将认证令牌转发至客户端；从而让网关在整个认证授权的流程中，无需进行认证授权以及认证令牌的解密与解析，在一定程度上解耦了认证授权业务，从而避免了由于网关遭到攻击而导致网络安全性降低的问题，因此提高了网络安全性。

附图说明

图1为本申请实施例提供的一种基于微服务架构的统一认证授权方法的流程示意图；

图2为本申请实施例提供的另一种基于微服务架构的统一认证授权方法的流程示意图；

图3为本申请实施例提供的另一种基于微服务架构的统一认证授权方法的流程示意图；

图4为本申请实施例提供的另一种基于微服务架构的统一认证授权方法的流程示意图；

图5为本申请实施例提供的一种认证授权系统的逻辑判断图；

图6为本申请实施例提供的一种认证授权系统的示意图；

图7为本申请实施例提供的一种电力设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

向相关术语进行如下解释：

微服务：是指将一个大的应用拆分出多个独立的模块，每个模块就叫做微服务。微服务的关键是一种系统架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。

JWT：英文全程为Jsonwebtoken,是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

API网关：API网关是系统的唯一入口，它封装了系统内部架构，为每个客户端提供一个定制的API。它还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。

现有技术中由API网关来进行微服务的认证与授权，采用这样的认证与授权方式，由API网关进行认证与授权后，下游的微服务不再需要进行认证与授权，一旦API网关被击破或者攻击者越过API网关访问微服务，便会产生网络安全问题，因此，本申请提出了一种基于微服务架构的统一认证授权方法，让API网关只执行转发任务，认证与授权的工作交由统一认证授权中心执行，相较于现有技术而言提高了网络安全性。

请参阅图1，本申请实施例提供了一种基于微服务架构的统一认证授权方法，该方法应用于认证授权系统，该认证授权系统包括网关、统一认证授权中心以及微服务，该方法包括以下步骤：

S101：网关接收客户端发送的登录请求。

在本申请的实施例中，网关又可以称为API网关或微服务网关，是客户端访问认证授权系统的唯一入口，客户端发送的请求都需要先经过网关，是本申请提高网络安全性的第一道保护屏障。

S102：网关判断登录请求是否携带认证令牌，如果登录请求携带认证令牌，则将登录请求发送至微服务；如果登录请求未携带认证令牌，则将登录请求发送至统一认证授权中心。

认证令牌可以是JWT，需要说明的是，采用其他的认证令牌均不影响本申请实施例的实现。

该步骤中，网关的作用在于进行登录请求的判断与转发，当客户端发送的登录请求未携带认证令牌时，说明该客户端未完成系统的认证，需要将其转发至统一认证授权中心进行认证；当客户端发送的登录请求携带认证令牌时，说明该客户端已经通过的系统的认证，将其转发至相应的微服务，以实现后续客户端调用微服务。

S103：统一认证授权中心接收登录请求，对登录请求进行身份认证。

在本申请的实施例中，网关不再进行认证令牌的认证，而是交由统一认证授权中心来完成，采用这样的工作方式，即使网关被攻击导致，越过网关访问微服务的客户端在没有认证令牌的情况下也无法调用或者访问微服务，是本申请提高网络安全性的第二道保护屏障。

S104：当登录请求通过身份认证时，统一认证授权中心向网关发送认证令牌，以便网关将认证令牌转发至客户端。

统一认证授权中心对登录请求进行身份认证后，会为客户端颁发认证令牌，该认证令牌经过网关的转发后发送的客户端，客户端在接收到认证令牌后，便可以通过网关的验证，以进行调用微服务的后续步骤。

在图1所示的流程中，通过统一认证授权中心实现对客户端的认证与授权，避免了采用网关进行认证与授权而导致的潜在的网络安全风险，采用了两道网络保护屏障的保护模式，对认证授权的业务进一步解耦合，在脱离了网关对网络的保护的情况下，越过网关的客户端也无法访问微服务，从而提高了网络安全性。

参见图2所示，由于现有技术中，微服务可以被越过网关的客户端所访问，因此也会产生危害网络安全的问题，为了进一步提高网络安全性，本申请在图1所示的流程的基础上，进一步增加了微服务对认证令牌进行解密与解析的步骤，具体包括以下步骤：

S201：微服务接收登录请求，并将认证令牌进行反编码，以得到客户端的用户账号。

该登录请求可以理解为客户端申请调用微服务的请求，在本申请的实施例中，微服务在接收到来自客户端的登录请求后，并不会允许客户端直接调用微服务，而是对认证令牌进行解密与解析的步骤以判断客户端是否有调用微服务的权限，从而进一步提高网络安全性，是本申请的实施例实现提高网络安全性的第三道保护屏障。

对认证令牌进行反编码的目的在于从认证令牌中解析出客户端的用户账号，反编码的方式可以采用Base64反编码技术，也可以采用其他的反编码技术，均不影响本申请实施例的实现。

S202：微服务在本地缓存中查找客户端的用户账号对应的公钥。

本地缓存可以是认证授权系统在本地的物理内存中划分出来的用于缓冲解密与解析时产生的数据，可以用于降低认证授权系统的网络负载压力；公钥可以指的是可公开的密钥，用于对认证令牌进行签名验证。

S203：微服务利用公钥和认证令牌生成签名，并对签名进行验签以生成验签结果。

在获取到客户端的用户账号对应的公钥之后，可以根据公钥生成认证令牌的签名。验签也可以称为签名验证，对签名验签后的验签结果可以是通过与不通过，采用其他方式对验签结果进行描述并不影响本申请实施例的实现。

S204：当验签结果为通过时，微服务根据用户账号在本地缓存中查找客户端的用户账号对应的第一资源标识符。

资源标识符又称为统一资源标识符或者统一资源标志符(UniformResourceIdentifier，URI)，URI可以用来唯一的标识一个资源的信息。

S205：微服务从登录请求中解析出第二资源标识符。

微服务通过对登录请求的解析，可以获取到第二资源标识符，该第二资源标识符用于作为第一资源标识符的比对对象。

S206：微服务对第一资源标识符与第二资源标识符进行比对，并生成比对结果。

在该步骤中，比对结果可以用于作为判断客户端是否有权限访问微服务的依据，当比对结果为通过时，则可以说明客户端具备访问第一资源标识符的权限。

S207：如果对比的结果为相等，则微服务向客户端发送登录成功消息。

在该步骤中，当第一资源标识符与第二资源标识符相等时，则可以说明对比结果为通过，微服务向客户端发送登录成功消息，该登录成功消息可以向客户端说明该客户端已经允许访问微服务。

在图2所示的流程中，为了进一步提高网络安全性，进一步增加了微服务对认证令牌进行解密与解析的步骤，客户端每次进行登录请求都需要携带认证令牌，并且微服务都需要对认证令牌进行解密与解析，以确定用户的登录态，从而实现了将微服务作为第三道网络保护屏障，进一步提高了网络安全性，保证了系统的安全性和稳定性。

参见图3所示，为了避免由于无法在本地缓存中查找到客户端的用户账号对应的公钥，而导致微服务无法完成认证令牌的解析，本申请的实施例在图2所示的流程的基础上，进一步增加分配公钥的步骤：

S301：微服务判断本地缓存中是否包含客户端的用户账号对应的公钥。

微服务进行判断的目的在于避免后续流程出现错误而导致无法对生成认证令牌的签名。

S302：如果本地缓存中未包含客户端的用户账号对应的公钥，则微服务向统一认证授权中心发送公钥分配请求。

在本申请的实施例中，统一认证授权中心具备分配公钥的功能，在微服务无法从本地缓存中查找到用户账号对应的公钥时，可以在接收微服务发送的公钥分配请求后，为相应的客户端的用户账号分配公钥。

S303：统一认证授权中心接收公钥分配请求，为客户端的用户账号分配公钥，并将公钥发送至微服务。

为客户端的用户账号分配公钥是为了后续微服务可以从本地缓存中查找到客户端的用户账号对应的公钥。

该步骤可以理解为是统一认证授权中心对本地缓存的公钥的进行更新，本地缓存中可能存在已经调用微服务的其他客户端的用户账号对应的其他公钥，这些其他公钥是属于暂时不用的，更新本地缓存的公钥可以进一步释放本地缓存。

S304：微服务接收公钥，并将公钥写入本地缓存中。

将公钥写入本地缓存的目的在于避免由于微服务无法从本地缓存中查找到客户端的用户账号对应的公钥而导致解析失败的情况发生。

在图3所示的流程中，通过微服务在判断本地缓存中未包含客户端的用户账号对应的公钥之后，向统一认证授权中心请求为客户端的用户账号分配公钥，从而避免了微服务无法完成认证令牌的解析。

参见图4所示，为了进一步避免由于无法在本地缓存中查找到客户端的用户账号对应的第一资源标识符，从而导致原本有权限访问微服务的客户端无法访问微服务，本申请的实施例在图2所示的流程的基础上，进一步增加分配第一资源标识符的步骤：

S401：微服务判断本地缓存中是否包含客户端的用户账号对应的第一资源标识符。

第一资源标识符可以是微服务的访问资源标识符，通过第一资源标识符可以访问微服务；微服务进行判断的目的在于避免后续流程出现错误而导致无法根据第一资源标识符进行后续的比对步骤。

S402：如果本地缓存中未包含客户端的用户账号对应的第一资源标识符，则微服务向统一认证授权中心发送资源标识符分配请求。

本地缓存中未包含第一资源标识符，即微服务无法从本地缓存中查找到第一资源标识符

在本申请的实施例中，统一认证授权中心具备分配公资源标识符功能，本地缓存中不包含第一资源标识符时，可以在接收微服务发送的公钥分配请求后，为相应的客户端的用户账号分配公钥。

S403：统一认证授权中心接收资源标识符分配请求，为客户端的用户账号分配第一资源标识符，并将第一资源标识符发送至微服务。

为客户端的用户账号分配第一资源标识符是为了后续微服务可以在本地缓存中查找到客户端的用户账号对应的第一资源标识符。

S404：微服务接收第一资源标识符，并将第一资源标识符写入本地缓存中。

将第一资源标识符写入本地缓存是为了避免由于无法在本地缓存中查找到客户端的用户账号对应的第一资源标识符，从而导致原本是有权限访问微服务的客户端无法访问微服务的情况发生。

在图4所示的流程中，通过微服务在判断本地缓存中未包含客户端的用户账号对应的第一资源标识符之后，向统一认证授权中心请求为客户端的用户账号分配第一资源标识符，从而避免了原本有权限访问微服务的客户端无法对微服务进行访问。

请参见图5所示，在具体应用场景中，认证授权系统的具体执行步骤可以包括以下步骤：

S501：接收客户端的登录请求；执行步骤S502。

S502：判断登录请求中的JWT是否为空，如果JWT为空，执行步骤S512，如果JWT非空，执行步骤S503。

该步骤用于判断客户端发送的登录请求是否携带JWT。

S503：根据JWT获取用户账号以及公钥；执行步骤S504。

具体地，利用Base64反编码从JWT中解析出客户端的用户账号，并根据用户账号在本地缓存中查找对应的公钥。

S504：判断公钥是否为空，如果公钥为空，则执行步骤S505；如果公钥非空，则执行步骤S507。

该步骤用于判断是否本地缓存中不存在用户账号对应的公钥。

S505：更新本地缓存中的公钥，执行步骤S506。

更新本地缓存中的公钥的过程，可以理解为用户账号生成对应的公钥，并写入本地缓存中的过程。

S506：判断公钥是否为空，如果公钥为空，则执行步骤S512，如果公钥非空，则执行步骤S507。

S507：判断JWT是否通过校验，如果JWT未通过校验，则执行步骤S512；如果JWT通过校验，则执行步骤S508。

具体地，校验的过程可以是，利用用户账号对应的公钥生成JWT的签名，并对JWT的签名进行签名验证。

S508：判断本地缓存中是否存在用户账号对应的URI，如果不存在用户账号对应的URI，则执行步骤S509；如果存在用户账号对应的URI，则执行步骤S511。

S509：更新本地缓存中的URI，执行步骤S510。

该步骤中，更新本地缓存中的URI的过程可以理解为根据用户账号生成对应的URI，并写入本地缓存中的过程。

S510：判断本地缓存中是否存在用户账号对应的URI，如果不存在，则执行步骤S512；如果存在，则执行步骤S511。

S511：通过客户端的登录请求。

客户端即微服务的调用方，通过客户端的登录请求之后，客户端可以携带JWT访问微服务。

S512：向客户端发送错误信息。

其中，错误信息可以是401错误代码。

参见图6所示，本申请的实施例提供了一种认证授权系统，包括网关601、统一认证授权中心602以及微服务603。

网关，用于接收客户端发送的登录请求；

网关，还用于判断登录请求是否携带认证令牌，如果登录请求携带认证令牌，则将登录请求发送至微服务；如果登录请求未携带认证令牌，则将登录请求发送至统一认证授权中心；

统一认证授权中心，用于接收登录请求，对登录请求进行身份认证；

统一认证授权中心，还用于当登录请求通过身份认证时，统一认证授权中心向网关发送认证令牌，以便网关将认证令牌转发至客户端。

在本申请实施例的一些实现方式中，微服务，用于接收登录请求，并将认证令牌进行反编码，以得到客户端的用户账号；

微服务，还用于在本地缓存中查找客户端的用户账号对应的公钥；

微服务，还用于利用公钥和认证令牌生成签名，并对签名进行验签以生成验签结果。

在本申请实施例的一些实现方式中，微服务还用于，当验签结果为通过时，微服务根据用户账号在本地缓存中查找客户端的用户账号对应的第一资源标识符。

在本申请实施例的一些实现方式中，微服务，还用于从登录请求中解析出第二资源标识符；

微服务，还用于对第一资源标识符与第二资源标识符进行比对，并生成比对结果；

微服务，还用于如果对比的结果为相等，则微服务向客户端发送登录成功消息。

在本申请实施例的一些实现方式中，微服务，还用于判断本地缓存中是否包含客户端的用户账号对应的公钥；

微服务，还用于如果本地缓存中未包含客户端的用户账号对应的公钥，则微服务向统一认证授权中心发送公钥分配请求；

统一认证授权中心，还用于接收公钥分配请求，为客户端的用户账号分配公钥，并将公钥发送至微服务；

微服务，还用于接收公钥，并将公钥写入本地缓存中。

在本申请实施例的一些实现方式中，微服务，还用于判断本地缓存中是否包含客户端的用户账号对应的第一资源标识符；

微服务，还用于如果本地缓存中未包含客户端的用户账号对应的第一资源标识符，则微服务向统一认证授权中心发送资源标识符分配请求；

统一认证授权中心，还用于接收资源标识符分配请求，为客户端的用户账号分配第一资源标识符，并将第一资源标识符发送至微服务；

微服务，还用于接收第一资源标识符，并将第一资源标识符写入本地缓存中。

参见图7所示，本申请还提供了一种电子设备70，该电子设备70包括至少一个处理器701、以及与处理器701连接的至少一个存储器702、总线703；其中，处理器701、存储器702通过总线703完成相互间的通信；处理器701用于调用存储器702中的程序指令，以实现上述如图1至图4中描述的一种基于微服务架构的统一认证授权方法。

最后，还需要说明的是，在本申请实施例中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。