CN109034816A - 用户信息验证方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本发明公开了一种用户信息验证方法、装置、计算机设备及存储介质，该用户信息验证方法包括：获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；基于目标用户标识获取用户验证信息；基于所述目标业务类型获取所述用户信息验证请求的基准验证字段，其中，所述基准验证字段为至少两个；基于基准验证字段查询用户验证信息；若每一所述基准验证字段都在所述用户验证信息中查询到相匹配的验证数据，则响应所述用户信息验证请求。该方法提高了用户信息验证效率。

Description

用户信息验证方法、装置、计算机设备及存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种用户信息验证方法、装置、计算机设备及存储介质。

背景技术

目前，用户在一个企业或者平台中办理安全性要求较高的业务时，通常都需要进行用户信息的验证，而对于部分用户信息还需要进行进一步的鉴权而实现验证的过程，例如，身份证信息和银行卡信息。然而，在对用户的身份证信息和银行卡信息进行鉴权时，均需要委托第三方平台进行鉴权，并且需要向第三方平台支付相应的费用。虽然这种验证方式可以保证用户信息的真实性，但是验证环节需要花费一定的时间，验证效率较低。

发明内容

基于此，有必要针对上述技术问题，提供一种可以提高用户信息验证效率的用户信息验证方法、装置、计算机设备及存储介质。

一种用户信息验证方法，包括：

获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；

基于目标用户标识获取用户验证信息；

基于所述目标业务类型获取所述用户信息验证请求的基准验证字段，其中，所述基准验证字段为至少两个；

基于基准验证字段查询用户验证信息；

若每一所述基准验证字段都在所述用户验证信息中查询到相匹配的验证数据，则响应所述用户信息验证请求。

一种用户信息验证装置，包括：

第一获取模块，用于获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；

第二获取模块，用于基于目标用户标识获取用户验证信息；

第三获取模块，用于基于所述目标业务类型获取所述用户信息验证请求的基准验证字段，其中，所述基准验证字段为至少两个；

查询模块，用于基于基准验证字段查询用户验证信息；

第一响应模块，用于若每一所述基准验证字段都在所述用户验证信息中查询到相匹配的验证数据，则响应所述用户信息验证请求。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述用户信息验证方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述用户信息验证方法的步骤。

上述用户信息验证方法、装置、计算机设备及存储介质，服务器在获取到用户验证请求之后，基于用户验证请求中的目标用户标识获取用户验证信息，并且通过基于目标业务类型获取的基准验证字段查询用户验证信息，若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。通过上述步骤可以避免对已经在办理其他业务时，已通过验证的用户信息，进行重复验证，提高了用户信息验证的效率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例中用户信息验证方法的一应用环境示意图；

图2是本发明一实施例中用户信息验证方法的一流程图；

图3是本发明一实施例中用户信息验证方法中对登录进行验证的一流程图；

图4是本发明一实施例中用户信息验证方法中对用户验证信息进行整合的一流程图；

图5是本发明一实施例中用户信息验证方法中步骤S22的实现流程图；

图6是本发明一实施例中用户信息验证方法中对不匹配的验证数据进行验证的一流程图；

图7是本发明一实施例中用户信息验证方法的一流程图；

图8是本发明一实施例中用户信息验证装置的一原理框图；

图9是本发明一实施例中计算机设备的一示意图。

具体实施方式

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

本申请提供的用户信息验证方法，可应用在如图1的应用环境中，其中，客户端(计算机设备)通过网络与服务端进行通信。客户端获取用户信息验证请求，并将用户信息验证请求发送至服务器。服务端获取到用户信息验证请求后，基于用户信息验证请求进行相应地处理，并响应该用户信息验证请求。其中，计算机设备可以但不限于各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。服务端可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一实施例中，如图2所示，提供一种用户信息验证方法，以该方法应用在图1中的服务端为例进行说明，包括如下步骤：

S10：获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型。

用户信息验证请求是指用户需要办理对应业务而触发的需要对身份信息进行验证的请求。目标用户标识为进行用户信息验证的用户对应的用户标识，用户标识适用于区分不同用户的标识，例如，用户标识可以是用户的身份证号码，或者是与用户唯一对应的账号ID等。目标业务类型是指用户需要办理的目标业务对应的类型，其中不同类型的目标业务需要验证的身份信息不同。

