一种基于web架构的token权限认证方法及系统与流程

本发明涉及web系统权限认证领域，特别是一种基于web架构的token权限认证方法及系统。

背景技术：

当前web系统身份认证大多是采用校验token(令牌)的方式，且都是基于b/s架构的。token由服务器端对数据进行签名、编码生成。当浏览器发送获取token的请求时，服务器端将生成的token下发给浏览器，之后浏览器发送业务请求时，都会在请求头部带上token以供服务器校验，如果服务器校验token是合法的，将返回业务数据。在这个校验过程中存在很大的安全隐患，由于仅仅是浏览器/服务器双端架构的，如果浏览器端token被盗取，盗取者将通过服务器验证，非法获取数据。

现有技术中的token验证方式相比传统的session验证方式，它并不需要记录每次用户请求的信息，因此减小了服务器端内存的开销，但安全性并未提高多少。由于token是服务器端直接下发的，后续服务器端只需要校验这个token，因此只要获得token就可以通过验证。虽然目前也有应对方案，比方说设置token过期时间，但这并不能从根本上解决安全问题，用户只要获取了有效的token就能非法获取数据。

技术实现要素：

为克服上述问题，本发明的目的是提供一种能够通过增加中转服务器端，改变令牌token获取方式，提高了验证令牌token安全性的基于web架构的token权限认证方法。

本发明采用以下方案实现：一种基于web架构的token权限认证方法，所述方法包括以下步骤：

步骤s1、在浏览器端、中转服务器端和服务器端对系统用户的业务权限进行管理，同步用户业务权限信息至后台服务器数据库中；

步骤s2、当用户申请访问系统业务权限时，管理员在浏览器端对用户进行管理；

步骤s3、浏览器端将待申请的用户业务权限信息发送至中转服务器端，中转服务器端生成令牌token和统一资源定位符url；

步骤s4、用户在浏览器端发起业务请求时，中转服务器端会获取管理员通过浏览器端给用户分配的密钥key和认证串cert，生成令牌token；

步骤s5、浏览器端发起开通业务权限或获取业务数据请求时，服务器端会进行身份校验。

进一步的，所述步骤s1进一步具体包括以下步骤：

步骤s11、浏览器端管理员为用户开通业务权限，并将用户业务权限信息同步到中转服务器端和后端服务器数据库中；

步骤s12、管理员根据业务特征不同，在本地运用工具生成不同的密钥key和认证串cert；

步骤s13、浏览器端将待申请用户的业务权限信息发送到中转服务器端，请求开通业务权限；

步骤s14、服务器端接收到请求时，进行管理员身份校验；

步骤s15、服务器端身份校验通过，则保存用户业务权限信息到数据库中，并向中转服务器返回数据保存成功的消息；

步骤s16、中转服务器端只有接收到“成功”的消息，才将用户信息存储到中转数据库中，并返回“成功”消息给浏览器端；否，则直接返回“错误”消息给浏览器端；

步骤s17、服务器端身份校验不通过，返回相应错误码给中转服务器，中转服务器收到消息之后，返回“错误”消息给浏览器端；

步骤s18、浏览器端显示相应成功或者失败的提示到页面上。

进一步的，所述步骤s2进一步具体为：管理员在浏览器端对用户进行编辑、删除用户业务权限管理。

进一步的，所述步骤s3进一步具体包括以下步骤：

步骤s31、从中转数据库获取发起这个请求的管理员的密钥key和认证串cert，并进行解密；

步骤s32、将密钥key、时间戳、管理员id以及待开通业务权限用户id等信息组合成字符串；

步骤s33、将一种hash算法运用于所得的字符串与认证串cert；

步骤s34、对hash算法所得的结果加密形成最终的令牌token；

步骤s35、在服务器ip和端口后面加上特殊的规则字符串以及接口名字符串形成最终的统一资源定位符url。

进一步的，所述步骤s4进一步具体为：用户在浏览器端发起业务请求时，中转服务器端会获取用于申请业务类型，管理员根据具体业务给用户分配的密钥key和认证串cert。

进一步的，所述步骤s5进一步具体包括以下步骤：

步骤s51、服务器端根据发起请求的用户id等信息从数据库中取出密钥key和认证串cert；

步骤s52、重复步骤s3生成新的令牌token；

步骤s53、对比中转服务器端发送过来的令牌token和新的令牌token，判断二者是否相等；

