CN112818325A - 一种基于应用实现api网关独立鉴权的方法 - Google Patents

Abstract

本发明公开了一种基于应用实现API网关独立鉴权的方法，所述方法通过使用kong插件实现原生API访问权限控制；所述kong插件为APP鉴权插件；所述方法的实现包括：创建API，创建时选择APP认证；发布API，在发布时将所述APP鉴权插件配置写入API网关；API网关控制台前端页面根据用户需要创建APP应用，作为用户调用API的身份。本发明基于APP应用实现独立鉴权，授权数据保存到redis中，当接收到客户端请求时kong网关首先从redis缓存中获取鉴权数据，相比于其他鉴权方式，处理速度更快；授权关系持久化到后端数据库中，后端提供备用鉴权接口，有效保证API的安全稳定调用。

Description

一种基于应用实现API网关独立鉴权的方法

技术领域

本发明涉及计算机网络认证鉴权技术领域，具体提供一种基于应用实现API网关独立鉴权的方法。

背景技术

API网关作为对外提供服务的入口，就像企业服务的大门，一方面，要有足够的能力应对大量的对外访问，另一方面，还要给对内的服务提供一定的安全保障。

当并发量较大时很有可能超出网关承受能力，轻则导致服务抛弃一部分请求，重则导致服务器资源耗尽，不可用；另外恶意请求容易入侵服务器，对内部服务造成安全隐患。

网络服务通常包括客户端和服务端，通过API(ApplicationProgrammingInterface，应用程序编程接口)网关统一接收客户端或者外部合作伙伴等调用方的请求，并根据各个接口不同的逻辑，进行一定的校验和逻辑处理，再转发给后端服务方。显然，API网关是网络服务中承接客户端和后端服务的中间桥梁，作为对外提供服务的入口，就像企业服务的大门。一方面，要有足够的能力，应对大量的对外访问，另一方面，还要给对内的服务提供一定的安全保障。

随着网络的发展和普及，对于API网关的性能要求越来越高，数据访问、交换过程中单纯的基于内存数据库做缓存，已经无法满足高性能的要求。

相比于其他鉴权方式，处理速度更快；授权关系持久化到后端数据库中，后端提供备用鉴权接口，有效保证API的安全稳定调用。

发明内容

本发明为了解决上述问题，提供一种基于应用实现API网关独立鉴权的方法。在数据安全的前提下，调用网关托管的API只需传递少量参数，有效缩短鉴权所需时间，保证API执行效率，简单高效地实现基于app_key和app_secret应用的API访问独立鉴权功能。

为实现上述目的，本发明提供了如下技术方案：

一种基于应用实现API网关独立鉴权的方法，所述方法通过使用kong插件和redis缓存实现原生API访问权限控制；

所述kong插件为APP鉴权插件；

所述方法的实现包括：

创建API，创建时选择APP认证；

发布API，在发布时将所述APP鉴权插件配置写入API网关；

API网关控制台前端页面根据用户需要创建APP应用，作为用户调用API的身份。

所述kong插件通过Lua代码实现，使用Redis作为缓存数据库；

所述API网关提供前端签名及验签功能；

提供了验证客户端合法性的功能，用户调用API时只有使用正确秘钥发起的访问能够通过API网关的校验，不携带秘钥或携带错误的秘钥不能通过API网关的鉴权。

当前端页面接收到用户调用API时携带的认证信息，网关层执行APP认证逻辑：

如果签名认证通过，则请求成功；

如果签名认证失败，则请求失败。

所述APP应用包括一对AppKey和AppSecret密钥对，其中：

AppKey：用于标识所使用的的是哪个密钥对，参与签名，在请求时作为参数在Header或Query中传入；

AppSecret密钥：用于签名计算，用于计算请求签名。请求时不带该参数。

用户调用API时必须携带授权应用的Key和签名秘钥，不携带秘钥或携带错误的秘钥不能通过API网关的鉴权。

所述AppKey和AppSecret密钥对在API网关创建APP时由系统自动分配，并具备该APP的全部权限，需要妥善保管；当API进行APP授权操作时，API网关控制台后端会将所选择的APP中有效的AppKey和AppSecret与API的路由名称绑定关系，持久化保存并缓存到Redis中。

用户在请求API时，需要用到密钥。如果发生泄漏，可以在API网关的控制台前端页面进行重置。