S20：基于目标用户标识获取用户验证信息。

由于目标用户标识具有唯一性，因此可以将目标用户标识作为检索字段，检索该目标用户标识的用户验证信息。可选地，可以基于目标用户标识在大数据平台中获取用户验证信息。

用户验证信息为已通过验证的用户身份信息，该用户在办理其他业务时，有可能需要对用户身份信息进行验证，而经过验证之后就会形成对应用户的验证数据，该用户在不同业务中的验证数据的总和就是其用户验证信息。而在该步骤中，基于目标用户标识获取用户验证信息，即是通过目标用户标识，获取该目标用户标识在以往办理过的业务中对应的用户验证信息。可选地，用户验证信息可以包括用户的姓名、身份证号、手机号、银行卡号或指纹信息等至少一项。其中，手机号、银行卡号和指纹信息对应的验证信息可以是一项或者是多项。

例如：用户在办理一个业务时通过验证的用户验证信息为第一手机号、第一银行卡号和左手拇指指纹信息，在办理另一个业务时通过验证的用户验证信息为第二手机号、第一银行卡号和右手拇指指纹信息。因此，基于目标用户标识获取的该用户的用户验证信息为第一手机号、第二手机号、第一银行卡号、左手拇指指纹信息和右手拇指指纹信息。

S30：基于目标业务类型获取用户信息验证请求的基准验证字段，其中，基准验证字段为至少两个。

其中，基准验证字段为用户信息验证请求中对应的目标业务中，需要进行验证的用户身份信息对应的字段。具体地，基准验证字段为至少两个，例如，在对用户身份信息进行验证时，都会在验证用户的姓名的基础上再验证至少一个字段(例如：银行卡、身份证或者手机号)。因此，基准验证字段为至少两个。对于不同的目标业务类型，需要进行验证的内容也会存在不同。例如，对于一些普通业务，可能只需要验证用户的姓名、身份证号和手机号即可，而对于较为核心业务，可能需要验证用户的姓名、身份证号、手机号、银行卡号和指纹信息。因此通过基于目标业务类型，获取该目标业务类型的基准验证字段。

例如，对于一目标业务类型，在办理该类型的目标业务时，需要对用户的姓名、身份证号、手机号码和银行卡号进行验证，则基于该目标业务类型获取用户信息验证请求的基准验证字段为姓名、身份证号、手机号码和银行卡号。

S40：基于基准验证字段查询用户验证信息。

具体地，根据获取的基准验证字段，在用户验证信息中查询该目标业务类型所需要进行验证的用户身份信息。例如，若基准验证字段为姓名、身份证号、手机号码和银行卡号，则基于上述基准验证字段在用户验证信息中查询是否存在相对应的验证数据。

S50：若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。

具体地，每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，是指在用户验证信息中存在和基准验证字段对应的验证数据。即若每一个基准验证字段都能够在用户验证信息中，成功查询到该目标业务类型相匹配的验证数据，则响应该用户信息验证请求。可选地，响应该用户信息验证请求可以为通过该用户信息验证请求。

在本实施例中，服务器在获取到用户验证请求之后，基于用户验证请求中的目标用户标识获取用户验证信息，并且通过基于目标业务类型获取的基准验证字段查询用户验证信息，若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。通过上述步骤可以避免对已经在办理其他业务时已通过验证的用户信息进行重复验证，提高了用户信息验证的效率。

在一实施例中，如图3所示，在步骤S10之前，该用户信息验证方法还包括如下步骤：

S11：获取登录请求信息，登录请求信息包括目标用户标识和目标用户密码。

在本发明实施例中，登录请求信息是指客户端在获取到用户在登录界面的输入信息之后经过处理，并发送到服务端中的信息。登录请求信息包括目标用户标识和目标用户密码。该目标用户标识和目标用户密码组成登录请求信息之后，客户端将该登录请求信息发送至服务端，服务端获取该登录请求信息。