步骤s54、是，则通过验证，判断是否为管理员发起的开通业务权限请求，是，则服务器端根据接收的数据，将其和用户业务信息一起保存在服务器数据库中，否，则无需保存用户信息；否，则验证不通过，返回相应错误码到中转服务器端。

本发明还提供了一种基于web架构的token权限认证系统，包括同步模块、管理模块、生成模块、分配模块和校验模块；所述同步模块，即在浏览器端、中转服务器端和服务器端对系统用户的业务权限进行管理，同步用户业务权限信息至后台服务器数据库中；所述管理模块，即当用户申请访问系统业务权限时，管理员在浏览器端对用户进行管理；所述生成模块，即浏览器端将待申请的用户业务权限信息发送至中转服务器端，中转服务器端生成令牌token和统一资源定位符url；所述分配模块，即用户在浏览器端发起业务请求时，中转服务器端会获取管理员通过浏览器端给用户分配的密钥key和认证串cert，生成令牌token；所述校验模块，即浏览器端发起开通业务权限或获取业务数据请求时，服务器端会进行身份校验。

进一步的，所述同步模块进一步包括：开通单元、业务特征单元、请求单元、身份校验单元、保存单元、返回单元、返回错误单元和显示单元；所述开通单元，即浏览器端管理员为用户开通业务权限，并将用户业务权限信息同步到中转服务器端和后端服务器数据库中；所述业务特征单元，即管理员根据业务特征不同，在本地运用工具生成不同的密钥key和认证串cert；所述请求单元，即浏览器端将待申请用户的业务权限信息发送到中转服务器端，请求开通业务权限；所述身份校验单元，即服务器端接收到请求时，进行管理员身份校验；所述保存单元，即服务器端身份校验通过，则保存用户业务权限信息到数据库中，并向中转服务器返回数据保存成功的消息；所述返回单元，即中转服务器端只有接收到“成功”的消息，才将用户信息存储到中转数据库中，并返回“成功”消息给浏览器端；否，则直接返回“错误”消息给浏览器端；所述返回错误单元，即服务器端身份校验不通过，返回相应错误码给中转服务器，中转服务器收到消息之后，返回“错误”消息给浏览器端；所述显示单元，即浏览器端显示相应成功或者失败的提示到页面上。

进一步的，所述管理模块进一步具体为：管理员在浏览器端对用户进行编辑、删除用户业务权限管理。

进一步的，所述生成模块进一步具体包括：获取单元、字符串单元、算法单元、形成单元和加入单元，所述获取单元，即从中转数据库获取发起这个请求的管理员的密钥key和认证串cert，并进行解密；所述字符串单元，即将密钥key、时间戳、管理员id以及待开通业务权限用户id等信息组合成字符串；所述算法单元，即将一种hash算法运用于所得的字符串与认证串cert；所述形成单元，即对hash算法所得的结果加密形成最终的令牌token；所述加入单元，即在服务器ip和端口后面加上特殊的规则字符串以及接口名字符串形成最终的统一资源定位符url。

进一步的，所述分配模块进一步具体为：用户在浏览器端发起业务请求时，中转服务器端会获取用于申请业务类型，管理员根据具体业务给用户分配的密钥key和认证串cert。

进一步的，所述校验模块进一步包括：发起单元、重复单元、对比单元和判断单元；所述发起单元，即服务器端根据发起请求的用户id等信息从数据库中取出密钥key和认证串cert；所述重复单元，即重复步骤s3生成新的令牌token；所述对比单元，即对比中转服务器端发送过来的令牌token和新的令牌token，判断二者是否相等；所述判断单元，即是，则通过验证，判断是否为管理员发起的开通业务权限请求，是，则服务器端根据接收的数据，将其和用户业务信息一起保存在服务器数据库中，否，则无需保存用户信息；否，则验证不通过，返回相应错误码到中转服务器端。

本发明的有益效果在于：本方案在传统b/s架构的基础上，增加了中转服务器端，传统架构浏览器端直接与服务器端通信，系统易受攻击，本方案中，浏览器端与中转服务器端、中转服务器端与后端服务器通信过程相互独立，系统不易遭受攻击，安全性更高；本方案使用生成令牌token的算法，相比传统算法，较为复杂；不同请求，根据接收参数的不同，算法并不完全相同，如应用场景的例子，中转服务器和后端服务器会将开通权限请求与业务请求区分开来，运用不同的算法流程计算令牌token，因此不易被破解，可靠性更高；中转服务器以及后端服务器各自运用相同的算法流程计算生成令牌token，而不是后端服务器直接下发，很大程度上降低了令牌token被盗取，发生数据泄露的几率；计算令牌token所需的密钥key和认证串cert，也是由两端独自生成，并不存在相互传递过程，进一步保证了令牌token的安全性。