所述API网关的控制台前端页面可根据用户需要创建多个APP应用，每个APP应用根据业务需求分别被不同的API授权。

所述签名在一定时间内有效，过期需重新生成签名，从而实现在携带最少参数的情况下保证API的安全调用。

所述方法实现流程包括：

所述APP应用被API授权后，用户可使用app_key、app_secret和签名SDK生成签名秘钥；

API网关控制台接收到调用API指令时，将app_key和签名放到请求header中；

API网关控制台根据app_key去查询对应的secret；

根据获取到的app_key/app_secret计算签名；

比对从请求header中获取的签名与API网关计算的签名是否相等，如果相等，认证通过，否则认证失败。

所述方法redis缓存的调用过程包括内容如下：

1)API网关控制台从redis缓存中查找是否有需要的app信息，如果有就返回，否则进行下一步查找；

2)通过调用API管理后端提供的接口查找需要的app信息，如果查到结果，更新redis缓存；

3)如果通过后端接口没有查到app信息，则更新redis缓存对应的key的一个空值，防止发起对后端的无效请求，同时设置一个较短的过期时间，防止如果后端数据更新后不生效。

所述签名构造过程包括：

构造签名内容：auth_app_key＝[app_key]&auth_time＝[auth_time]，app_key和auth_time参与签名，auth_time为当前UTC时间戳；

将所述签名内容通过base64_safe(HMAC-SHA1(app_secret,sign_str))计算生成sign，使用url安全的base64签名。

所述APP认证的参数传递包括两种方式：通过header传参和通过query传参；

如果通过header传参，则header中传入参数包括：

X-Auth-App-Key，创建应用时的app_key；

X-Auth-time，UTC时间单位为秒的时间戳；

X-Auth-Sign，计算得到的签名；

如果通过query传参，则query中携带如下参数：

auth_app_key，创建应用时的app_key；

auth_time，UTC时间单位为秒的时间戳；

auth_sign，计算得到的签名。

Kong是一款基于Nginx_Lua模块写的高可用，易扩展由Mashape公司开源的APIGateway项目。由于Kong是基于Nginx的，所以可以水平扩展多个Kong服务器，通过前置的负载均衡配置把请求均匀地分发到各个Server，来应对大批量的网络请求。

Kong采用插件机制进行功能定制，插件集(可以是0或n个)在API请求响应循环的生命周期中被执行。插件使用Lua编写，目前已有几个基础功能：HTTP基本认证、密钥认证、CORS(Cross-origin Resource Sharing，跨域资源共享)、TCP、UDP、文件日志、API请求限流、请求转发以及nginx监控。

Redis是现在最受欢迎的NoSQL数据库之一，Redis是一个使用ANSI C编写的开源、包含多种数据结构、支持网络、基于内存、可选持久性的键值对存储数据库，其具备如下特性：

基于内存运行，性能高效；

支持分布式，理论上可以无限扩展；

key-value存储系统；

开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API；

相比于其他数据库类型，Redis具备的特点是：

C/S通讯模型；

单进程单线程模型；

丰富的数据类型；

操作具有原子性；

持久化；

高并发读写；

支持lua脚本；

加入kong后，每个客户端对API的请求将首先到达Kong，然后被代理到最终API，在请求和响应之间，Kong将执行任何已安装的插件，扩展API功能集，Kong有效的成为每个API的入口点。

与现有技术相比，本发明一种基于应用实现API网关独立鉴权的方法具有以下突出的有益效果：

本发明基于APP应用实现独立鉴权，授权数据保存到redis中，当接收到客户端请求时kong网关首先从redis缓存中获取鉴权数据，相比于其他鉴权方式，处理速度更快；授权关系持久化到后端数据库中，后端提供备用鉴权接口，有效保证API的安全稳定调用；API对应用的批量授权可更安全的开放对外服务能力，保障授权有效期内API的安全调用。

附图说明

图1是所述方法实现流程示意图；

图2是Kong与Redis交互示意图。

具体实施方式

下面将结合附图和实施例，对本发明作进一步详细说明。

一种基于应用实现API网关独立鉴权的方法，所述方法通过Lua代码实现Kong的APP认证插件功能，Redis作为缓存数据库。当用户携带认证信息调用API时网关层会执行APP认证逻辑，签名认证通过，则请求成功，签名认证失败，请求失败。