可选地，目标用户标识和目标用户密码也可以是客户端在获取到用户输入的登录信息之后进行加密得到的。通过加密处理可以保证登录请求信息在数据传输过程中的安全性。

S12：基于目标用户标识对目标用户密码进行验证。

具体地，用户在注册之时会按照一定的提示信息输入或选择账户登录信息，其中，账户登录信息包括用户的原始用户标识和注册密码，服务端在获取该账户登录信息之后，将该账户登录信息存储在注册记录表中。而基于目标用户标识对目标用户密码进行验证的过程具体为：服务端基于目标用户标识在注册记录表中查找到对应的原始用户标识，并将该原始用户标识对应的注册密码和目标用户密码进行比对，若两者相同，则验证成功。

可选地，服务端将该账户登录信息中的注册密码按照预设的方式进行加密，得到加密注册密码后，再存储在注册记录表中。此时，客户端发送至服务端的登录请求信息也是经过加密处理的。需要说明的是，对注册密码进行加密的方式与对登录请求信息加密的方式相同。因此，对于同一个用户的目标用户标识，若输入的登录密码与注册密码相同，则加密后得到的目标用户密码和加密注册密码也相同。

进一步地，服务端在获取登录请求信息之后，基于目标用户标识在注册记录表中查询该目标用户标识的加密注册密码，若该加密注册密码与登录请求信息中的目标用户密码相同，则目标用户密码验证成功。

S13：若目标用户密码验证成功，则发送业务类型列表。

在目标用户密码验证成功，则用户登录成功。在用户登录成功后，则获取该平台中的已有业务，并生成已有业务表，发送到客户端，以供用户选择。可选地，已有业务表包括已有业务和对应的业务类型。

S14：获取目标业务类型，基于目标用户标识和目标业务类型生成用户信息验证请求。

具体地，用户在客户端的显示界面中选择一个目标业务，客户端将该目标业务对应的业务类型作为目标业务类型，并基于该目标业务类型和目标用户标识生成用户信息验证请求。然后客户端将该用户信息验证请求发送至服务端，服务端获取到该用户信息验证请求。

本实施例中，用户可以通过同一个目标用户标识和目标用户密码在不同的平台中进行登录操作，省去了重复注册账号的操作，同时也因为同一个用户标识只有一个账号信息，而减少了服务器注册记录表的表格容量，节省了存储空间。进一步地，在用户信息验证之前对用户进行登录信息的验证，保证了用户信息验证的安全性。而且，通过在客户端对用户的登录信息进行加密，再传输到服务端进行登录验证，能够提高用户的账号信息的安全性，有效地避免在数据传输的过程中出现密码泄露的风险。

在一实施例中，如图4所示，在步骤S20之前且在步骤S10之后，该用户信息验证方法还包括如下步骤：

S21：获取各个接口的用户验证数据表。

用户验证数据表是用于存储用户办理不同业务时的验证数据的表格，并使用该用户的原始用户标识区分每个用户的用户验证数据表。其中，原始用户标识为用户注册时设置的注册账号，用户唯一区分不同用户的标识，例如，身份证号或账号ID等。

具体地，在不同业务中设置对应的接口，用于进行数据的交互。在获取到该用户信息验证请求后，通过获取各个接口的用户验证数据表，以便于后续进行验证数据表的整合。

可选地，可以在各个接口中加入数据抽取模块，用于抽取用户验证信息数据表。可选地，可以通过数据抽取模块，从各个接口的数据库中抽取用户验证数据表，并发送至服务端。服务端获取到各个接口的用户验证数据表。具体地，可以以原始用户标识为单位，抽取同一原始用户标识在各个接口的用户验证数据表。

优选地，还可以设置有数据触发器，用于当任一接口的数据库中有数据发生变更时，记录数据变更信息。当检测到任一接口的用户验证数据表发生增加、删除或者修改的变更时，采用数据触发器将变更后的用户验证数据表，通过数据抽取模块发送至大数据平台，大数据平台更新替换原有的用户验证数据表。

S22：基于同一原始用户标识，整合用户验证数据表，得到用户验证信息。

具体地，基于同一原始用户标识，对用户验证数据表中，内容重复的验证数据进行合并或筛选，以原始用户标识为单位，组成各个原始用户标识的用户验证信息。