附图说明

图1是本发明的方法流程示意图。

图2是本发明的系统原理框图。

图3为用户业务权限申请的流程示意图。

图4为服务器端校验身份的流程示意图。

图5为使用案例的时序图。

具体实施方式

下面结合附图对本发明做进一步说明。

请参阅图1所示，本发明的一种基于web架构的token权限认证方法，所述方法包括以下步骤：

步骤s1、在浏览器端、中转服务器端和服务器端对系统用户的业务权限进行管理，同步用户业务权限信息至后台服务器数据库中；

步骤s2、当用户申请访问系统业务权限时，管理员在浏览器端对用户进行管理；

步骤s3、浏览器端将待申请的用户业务权限信息发送至中转服务器端，中转服务器端生成令牌token和统一资源定位符url；

步骤s4、用户在浏览器端发起业务请求时，中转服务器端会获取管理员通过浏览器端给用户分配的密钥key和认证串cert，生成令牌token；

步骤s5、浏览器端发起开通业务权限或获取业务数据请求时，服务器端会进行身份校验。

下面通过一实施例对本发明作进一步说明：

基于浏览器端、中转服务器端以及服务器端的身份认证方案，其具体实现包含以下步骤：

a1、对系统用户的业务权限进行管理，同步用户业务权限信息到后台服务器数据库中。当用户发送业务请求时，后台服务器进行用户业务权限认证；

a1-1、浏览器端管理员为用户开通业务权限，并将用户业务权限信息同步到中转服务器、后端服务器数据库中，交互过程如图3所示；

a1-1-1、管理员根据业务特征不同，在本地运用工具生成不同的密钥key和认证串cert，key是密钥，cert是认证串，生成的密钥key和认证串cert与用户业务权限绑定，该工具将用户信息(如用户1)与业务信息(如项目1、项目2)等结合起来并采用加密算法生成密钥key和认证串cert，由此可见，不同的用户、不同的业务生成的密钥key和认证串cert是不同的。

a1-1-2、浏览器端将待申请用户的业务权限信息发送到中转服务器，请求开通业务权限。

a1-1-3、中转服务器接收到该请求，首先判断该用户是否首次开通该业务权限，是则根据浏览器发送的数据，结合管理员的密钥key和认证串cert，经过一系列重组、加密的过程生成令牌token，具体过程在步骤a3-1详细说明。中转服务器将令牌token携带在请求头部，发送数据到后端服务器；如果数据库中已存在该条用户权限记录，则直接返回“记录已存在”消息到浏览器端。

a1-1-4、后端服务器接收到请求时，立即进行管理员身份校验；

a1-1-5、服务器端身份校验通过，则保存用户业务权限信息到数据库中，并向中转服务器返回数据保存成功的消息；

a1-1-6、中转服务器端只有接收到“成功”的消息，才将用户信息存储到中转数据库中，并返回“成功”消息给浏览器端；否则直接返回“错误”消息给浏览器端；

a1-1-7、服务器端身份校验不通过，返回相应错误码给中转服务器，中转服务器收到消息之后，返回“错误”消息给浏览器端；

a1-1-8、浏览器端显示相应成功或者失败的提示到页面上；

a2、管理员在浏览器端对用户进行其他管理，如编辑、删除用户业务权限，系统流程与上述开通用户业务权限的流程类似，都是先经过中转服务器转发，服务器进行身份校验，校验通过同步用户权限信息到服务器数据库，中转服务器再进行信息保存；校验不通过或者用户权限信息保存失败，则最终返回“错误”消息到浏览器端；

a3、步骤a1-1-3中转服务器端生成令牌token、统一资源定位符url的过程：

a3-1、从中转数据库获取发起这个请求的管理员的密钥key和认证串cert，并进行解密；

a3-1、将key、时间戳、管理员id以及待开通业务权限用户id等信息组合成字符串；

a3-2、将一种hash算法运用于步骤a3-1所得的字符串与cert；

a3-3、对步骤a3-2所得的结果加密形成最终的令牌token；

a3-4、在服务器ip和端口后面加上特殊的规则字符串以及接口名字符串形成最终的

url；

a4、用户在浏览器端发起业务请求时，中转服务器会获取步骤a2中管理员根据具体业务给用户分配的密钥key和认证串cert，其他生成令牌token、统一资源定位符url的过程与步骤a3类似，不过与步骤a3-1中的字符串组合方式不同，可能会多几个或者少几个字段；与步骤a3-4中生成url的规则也完全不相同；