用户在控制台页面创建APP应用作为调用API的身份，每个APP应用有一对AppKey和AppSecret密钥对，AppKey需要在请求时作为参数在Header或Query中传入，AppSecret需要用于计算请求签名。

在API网关创建APP时，系统会自动分配一对AppKey和AppSecret。在用户请求API时，需要用到密钥。AppKey和AppSecret密钥对具备该APP的全部权限，需要妥善保管。如果发生泄漏，可以在API网关的控制台进行重置。

API的授权对象是APP。系统可以创建多个APP，可以根据业务需求分别被不同的API授权。

用户可以在API网关控制台完成对APP的创建、修改、删除、查看详情、密钥管理、查看已授权等管理操作。

当用户对API进行APP授权操作时，控制台后端会将所选择的APP中有效的AppKey和AppSecret与API的路由名称绑定关系持久化保存并缓存到Redis中。

所述缓存格式如下：

使用hash格式存储应用和API授权关系

安全：

考虑到缓存击穿和缓存雪崩，每个授权关系key失效时间随机设置。

所述插件的配置如下：

所述API控制台提供备用鉴权接口，，有效保证API的安全稳定调用，具体包括内容如下：

Redis中的鉴权数据不是持久化保存的，在随机有效期内有效，失效后Kong将携带token调用API管理后端接口获取鉴权数据。

请求方式：GET

请求地址：/xxxxx

鉴权：采用简单鉴权方式，配置文件中存入随机生成的token，发起请求时写在header中

请求参数：

header:

X-Token:xxxxxxxxxxxxxxx

query：app_key:xxxx

请求响应：

成功：{"code":"0",data:{"app_id":"xxxxxxxxxxxxxx","app_key":"xxxxxxxxxxxxxxx","app_secret":"xxxxxxxxxxxxxxx","app_name":"应用名称","expired_at":"[过期时间]"}}

所述方法实现签名认证过程如下：

API网关服务会对APP认证的API请求进行身份验证，所以无论使用HTTP还是HTTPS协议提交请求，都需要在请求中包含签名(Signature)信息。

发布的API如果使用APP认证方式，客户端在调用API时，需要使用签名秘钥生成签名。API网关提供的SDK内置了签名实现，只需要将签名秘钥配置在SDK中，即可得到调用API时所需的请求头签名参数。

API网关提供前端签名及验签能力，前端签名及验签主要两点用途：

1.验证客户端请求的合法性，确认请求中携带授权后的AK生成的签名；

2.防止请求数据在网络传输过程中被篡改。

API的拥有者可以在API网关控制台应用管理页面生成APP，每个APP会携带一对签名秘钥(APPKey和APPSecret),API拥有者将API授权给指定的APP(APP可以是API拥有者颁发或者API调用者所有)后，API调用者就可以用APP的签名秘钥来调用相关的API了。

客户端调用API时，需要使用已授权APP的AppKey和AppSecret生成签名，并且将APP Key和加密后生成的字符串放在请求的Header传输给API网关，API网关会读取请求中的APP Key的头信息，并且根据APP Key的值查询到对应的APP Secret的值，使用APPSecret对收到的请求中的关键数据进行签名计算，并且使用自己的生成的签名和客户端传上来的签名进行比对，来验证签名的正确性。只有签名验证通过的请求才会请求上游服务，否则API网关会认为该请求为非法请求，直接返回错误应答。

所述方法生成签名过程如下：

以下是生成签名的SDK源码，只需将AppKey和AppSecret作为参数调用AppSign方法，即可返回调用API所需要的请求头签名信息：

所述签名传输过程如下：

客户端需要将以下三个参数放在HTTP请求中传输给API网关，进行签名校验：

x-auth-app-key：创建应用(APP)时的app_key

x-auth-time： UTC时间秒为单位的时间戳

x-auth-sign： 计算得到的签名

所述方法调用API支持两种携带参数的方式包括：通过header传参和通过query传参。

如果通过header传参，则header中传入如下参数

X-Auth-App-Key：创建应用时的app_key

X-Auth-time： UTC时间秒为单位的时间戳

X-Auth-Sign： 计算得到的签名

如果通过query传参，则query中携带如下参数

auth_app_key：创建应用时的app_key

auth_time： UTC时间秒为单位的时间戳

auth_sign： 计算得到的签名

所述header传参请求示例：

所述query传参的请求示例：

http://demo.com？auth_app_key＝xxxxxx&auth_time＝1599270802&auth_sign＝xxxxxxxxxxx