可选地，可以通过大数据平台，接收由数据抽取模块发送的用户验证数据表，并将这些用户验证数据表进行整理，之后再发送到服务端，以提高数据整合效率。

在本实施例中，通过获取各个接口中的用户验证数据表，通过基于同一原始用户标识，对各个接口的用户验证数据表进行整合，使得同一原始用户标识的用户验证数据都在同一张表格中。在用户信息验证中查询对应的验证数据时，不需要到各个接口上获取对应的用户验证数据表，节省了查询时间，提高了查询效率。

在一实施例中，如图5所示，步骤S22中，即基于同一原始用户标识，整合用户验证数据表，得到用户验证信息，具体包括如下步骤：

S221：基于同一原始用户标识，在用户验证数据表中获取对应的用户验证数据，用户验证数据包括原始用户标识、验证内容和验证日期。

其中，原始用户标识是用户验证数据表中不同用户的用户标识。验证内容是该原始用户标识通过验证的用户身份信息。验证日期是指该验证内容通过验证的日期。

S222：若同一原始用户标识中存在相同验证内容的用户验证数据，则获取相同验证内容的用户验证数据中的验证日期，作为目标验证日期。

具体地，在获取到同一原始用户标识的验证内容后，查询是否存在相同的验证内容，例如，同一原始用户标识的第一手机号码，在第一接口和第二接口中均已验证过，则该原始用户标识对应的用户验证数据中，会存在两条验证内容为第一手机号码的用户验证数据。若存在相同的验证内容，则分别获取相同验证内容对应的验证日期，作为目标验证日期。

S223：对目标验证日期进行排序，获取排序后最新的目标验证日期和该最新的目标验证日期对应的验证内容，并将非最新的目标验证日期对应的用户验证数据删除。

在本实施例中，该最新的目标验证日期是指与获取到该用户信息验证请求的日期最接近的目标验证日期。

具体地，获取到目标验证日期后，对目标验证日期，按照目标验证日期的时间先后进行排序。在对目标验证日期进行排序后，只获取最新的目标验证日期和该最新的目标验证日期对应的验证内容，并将非最新的目标验证日期对应的用户验证数据删除。

例如：用户在第一接口和第二接口均对姓名，身份证号和第一手机号进行过验证，且用户在第一接口的姓名，身份证号和第一手机号的目标验证日期为2017年3月15日，而用户在第二接口的姓名、身份证号和第一手机号的目标验证日期为2017年5月8日，则用户在第二接口的姓名、身份证号和第一手机号的验证日期为最新的目标验证日期，用户在第一接口的姓名、身份证号和第一手机号的目标验证日期为非最新的目标验证日期。此时会将从第一接口获取的验证内容为姓名、身份证号和第一手机号的用户验证数据删除。

S224：汇总同一原始用户标识对应的用户验证数据，得到用户验证信息。

进一步地，在对同一原始用户标识的相同的验证内容进行整合后，与该同一原始用户标识的其他验证内容进行整合，得到该原始用户标识的用户验证信息。

为了更好的理解本实施例的技术方案，下面通过一个具体地例子说明整合用户验证数据表过程，详述如下：

例如，张三在第一接口的用户验证数据表中的验证数据为姓名、身份证号、第一手机号、第一银行卡号和右手拇指指纹以及各项验证内容的验证日期；张三在第二接口的用户验证数据表中的验证数据为姓名、身份证号、第二手机号和第二银行卡号以及各项验证内容的验证日期。

其中，张三的姓名和身份证号为相同的验证内容，因此判断张三的姓名和身份证号分别在第一接口和第二接口的验证日期的时间先后，通过步骤S223和步骤S224的操作后，得到张三的用户验证信息为张三的姓名、身份证号、第一手机号、第二手机号、第一银行卡号、第二银行卡号和右手拇指指纹以及各项验证内容的验证日期。

在本实施例中，通过根据目标验证日期对相同验证内容进行合并，并对用户验证数据表进行整合，保证用户验证信息的简洁，提高后续查询的效率。

在一实施例中，如图6所示，在步骤S40之后，该用户信息验证方法还包括如下步骤：