a5、浏览器端发起开通权限或者获取业务数据请求时，服务器端进行身份校验的过程，如图4所示：

a6-1、服务器端根据发起请求的用户id等信息从数据库中取出密钥key和认证串cert；a6-2、重复a3-1到a3-3的步骤，生成一个新的令牌token；

a6-3、对比中转服务器发送过来的令牌token和步骤a5-2生成的token，判断二者是否相等；

a6-4、若两者相等，则通过验证，此处若为管理员发起的开通业务权限请求，则服务器端根据接收的数据，如用户id等，计算生成密钥key和认证串cert，将其和用户业务信息一起保存在服务器数据库中；若是用户的业务请求，则无需保存用户信息；

a6-5、若两者不等，则验证不通过，返回相应错误码到中转服务器。

下面通过一具体应用场景，对本发明作进一步说明：

应用场景：系统初始超级管理员a给用户b开通超级管理员权限，超级管理员b给普通用户c开通具体业务权限，用户c再发起业务请求，获取业务数据的过程；场景交互如图5所示，具体流程如下：

1、超级管理员a在浏览器上给用户b开通访问系统的权限，给用户b分配id、超级管理员角色以及密钥key和认证串cert，密钥key和认证串cert由超级管理员a运行本地工具生成。

2、浏览器端向中转服务器发起开通权限请求，将用户b的信息(id、角色id、密钥key和认证串cert)发送过去。

3、中转服务器接收到请求之后，首先查找中转服务器中记录是否已存在，如果已存在，直接返回相关错误码；记录不存在则进行下一步。

4、中转服务器从数据库里取出超级管理员a的密钥key和认证串cert并解密，利用超级管理员a的id、用户b的id、key、cert、时间戳以及其他一些特殊约定字符串运用算法生成令牌token，按照约定拼接好url，向后端服务器发送请求。

5、后端服务器根据超级管理员a的id从数据库里取出密钥key和认证串cert，然后再用与中转服务器同样的算法生成令牌token，令牌token与中转服务器传送的令牌token相同则通过校验，利用中转服务器传送的用户b的id、角色id信息运用与前端工具同样的算法生成密钥key和认证串cert，将用户b的id、角色id以及计算得到的cert和key保存在后端数据库中，最后返回中转服务器请求的数据；令牌token不等则返回没有权限提示信息。

6、中转服务器收到后端服务器返回成功的消息之后，将用户b的密钥key和认证串cert加密之后与id、角色id一起存入中转数据库中。如果收到的是失败的消息，则不保存用户b信息，将错误信息返回给浏览器。

7、浏览器端收到错误信息之后，在页面提示“添加用户”失败的信息。

8、超级管理员b给普通用户c开通业务权限，如给c开通游戏1、站点2的访问权限。

9、超级管理员b运用工具输入参数游戏1、站点2生成用户c的业务密钥key和认证串cert，浏览器向中转服务器发起请求。

10、中转服务器接收到请求之后，处理流程和步骤3-4类似，只是生成token时有所不同，需要超级管理员b的密钥key和认证串cert，url的拼接约定也不一样，传送的信息包括用户c的id、游戏id以及站点id。

11、后端服务器处理流程与步骤5类似，后端服务器从数据库中取出超级管理员b的密钥key和认证串cert，生成令牌token进行校验，如果校验通过，利用收到的用户id、游戏id以及站点id运用与步骤5同样的工具算法生成密钥key和认证串cert，然后与用户c的id信息一起存入后端数据库中。

12、在后端服务器保存用户c的业务权限信息成功之后，中转服务器也保存用户c的业务权限信息，并返回成功的消息给浏览器端。

13、用户c在浏览器端发起游戏1、站点2的业务请求，中转服务器转发请求到服务器端，服务器从数据库中取出用户c的业务密钥key和认证串cert，之后计算令牌token进行校验，校验通过则返回请求的数据。

14、用户c在浏览器端获取到请求的数据。

总之，本方案提出的身份认证方案基于浏览器端、中转服务器端、服务器端实现，浏览器端管理员运用工具生成密钥key和认证串cert，不同角色、不同用户以及不同业务生成的密钥key和认证串cert是不同的，加密之后存储在中转服务器数据库中。中转服务器接收到浏览器端请求时，根据接收到的数据，从数据库取出需要使用的密钥key和认证串cert并解密，运用算法生成令牌token，然后将请求转发给服务器端。服务器端接收到请求之后，根据中转服务器发送的数据，从数据库取出对应的密钥key和认证串cert，运用同样的算法生成令牌token，生成的令牌token如果与接收到的令牌token相同，则通过验证，返回响应数据，其他情况返回错误码。