返回码说明：

如图1所示，所述方法实现的流程如下：

1.网关接收到用户请求

2.在请求header中添加app_key，sign等认证信息

3.根据app_key去查询对应的app_secret

4.根据获取到的app_key/app_secret等信息计算签名

5.比对从请求中获取的签名与网关自己计算的签名是否相等，如果相等，认证通过，否则认证失败。

如图2所示，所述Kong与Redis交互过程包括内容如下：授权数据保存到redis中，当接收到客户端请求时，kong网关首先从redis缓存中获取鉴权数据；授权关系持久化到后端数据库中，后端提供备用鉴权接口，有效保证API的安全稳定调用。

以上所述的实施例，只是本发明较优选的具体实施方式，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。

Claims (10)

1.一种基于应用实现API网关独立鉴权的方法，其特征在于：所述方法通过使用kong插件实现原生API访问权限控制；

所述kong插件为APP鉴权插件；

所述方法的实现包括：

创建API，创建时选择APP认证；

发布API，在发布时将所述APP鉴权插件配置写入API网关；

API网关控制台前端页面根据用户需要创建APP应用，作为用户调用API的身份。

2.根据权利要求1所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，

所述kong插件通过Lua代码实现，使用Redis作为缓存数据库；

所述API网关提供前端签名及验签功能；

当API网关控制台前端页面接收到用户调用API时携带的认证信息，网关层执行APP认证逻辑：

如果签名认证通过，则请求成功；

如果签名认证失败，则请求失败。

3.根据权利要求2所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，所述APP应用包括一对AppKey和AppSecret密钥对，其中：

AppKey：用于标识所使用的的是哪个密钥对，参与签名，在请求时作为参数在Header或Query中传入；

AppSecret密钥：用于签名计算，用于计算请求签名。

4.根据权利要求3所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，

所述AppKey和AppSecret密钥对在API网关创建APP时由系统自动分配，并具备该APP的全部权限；

当API进行APP授权操作时，API网关控制台后端会将所选择的APP应用中有效的AppKey和AppSecret与API的路由名称绑定关系，持久化保存并缓存到Redis中。

5.根据权利要求4所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，所述API网关的控制台前端页面可根据用户需要创建多个APP应用，每个APP应用根据业务需求分别被不同的API授权。

6.根据权利要求2所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，所述签名在一定时间内有效，过期需重新生成签名。

7.根据权利要求4所述的一种基于应用实现API网关独立鉴权的方法，其特征在于：所述方法实现流程包括：

所述APP应用被API授权后，用户可使用app_key、app_secret和签名SDK生成签名秘钥；

API网关控制台接收到调用API指令时，将app_key和签名放到请求header中；

API网关控制台根据app_key去查询对应的secret；

根据获取到的app_key/app_secret计算签名；

比对从请求header中获取的签名与API网关计算的签名是否相等，如果相等，认证通过，否则认证失败。

8.根据权利要求3所述的一种基于应用实现API网关独立鉴权的方法，其特征在于：所述方法redis缓存的调用过程包括内容如下：

1)API网关控制台从redis缓存中查找是否有需要的app信息，如果有就返回，否则进行下一步查找；

2)通过调用API管理后端提供的接口查找需要的app信息，如果查到结果，更新redis缓存；

3)如果通过后端接口没有查到app信息，则更新redis缓存对应的key的一个空值，防止发起对后端的无效请求，同时设置一个较短的过期时间，防止如果后端数据更新后不生效。

9.根据权利要求2所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，所述签名构造过程包括：

构造签名内容：auth_app_key＝[app_key]&auth_time＝[auth_time]，app_key和auth_time参与签名，auth_time为当前UTC时间戳；

将所述签名内容通过base64_safe(HMAC-SHA1(app_secret,sign_str))计算生成sign，使用url安全的base64签名。

10.根据权利要求2所述的一种基于应用实现API网关独立鉴权的方法，其特征在于，所述APP认证的参数传递包括两种方式：通过header传参和通过query传参；

如果通过header传参，则header中传入参数包括：

X-Auth-App-Key，创建应用时的app_key；

X-Auth-time，UTC时间单位为秒的时间戳；

X-Auth-Sign，计算得到的签名；

如果通过query传参，则query中携带如下参数：

auth_app_key，创建应用时的app_key；

auth_time，UTC时间单位为秒的时间戳；

auth_sign，计算得到的签名。

Images