S41：若存在至少一个基准验证字段在用户验证信息中查询不到相匹配的验证数据，则将对应的基准验证字段作为目标验证字段。

可选地，存在至少一个基准验证字段在用户验证信息中查询不到相匹配的验证数据，是指在至少有一个基准验证字段，不能从用户验证信息中查询并获取到相对应的验证数据。例如，若基准验证字段为姓名和指纹信息，而用户验证信息中并不存在指纹信息，则在用户验证信息中查询不到和指纹信息相匹配的验证数据。

优选地，在用户验证信息中，未获取到相匹配的验证数据的基准验证字段还包括该用户验证信息中存在和基准验证字段相对应的的验证数据，但是验证数据的时效不满足该目标业务类型要求。在对用户的验证内容进行验证的时候，会根据业务类型设置验证内容的时效。其中，时效是指从验证日期到获取目标业务类型的日期，验证日期是指该验证内容通过验证的日期。具体地，验证数据的时效不满足该目标业务类型要求，可以是指该验证数据对应的时效超过该目标业务类型的对验证数据的时效的要求。

例如：目标业务类型对验证数据的时效要求为在半年，若用户验证信息中的验证数据对应的验证日期，到获取目标业务类型的日期超过六个月，则判定该验证数据的时效不满足该目标业务类型的要求，即该验证数据和基准验证字段是不匹配的。

因此，若存在在用户验证信息中，未获取到相匹配的验证数据的基准验证字段，则将未获取到相匹配的验证数据的基准验证字段作为目标验证字段，以提示用户对目标验证字段进行验证。

S42：基于目标验证字段发送目标验证字段验证请求。

具体地，将该目标验证字段验证请求送至客户端，以提示用户对该目标验证字段对应的验证内容进行验证。优选地，该目标验证字段验证请求包括目标验证字段。

S43：获取目标验证字段验证请求对应的目标验证信息，若目标验证信息验证通过，则响应用户信息验证请求。

进一步地，用户向客户端反馈目标验证字段验证请求中包含的验证内容，客户端获取该验证内容，作为目标验证信息发送至服务端。服务端对接收到客户端发送的目标验证信息并进行验证，若验证通过，则响应用户信息验证请求。

在本实施例中，若存在用户验证信息中未获取到相匹配的验证数据的基准验证字段，则对对应的基准验证字段进行验证，保证了用户信息验证的及时性，同时，仅验证在用户验证信息中，未获取到相匹配的验证数据的基准验证字段，有利于提高用户信息验证的效率。

在一实施例中，如图7所示，步骤S43中，即响应用户信息验证请求。具体包括如下步骤：

S431：基于目标业务类型获取业务安全等级。

具体地，业务安全等级是指由于目标业务类型的不同，因此目标业务类型的业务安全等级也不同。例如：可以按照目标业务类型的业务价格，进行业务安全等级的设置，若该业务价格越高，则对应的目标业务类型也越高。根据不同的业务安全等级，发送不同等级的用户身份验证请求。

S432：基于业务安全等级和目标用户标识发送对应的用户身份验证请求。

进一步地，用户身份验证请求中可以包括但不限于：OTP(动态口令，One-timePassword)，人脸识别或者短信验证等，具体验证方式可以由业务安全等级确定，此处不做限制。根据不同业务安全等级，发送不同方式的用户身份验证请求。优选地，业务安全等级越高，对应的用户身份验证请求的方式越严格。例如，对于普通的业务安全等级，可以仅通过短信验证即可，对于高级的业务安全等级，可以通过人脸识别进行验证。可选地，也可以采用多种验证方式结合来进行验证，例如，用户身份验证请求可以是人脸识别和短信验证结合的方式。

S433：获取用户身份校验信息，若用户身份校验信息验证通过，则用户信息验证请求验证通过。

身份校验信息是指用户根据用户身份验证请求进行的验证信息。客户端在获取到身份校验信息之后，将身份校验信息发送至服务端。服务端获取该用户身份校验信息之后，进行验证。若用户身份校验信息验证通过，则用户信息验证请求验证通过。