生成密钥key和认证串cert的工具并不运行在浏览器上，而是运行在管理员的pc上，管理员运用工具根据相对复杂的规则生成密钥key和认证串cert，随着参数的不同，生成的值也会不同，不同用户、不同业务会生成不同值。加密之后存储到数据库中也能保证安全性。服务器端的密钥key和认证串cert也是运用与前端工具相同的规则生成，当服务器端通过管理员发起的权限请求时，就会将用户的业务权限信息与密钥key和认证串cert一起保存在后端数据库中。

请参阅图2所示，本发明还提供了一种基于web架构的token权限认证系统，包括同步模块、管理模块、生成模块、分配模块和校验模块；所述同步模块，即在浏览器端、中转服务器端和服务器端对系统用户的业务权限进行管理，同步用户业务权限信息至后台服务器数据库中；所述管理模块，即当用户申请访问系统业务权限时，管理员在浏览器端对用户进行管理；所述生成模块，即浏览器端将待申请的用户业务权限信息发送至中转服务器端，中转服务器端生成令牌token和统一资源定位符url；所述分配模块，即用户在浏览器端发起业务请求时，中转服务器端会获取管理员通过浏览器端给用户分配的密钥key和认证串cert，生成令牌token；所述校验模块，即浏览器端发起开通业务权限或获取业务数据请求时，服务器端会进行身份校验。

所述同步模块进一步包括：开通单元、业务特征单元、请求单元、身份校验单元、保存单元、返回单元、返回错误单元和显示单元；所述开通单元，即浏览器端管理员为用户开通业务权限，并将用户业务权限信息同步到中转服务器端和后端服务器数据库中；所述业务特征单元，即管理员根据业务特征不同，在本地运用工具生成不同的密钥key和认证串cert；所述请求单元，即浏览器端将待申请用户的业务权限信息发送到中转服务器端，请求开通业务权限；所述身份校验单元，即服务器端接收到请求时，进行管理员身份校验；所述保存单元，即服务器端身份校验通过，则保存用户业务权限信息到数据库中，并向中转服务器返回数据保存成功的消息；所述返回单元，即中转服务器端只有接收到“成功”的消息，才将用户信息存储到中转数据库中，并返回“成功”消息给浏览器端；否，则直接返回“错误”消息给浏览器端；所述返回错误单元，即服务器端身份校验不通过，返回相应错误码给中转服务器，中转服务器收到消息之后，返回“错误”消息给浏览器端；所述显示单元，即浏览器端显示相应成功或者失败的提示到页面上。

所述管理模块进一步具体为：管理员在浏览器端对用户进行编辑、删除用户业务权限管理。

所述生成模块进一步具体包括：获取单元、字符串单元、算法单元、形成单元和加入单元，所述获取单元，即从中转数据库获取发起这个请求的管理员的密钥key和认证串cert，并进行解密；所述字符串单元，即将密钥key、时间戳、管理员id以及待开通业务权限用户id等信息组合成字符串；所述算法单元，即将一种hash算法运用于所得的字符串与认证串cert；所述形成单元，即对hash算法所得的结果加密形成最终的令牌token；所述加入单元，即在服务器ip和端口后面加上特殊的规则字符串以及接口名字符串形成最终的统一资源定位符url。

所述分配模块进一步具体为：用户在浏览器端发起业务请求时，中转服务器端会获取用于申请业务类型，管理员根据具体业务给用户分配的密钥key和认证串cert。

所述校验模块进一步包括：发起单元、重复单元、对比单元和判断单元；所述发起单元，即服务器端根据发起请求的用户id等信息从数据库中取出密钥key和认证串cert；所述重复单元，即重复步骤s3生成新的令牌token；所述对比单元，即对比中转服务器端发送过来的令牌token和新的令牌token，判断二者是否相等；所述判断单元，即是，则通过验证，判断是否为管理员发起的开通业务权限请求，是，则服务器端根据接收的数据，将其和用户业务信息一起保存在服务器数据库中，否，则无需保存用户信息；否，则验证不通过，返回相应错误码到中转服务器端。

以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所做的均等变化与修饰，皆应属本发明的涵盖范围。