优选地，服务端在获取到用户身份校验信息后，基于该目标用户标识，对用户身份校验信息进行验证。可选地，可以将用户身份校验信息和服务端预先存储的用户身份信息进行比对。若比对结果为匹配，则用户身份校验信息验证通过，且用户信息验证请求验证通过。

在本实施例中，基于目标业务类型的业务安全等级对用户进行身份验证，确保是用户本人进行办理业务和对验证数据提供免验证的操作，提高了用户信息的安全性，降低了信息泄漏的风险。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

在一实施例中，提供一种用户信息验证装置，该用户信息验证装置与上述实施例中用户信息验证方法一一对应。如图8所示，该用户信息验证装置包括第一获取模块81、第二获取模块82、第三获取模块83、查询模块84和第一响应模块85。各功能模块详细说明如下：

第一获取模块81，用于获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；

第二获取模块82，用于基于目标用户标识获取用户验证信息；

第三获取模块83，用于基于目标业务类型获取所述用户信息验证请求的基准验证字段，其中，基准验证字段为至少两个；

查询模块84，用于基于基准验证字段查询用户验证信息；

第一响应模块85，用于若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。

优选地，该用户信息验证装置还包括：

登录获取模块811，用于获取登录请求信息，登录请求信息包括目标用户标识和目标用户密码；

验证模块812，用于基于目标用户标识对目标用户密码进行验证；

发送模块813，用于若目标用户密码验证成功，则发送业务类型列表；

请求生成模块814，用于获取目标业务类型，基于目标用户标识和目标业务类型生成用户信息验证请求。

优选地，该用户信息验证装置还包括：

接口获取模块821，用于获取各个接口的用户验证数据表；

整合模块822，用于基于同一原始用户标识，整合用户验证数据表，得到用户验证信息。

优选地，该整合模块822还包括：

验证数据获取子模块8221，用于基于同一原始用户标识，在用户验证数据表中获取对应的用户验证数据，用户验证数据包括原始用户标识、验证内容和验证日期；

验证日期获取子模块8222，用于若同一原始用户标识中存在相同验证内容的用户验证数据，则获取相同验证内容的用户验证数据中的验证日期，作为目标验证日期；

验证日期整理子模块8223，用于对目标验证日期进行排序，获取排序后最新的目标验证日期和该最新的目标验证日期对应的验证内容，并将非最新的目标验证日期对应的用户验证数据删除；

验证信息整理子模块8224，用于汇总同一原始用户标识对应的用户验证数据，得到用户验证信息。

优选地，该用户信息验证装置还包括：

目标验证字段生成模块841，用于若存在至少一个所述基准验证字段在所述用户验证信息中查询不到相匹配的验证数据，则将对应的基准验证字段作为目标验证字段；

发送模块842，用于基于目标验证字段发送目标验证字段验证请求；

第二响应模块843，用于获取目标验证字段验证请求对应的目标验证信息，若目标验证信息验证通过，则响应用户信息验证请求。

优选地，该第二响应模块843包括：

安全等级获取子模块8431，用于基于目标业务类型获取业务安全等级；

身份验证子模块8432，用于基于业务安全等级和目标用户标识发送对应的用户身份验证请求；

校验子模块8433，用于获取用户身份校验信息，若用户身份校验信息验证通过，则用户信息验证请求验证通过。

关于用户信息验证装置的具体限定可以参见上文中对于用户信息验证方法的限定，在此不再赘述。上述用户信息验证装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图9所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储用户验证信息。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种用户信息验证方法。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；

基于目标用户标识获取用户验证信息；

基于目标业务类型获取用户信息验证请求的基准验证字段，其中，基准验证字段为至少两个；

基于基准验证字段查询用户验证信息；

若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

获取用户信息验证请求，用户信息验证请求包括目标用户标识和目标业务类型；

基于目标用户标识获取用户验证信息；

基于目标业务类型获取用户信息验证请求的基准验证字段，其中，基准验证字段为至少两个；

基于基准验证字段查询用户验证信息；

若每一基准验证字段都在用户验证信息中查询到相匹配的验证数据，则响应用户信息验证请求。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。

Claims (10)

1.一种用户信息验证方法，其特征在于，所述用户信息验证方法包括：

获取用户信息验证请求，所述用户信息验证请求包括目标用户标识和目标业务类型；

基于所述目标用户标识获取用户验证信息；

基于所述目标业务类型获取所述用户信息验证请求的基准验证字段，其中，所述基准验证字段为至少两个；

基于所述基准验证字段查询所述用户验证信息；

若每一所述基准验证字段都在所述用户验证信息中查询到相匹配的验证数据，则响应所述用户信息验证请求。

2.如权利要求1所述的用户信息验证方法，其特征在于，在所述获取用户信息验证请求的步骤之前，所述用户信息验证方法还包括：

获取登录请求信息，所述登录请求信息包括目标用户标识和目标用户密码；

基于所述目标用户标识对所述目标用户密码进行验证；

若所述目标用户密码验证成功，则发送业务类型列表；

获取所述目标业务类型，基于所述目标用户标识和所述目标业务类型生成所述用户信息验证请求。

3.如权利要求1所述的用户信息验证方法，其特征在于，在所述基于所述目标用户标识获取用户验证信息的步骤之前且在所述获取用户信息验证请求的步骤之后，所述用户信息验证方法还包括：

获取各个接口的用户验证数据表；

基于同一原始用户标识，整合所述用户验证数据表，得到所述用户验证信息。

4.如权利要求3所述的用户信息验证方法，其特征在于，所述基于同一原始用户标识，整合所述用户验证数据表，得到所述用户验证信息，包括：

基于所述同一原始用户标识，在所述用户验证数据表中获取对应的用户验证数据，所述用户验证数据包括原始用户标识、验证内容和验证日期；

若所述同一原始用户标识中存在相同验证内容的所述用户验证数据，则获取相同验证内容的所述用户验证数据中的所述验证日期，作为目标验证日期；

对目标验证日期进行排序，获取排序后最新的目标验证日期和该最新的目标验证日期对应的验证内容，并将非最新的目标验证日期对应的用户验证数据删除；

汇总所述同一原始用户标识对应的所述用户验证数据，得到所述用户验证信息。

5.如权利要求1所述的用户信息验证方法，其特征在于，在基于所述基准验证字段查询用户验证信息的步骤之后，所述用户信息验证方法还包括：

若存在至少一个所述基准验证字段在所述用户验证信息中查询不到相匹配的验证数据，则将对应的所述基准验证字段作为目标验证字段；

基于所述目标验证字段发送目标验证字段验证请求；

获取所述目标验证字段验证请求对应的目标验证信息，若所述目标验证信息验证通过，则响应所述用户信息验证请求。

6.如权利要求5所述的用户信息验证方法，其特征在于，所述响应所述用户信息验证请求，包括：

基于所述目标业务类型获取业务安全等级；

基于所述业务安全等级和所述目标用户标识发送对应的用户身份验证请求；

获取用户身份校验信息，若所述用户身份校验信息验证通过，则通过所述用户信息验证请求验证。

7.一种用户信息验证装置，其特征在于，包括：

第一获取模块，用于获取用户信息验证请求，所述用户信息验证请求包括目标用户标识和目标业务类型；

第二获取模块，用于基于所述目标用户标识获取用户验证信息；

第三获取模块，用于基于所述目标业务类型获取所述用户信息验证请求的基准验证字段，其中，所述基准验证字段为至少两个；

查询模块，用于基于所述基准验证字段查询用户验证信息；

第一响应模块，用于若每一所述基准验证字段都在所述用户验证信息中查询到相匹配的验证数据，则响应所述用户信息验证请求。

8.如权利要求7所述的用户信息验证装置，其特征在于，所述用户信息验证还包括：

登录获取模块，用于获取登录请求信息，所述登录请求信息包括目标用户标识和目标用户密码；

验证模块，用于基于所述目标用户标识对所述目标用户密码进行验证；

发送模块，用于若所述目标用户密码验证成功，则发送业务类型列表；

请求生成模块，用于获取目标业务类型，基于所述目标用户标识和目标业务类型生成用户信息验证请求。

9.一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6任一项所述用户信息验证方法的步骤。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述用户信息验证方法的步骤。