身份验证方法、系统、业务服务器和验证服务器与流程

本申请涉及互联网技术领域，特别涉及一种身份验证方法、系统、业务服务器和验证服务器。

背景技术：

随着互联网技术的不断发展，越来越多的用户可通过互联网进行交互活动或者获取服务。很多情况下，在用户进行互联网或者移动互联网活动中的某些场景中，例如注册、登录等场景中，需要验证用户身份，以确认业务操作是由用户本人发起的合法操作。目前，可通过语音或短信将验证码发送至用户终端，用户根据提示在相应的位置输入该验证码后，该验证码可通过互联网或移动互联网传送至后台服务器，然后由后台服务器验证用户填写的验证码与之前下发给用户的验证码是否一致，如果一致则通过验证。但是，这种方式中验证码在传输过程或者在达到手机后，容易被第三方或者木马截获，安全性较低，且由于短信的到达率不能保证、语音播放验证码容易记错，因此身份验证的成功率难以达到理想值，影响用户体验。

技术实现要素：

本申请旨在至少在一定程度上解决上述技术问题。

为此，本申请的第一个目的在于提出一种身份验证方法，能够有效提高身份验证的可靠性和安全性。

本申请的第二个目的在于提出另一种身份验证方法。

本申请的第三个目的在于提出一种业务服务器。

本申请的第四个目的在于提出另一种验证服务器。

本申请的第五个目的在于提出另一种身份验证系统。

为达上述目的，根据本申请第一方面实施例提出了一种身份验证方法，包括以下步骤：当通过网际网络接收到客户端发送的数据交互请求时，获取所述客户端对应的第一用户识别码；将所述第一用户识别码发送至验证服务器；从所述验证服务器获取与所述第一用户识别码对应的中间号码；将所述中间号码发送至所述客户端，以使所述客户端的用户通过电话通信网络向所述中间号码发起呼叫请求；接收验证服务器根据所述呼叫请求反馈的所述身份验 证的验证结果；根据所述验证结果处理所述数据交互请求。

本申请实施例的身份验证方法，在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，并由验证服务器根据呼叫请求得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

本申请第二方面实施例提供了另一种身份验证方法，包括以下步骤：接收业务服务器发送的第一用户识别码；为所述第一用户识别码分配对应的中间号码；将所述中间号码返回至所述业务服务器，以通过所述业务服务器将所述中间号码提供给用户的客户端；从电话通信网络获取向所述中间号码发起所述呼叫的第二用户识别码；验证所述第一用户识别码与所述第二用户识别码是否一致，并将验证结果返回至所述业务服务器。

本申请实施例的身份验证方法，可为业务服务器发送的第一用户识别码分配相应的中间号码，并通过业务服务器提供给用户的客户端，当中间号码接收到呼叫时，从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证所述第一用户识别码与所述第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

本申请第三方面实施例提供了一种业务服务器，包括：第一获取模块，用于当通过网际网络接收到客户端发送的数据交互请求时，获取所述客户端对应的第一用户识别码；第一发送模块，用于将所述第一用户识别码发送至验证服务器；第二获取模块，用于从所述验证服务器获取与所述第一用户识别码对应的中间号码；第二发送模块，用于将所述中间号码发送至所述客户端，以使所述客户端的用户通过电话通信网络向所述中间号码发起呼叫请求；第一接收模块，用于接收验证服务器根据所述呼叫请求反馈的所述身份验证的验证结果；处理模块，用于根据所述验证结果处理所述数据交互请求。

本申请实施例的业务服务器，在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，并由验证服务器根据呼叫请求得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接 入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

本申请第四方面实施例提供了一种验证服务器，包括：接收模块，用于接收业务服务器发送的第一用户识别码；分配模块，用于为所述第一用户识别码分配对应的中间号码；返回模块，用于将所述中间号码返回至所述业务服务器，以通过所述业务服务器将所述中间号码提供给用户的客户端；获取模块，用于从电话通信网络获取向所述中间号码发起所述呼叫的第二用户识别码；验证模块，用于验证所述第一用户识别码与所述第二用户识别码是否一致，并将验证结果返回至所述业务服务器。

本申请实施例的业务服务器，可为业务服务器发送的第一用户识别码分配相应的中间号码，并通过业务服务器提供给用户的客户端，当中间号码接收到呼叫时，从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证所述第一用户识别码与所述第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

本申请第五方面实施例提供了一种身份验证系统，包括：客户端、本申请第三申请实施例的业务服务器以及本申请第四方面实施例的验证服务器。

本申请实施例的身份验证系统，业务服务器在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，验证服务器可从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证所述第一用户识别码与所述第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为根据本申请一个实施例的身份验证方法的流程图；

图2为根据本申请又一个实施例的身份验证方法的流程图；

图3为根据本申请另一个实施例的身份验证方法的流程图；

图4为根据本申请一个实施例的验证服务器的同步位置更新的示意图；

图5为根据本申请一个实施例的业务服务器的结构示意图；

图6为根据本申请另一个实施例的业务服务器的结构示意图；

图7为根据本申请又一个实施例的业务服务器的结构示意图；

图8为根据本申请一个实施例的验证服务器的结构示意图；

图9为根据本申请一个实施例的身份验证系统的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

由于网际网络(如互联网，移动互联网等)是一个开放的网络，接入门槛非常低，其安全性相对而言不是很高，因此，在身份验证过程时通过网际网络传输验证码时，存在安全隐患。因此，为了解决上述问题，本申请实施例提出了一种身份验证方法、业务服务器、验证服务器以及身份验证系统。

下面参考附图描述根据本申请实施例的身份验证方法、业务服务器、验证服务器以及身份验证系统。

图1为根据本申请一个实施例的身份验证方法的流程图。

如图1所示，根据本申请实施例的身份验证方法，包括：

S101，当通过网际网络接收到客户端发送的数据交互请求时，获取客户端对应的第一用户识别码。

其中，网际网络可为互联网或移动互联网，例如，基于IP(Internet Protocol，网络之间互连的协议)协议的IP网络。

数据交互请求可以是注册请求、登录请求、用户信息变更请求、支付请求、转账请求、查询请求等。其中，数据交互请求可以HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求的方式发送。

客户端对应的第一用户识别码为客户端用户在电话通信网络中的身份标识信息，用于在电话通信网络中唯一标识客户端用户。举例来说，第一用户识别码可以是手机号码、MSIN(Mobile Subscriber Identification Number，移动用户识别号码)，IMSI(国际移动用户识别 码)等。

其中，电话通信网络是由信令网和话务网组成的一个封闭的网络。

具体地，客户端可根据用户的操作向业务服务器发送相应的数据交互请求。业务服务器在接收到客户端发送的数据交互请求之后，可获取该客户端的用户的第一用户识别码。

举例来说，当用户通过客户端发起支付请求时，客户端可向业务服务器发送支付请求，然后由业务服务器发起后续验证过程。

在本申请的一个实施例中，业务服务器可向客户端发送用户识别码输入请求，以使客户端的用户输入第一用户识别码。具体地，业务服务器在接收到数据交互请求之后，可向客户端发送用户识别码输入请求，客户端在接收到用户识别码输入请求后可提供用户识别码输入界面，并提示用户进行输入，并将用户输入的用户识别码返回至业务服务器。

在本申请的另一个实施例中，业务服务器从用户数据库中提取客户端的用户的第一用户识别码。其中，业务服务器可预先根据用户的帐号信息存储与用户帐号信息相对应的用户识别码，从而在接收到数据交互请求之后，可根据接收到的数据交互请求对应的帐号信息在用户数据中查找该相应的用户识别码。举例来说，用户在注册时，或者在注册之后提交了手机号码，则业务服务器可保存该用户的帐号与手机号码的对应关系。当接收到来自该用户的帐号的数据交互请求时，即可根据账号提取对应的手机号码。

S102，将第一用户识别码发送至验证服务器。

其中，验证服务器为对用户进行身份验证处理的服务器，业务服务器是用于为客户端提供相应业务的服务器。业务服务器可通过网际网络与验证服务器进行通信。

S103，从验证服务器获取与第一用户识别码对应的中间号码。

在本申请的一个实施例中，当验证服务器接收到业务服务器发送的第一用户识别码时，可为第一用户识别码分配对应的中间号码，并返回给验证服务器。其中，中间号码可为手机号码、特服号、固定电话号码或者网络电话号码等。

在本申请的实施例中，中间号码可为固定号码或者临时号码。具体地，验证服务器可将预设的号码作为第一用户识别码对应的中间号码，即将一个预先设定的一个固定号码作为中间号码。另外，验证服务器也可从预设的号码池中随机选择一个临时号码，并将临时号码作为第一用户识别码对应的中间号码。其中，预设的号码池可为业务服务器从通信运营商处预先申请的。

S104，将中间号码发送至客户端，以使客户端的用户通过电话通信网络向中间号码发起呼叫请求。

业务服务器从验证服务器获取与第一用户识别码对应的中间号码之后，可将该中间号码发送至客户端。客户端可显示该中间号码，从而，客户端的用户可通过电话通信网络向该中 间号码发起呼叫请求。

应当理解，本申请实施例中用户所使用的发起呼叫的设备可以是客户端所在的设备，也可以是用户的其他呼叫设备。举例来说，如果客户端所在的设备为手机，则客户端可在手机中渲染中间号码对应的呼叫界面，从而用户可通过触发拨号按键直接向中间号码发起呼叫。如果客户端所在的设备为电脑，则用户可使用手机向客户端显示的中间号码发起呼叫。

S105，接收验证服务器根据呼叫请求反馈的身份验证的验证结果。

在本申请的实施例中，验证服务器可从电话通信网络获取向中间号码发起呼叫的第二用户识别码，并验证第一用户识别码与第二用户识别码是否一致，然后将验证结果返回至业务服务器。

S106，根据验证结果处理数据交互请求。

如果验证服务器返回的验证结果为第一用户识别码与第二用户识别码一致，则判断客户端的用户通过验证(本次呼叫由用户本人发起)，可响应该数据交互请求；如果验证服务器返回的验证结果为第一用户识别码与第二用户识别码不一致，则判断客户端的用户未通过验证(本次呼叫并非由用户本人发起)，可拒绝响应该数据交互请求，并提示客户端的用户验证失败。

本申请实施例的身份验证方法，在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，并由验证服务器根据呼叫请求得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

此外，通过电话呼叫进行验证，通话与验证可实时同步完成，提高了验证效率，提升了用户的验证体验。

图2为根据本申请又一个实施例的身份验证方法的流程图。

如图2所示，根据本申请实施例的身份验证方法，包括：

S201，当通过网际网络接收到客户端发送的数据交互请求时，确定数据交互请求对应的风险等级。

在本申请的实施例中，业务服务器可根据数据交互请求的请求类型确定相应的风险等级。不同请求类型对应的风险等级可为系统默认值，也可由用户根据需要预先设定。举例来说，如果数据交互请求为大额支付请求，则风险等级可为高级；如果数据交互请求为查询请求，则风险等级可为低级；如果数据交互请求为用户信息修改请求，则风险等级可为中级。

S202，如果数据交互请求对应的风险等级高于预设等级，则获取客户端对应的第一用户识别码。

其中，预设等级可为默认设置，或者由用户设置。举例来说，预设等级可为中级。

由此，当数据交互请求对应的风险等级高于预设等级时，业务服务器才获取客户端对应的第一用户识别码，并发起后续的验证流程。

S203，将第一用户识别码发送至验证服务器。

S204，从验证服务器获取与第一用户识别码对应的中间号码。

S205，将中间号码发送至客户端，以使客户端的用户通过电话通信网络向中间号码发起呼叫请求。

S206，接收验证服务器根据呼叫请求反馈的身份验证的验证结果。

S207，根据验证结果处理数据交互请求。

S203-S207与图1所示实施例中S102-S106相同，因此可参照图1所示实施例。

在本申请的一个实施例中，在对客户端的用户的身份进行验证时，除了考虑验证服务器返回的验证结果之外，还可考虑呼叫过程中用户的交互操作进行验证。

因此，本申请的实施例还可包括：接收验证服务器发送的呼叫过程中的交互记录；根据交互记录对客户端的用户进行身份验证。也就是说，验证服务器可记录呼叫过程中用户的交互记录，并返回至业务服务器，业务服务器可判断交互记录是否符合预设交互要求。如果交互记录符合预设交互要求、且验证服务器返回的验证结果为第一用户识别码与第二用户识别码一致，则判断用户的身份验证通过，否则，二者中有任一条件不满足，则判断用户的身份验证未通过。

其中，可根据不同的安全验证等级设定用户在呼叫过程中的交互场景。举例说明如下：

场景一

低等级验证：向中间号码发起的呼叫被接听后，验证服务器播放预设提示音，播放完毕之后，通话结束。在此过程中，客户端的用户不需要进行操作。通话完成，即表示交互记录符合预设交互要求。

场景二

中等级验证：向中间号码发起的呼叫被接听后，验证服务器播放提示用户按相应的按键的语音，并记录用户的按键操作。如果用户的按键操作与提示语音一致，则表示交互记录符合预设交互要求。

场景三

高等级验证：向中间号码发起的呼叫被接听后，验证服务器提示用户输入相应字符串的语音，并记录用户输入的字符串。如果用户输入的字符串与提示语音中的字符串一致，则表 示交互记录符合预设交互要求。

其中，安全验证等级可根据身份验证请求对应的用户的身份、客户端的安全环境等设定。例如，如果用户为正常状态，客户端使用环境安全，则选择低等级验证；如果用户为异常状态(如异地登录登)，则选择中等级验证；如果用户被举报，或者客户端使用环境不安全(如被病毒或木马恶意攻击的环境)则选择高等级验证。

应当理解，判断交互记录是否符合预设交互要求也可由验证服务器执行，然后由验证服务器根据判断结果以及对第一用户识别码与第二用户识别码的验证结果判断用户的身份验证是否通过，并将判断结果返回至业务服务器。

本申请实施例的身份验证方法，在接收到客户的数据交互请求时，可根据数据交互请求对应的风险等级判断是否发起验证过程，从而能够过滤掉不需身份验证的情况，能够有效提高数据交互请求的相应速度。

为了实现上述实施例，本申请还提出另一种身份验证方法。

图3为根据本申请另一个实施例的身份验证方法的流程图。

如图3所示，根据本申请实施例的身份验证方法，包括：

S301，接收业务服务器发送的第一用户识别码。

其中，验证服务器可通过网际网络接收业务服务器发送的第一用户识别码。第一用户识别码为客户端用户在电话通信网络中的身份标识信息，用于在电话通信网络中唯一标识客户端用户。举例来说，第一用户识别码可以是手机号码、MSIN(Mobile Subscriber Identification Number，移动用户识别号码)，IMSI(国际移动用户识别码)等。

其中，验证服务器为对用户进行身份验证处理的服务器，业务服务器是用于为客户端提供相应业务的服务器。业务服务器可通过网际网络与验证服务器进行通信。

其中，网际网络可为互联网或移动互联网，例如，基于IP(Internet Protocol，网络之间互连的协议)协议的IP网络。电话通信网络是由信令网和话务网组成的一个封闭的网络。

具体地，客户端可根据用户的操作向业务服务器发送相应的数据交互请求。业务服务器在接收到客户端发送的数据交互请求之后，可获取该客户端的用户的第一用户识别码。举例来说，当用户通过客户端发起支付请求时，客户端可向业务服务器发送支付请求，然后由业务服务器发起后续验证过程。

其中，数据交互请求可以是注册请求、登录请求、用户信息变更请求、支付请求、转账请求、查询请求等。其中，数据交互请求可以HTTP(Hyper Text Transfer Protocol，超文本传输协议)请求的方式发送。

在本申请的实施例中，业务服务器可向客户端发送用户识别码输入请求，以使客户端的用户输入第一用户识别码。或者，业务服务器从用户数据库中提取客户端的用户的第一用户 识别码。

S302，为第一用户识别码分配对应的中间号码。

其中，中间号码可为手机号码、特服号、固定电话号码或者网络电话号码等。

在本申请的实施例中，中间号码可为固定号码或者临时号码。

在本申请的一个实施例中，验证服务器可将预设的号码作为第一用户识别码对应的中间号码，即将一个预先设定的一个固定号码作为中间号码。

如果以固定号码作为中间号码，则需要将电话通信网络中该固定号码的路由指向验证服务器，以使对该固定号码的呼叫能够到达验证服务器。

在本申请的另一个实施例中，验证服务器也可从预设的号码池中随机选择一个临时号码，并将临时号码作为第一用户识别码对应的中间号码。其中，预设的号码池可为业务服务器从通信运营商处预先申请的。

如果以临时号码作为中间号码，则验证服务器在选择临时号码后，需要进行同步位置更新。即如图4所示，通知电话通信网络中的HLR(Home Location Register，归属位置寄存器)被选择的临时号码的路由指向验证服务器。从而，对该临时号码的呼叫能够到达验证服务器。使其中，验证服务器通过HSTP/LSTP(High/Low Signal Transfer Point，传统通信网中的信令转接点)与HLR发送进行通信。

S303，将中间号码返回至业务服务器，以通过业务服务器将中间号码提供给用户的客户端。

业务服务器从验证服务器获取与第一用户识别码对应的中间号码之后，可将该中间号码发送至用户的客户端。客户端将该中间号码显示给用户，从而，客户端的用户可通过电话通信网络向该中间号码发起呼叫请求。

S304，从电话通信网络获取向中间号码发起呼叫的第二用户识别码。

由于中间号码的路由指向验证服务器，因此，当中间号码被呼叫时，验证服务器可接收到呼叫请求，并可从电话通信网络中获取向中间号码发起呼叫的号码，即第二用户识别码。

S305，验证第一用户识别码与第二用户识别码是否一致，并将验证结果返回至业务服务器。

如果验证服务器的验证结果为第一用户识别码与第二用户识别码一致，则可判断客户端的用户通过验证(本次呼叫由用户本人发起)，业务服务器可响应该数据交互请求；如果验证服务器的验证结果为第一用户识别码与第二用户识别码不一致，则可判断客户端的用户未通过验证(本次呼叫并非由用户本人发起)，业务服务器可拒绝响应该数据交互请求，并提示客户端的用户验证失败。

在本申请的一个实施例中，验证服务器还可记录呼叫过程中用户的交互记录，并判断该 交互记录是否符合预设交互要求。如果交互记录符合预设交互要求、且验证服务器返回的验证结果为第一用户识别码与第二用户识别码一致，则判断用户的身份验证通过，否则，二者中有任一条件不满足，则判断用户的身份验证未通过。然后将验证结果发送至业务服务器。

当然，验证服务器也可将呼叫过程中用户的交互记录发送之业务服务器，然后由业务服务器根据用户识别码的比对结果和交互记录的判断结果判断用户的身份验证是否通过。

本申请实施例的身份验证方法，可为业务服务器发送的第一用户识别码分配相应的中间号码，并通过业务服务器提供给用户的客户端，当中间号码接收到呼叫时，从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证第一用户识别码与第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

应当理解，在本申请的实施例中，业务服务器与验证服务器可为同一服务器，也可为不同的服务器。

为了实现上述实施例，本申请还提出一种业务服务器。

图5为根据本申请一个实施例的业务服务器的结构示意图。

如图5所示，根据本申请实施例的业务服务器100，包括：第一获取模块110、第一发送模块120、第二获取模块130、第二发送模块140、第一接收模块150和处理模块160。

具体地，第一获取模块110用于当通过网际网络接收到客户端发送的数据交互请求时，获取客户端对应的第一用户识别码。

其中，客户端可根据用户的操作向业务服务器发送相应的数据交互请求。第一获取模块110在接收到客户端发送的数据交互请求之后，可获取该客户端的用户的第一用户识别码。

举例来说，当用户通过客户端发起支付请求时，客户端可向业务服务器发送支付请求，然后由业务服务器发起后续验证过程。

在本申请的一个实施例中，第一获取模块110可用于向客户端发送用户识别码输入请求，以使客户端的用户输入第一用户识别码。具体地，第一获取模块110在接收到数据交互请求之后，可向客户端发送用户识别码输入请求，客户端在接收到用户识别码输入请求后可提供用户识别码输入界面，并提示用户进行输入，并将用户输入的用户识别码返回至业务服务器。

在本申请的另一个实施例中，第一获取模块110可用于从用户数据库中提取客户端的用户的第一用户识别码。其中，业务服务器可预先根据用户的帐号信息存储与用户帐号信息相对应的用户识别码，从而在接收到数据交互请求之后，第一获取模块110可根据接收到的数 据交互请求对应的帐号信息在用户数据中查找该相应的用户识别码。举例来说，用户在注册时，或者在注册之后提交了手机号码，则业务服务器可保存该用户的帐号与手机号码的对应关系。当接收到来自该用户的帐号的数据交互请求时，即可根据账号提取对应的手机号码。

第一发送模块120用于将第一用户识别码发送至验证服务器。

第二获取模块130用于从验证服务器获取与第一用户识别码对应的中间号码。

在本申请的一个实施例中，当验证服务器接收到业务服务器发送的第一用户识别码时，可为第一用户识别码分配对应的中间号码，并返回给验证服务器。其中，中间号码可为手机号码、特服号、固定电话号码或者网络电话号码等。

在本申请的实施例中，中间号码可为固定号码或者临时号码。具体地，验证服务器可将预设的号码作为第一用户识别码对应的中间号码，即将一个预先设定的一个固定号码作为中间号码。另外，验证服务器也可从预设的号码池中随机选择一个临时号码，并将临时号码作为第一用户识别码对应的中间号码。其中，预设的号码池可为业务服务器从通信运营商处预先申请的。

第二发送模块140用于将中间号码发送至客户端，以使客户端的用户通过电话通信网络向中间号码发起呼叫请求。

第二获取模块130从验证服务器获取与第一用户识别码对应的中间号码之后，第二发送模块140可将该中间号码发送至客户端。客户端可显示该中间号码，从而，客户端的用户可通过电话通信网络向该中间号码发起呼叫请求。

应当理解，本申请实施例中用户所使用的发起呼叫的设备可以是客户端所在的设备，也可以是用户的其他呼叫设备。举例来说，如果客户端所在的设备为手机，则客户端可在手机中渲染中间号码对应的呼叫界面，从而用户可通过触发拨号按键直接向中间号码发起呼叫。如果客户端所在的设备为电脑，则用户可使用手机向客户端显示的中间号码发起呼叫。

第一接收模块150用于接收验证服务器根据呼叫请求反馈的身份验证的验证结果。

在本申请的实施例中，验证服务器可从电话通信网络获取向中间号码发起呼叫的第二用户识别码，并验证第一用户识别码与第二用户识别码是否一致，然后将验证结果返回至业务服务器。

处理模块160用于根据验证结果处理数据交互请求。

如果验证服务器返回的验证结果为第一用户识别码与第二用户识别码一致，则判断客户端的用户通过验证(本次呼叫由用户本人发起)，处理模块160可响应该数据交互请求；如果验证服务器返回的验证结果为第一用户识别码与第二用户识别码不一致，则判断客户端的用户未通过验证(本次呼叫并非由用户本人发起)，处理模块160可拒绝响应该数据交互请求，并提示客户端的用户验证失败。

本申请实施例的业务服务器，在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，并由验证服务器根据呼叫请求得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

图6为根据本申请另一个实施例的业务服务器的结构示意图。

如图6所示，本申请实施例的业务服务器100，包括：第一获取模块110、第一发送模块120、第二获取模块130、第二发送模块140、第一接收模块150、处理模块160和确定模块170。

具体地，第一获取模块110、第一发送模块120、第二获取模块130、第二发送模块140、第一接收模块150和处理模块160，可参照图5所示实施例。

确定模块170用于当通过网际网络接收到客户端发送的数据交互请求时，确定数据交互请求对应的风险等级。

在本申请的实施例中，确定模块170可根据数据交互请求的请求类型确定相应的风险等级。不同请求类型对应的风险等级可为系统默认值，也可由用户根据需要预先设定。举例来说，如果数据交互请求为大额支付请求，则风险等级可为高级；如果数据交互请求为查询请求，则风险等级可为低级；如果数据交互请求为用户信息修改请求，则风险等级可为中级。

其中，第一获取模块110用于在数据交互请求对应的风险等级高于预设等级时，获取客户端的用户的第一用户识别码。

其中，预设等级可为默认设置，或者由用户设置。举例来说，预设等级可为中级。

由此，当数据交互请求对应的风险等级高于预设等级时，第一获取模块110才获取客户端对应的第一用户识别码，并发起后续的验证流程。

本申请实施例的业务服务器，在接收到客户的数据交互请求时，可根据数据交互请求对应的风险等级判断是否发起验证过程，从而能够过滤掉不需身份验证的情况，能够有效提高数据交互请求的相应速度。

图7为根据本申请又一个实施例的业务服务器的结构示意图。

如图7所示，本申请实施例的业务服务器100，包括：第一获取模块110、第一发送模块120、第二获取模块130、第二发送模块140、第一接收模块150、处理模块160、确定模块170、第二接收模块180和验证模块190。

具体地，第一获取模块110、第一发送模块120、第二获取模块130、第二发送模块140、 第一接收模块150、处理模块160和确定模块170可参照图6所示实施例。

第二接收模块180用于接收验证服务器发送的呼叫过程中的交互记录。

其中，验证服务器可记录呼叫过程中用户的交互记录，并返回至业务服务器。

验证模块190用于根据交互记录对客户端的用户进行身份验证。

具体地，验证模块190可判断交互记录是否符合预设交互要求。如果交互记录符合预设交互要求、且验证服务器返回的验证结果为第一用户识别码与第二用户识别码一致，则判断用户的身份验证通过，否则，二者中有任一条件不满足，则判断用户的身份验证未通过。

其中，可根据不同的安全验证等级设定用户在呼叫过程中的交互场景。举例说明如下：

场景一

低等级验证：向中间号码发起的呼叫被接听后，验证服务器播放预设提示音，播放完毕之后，通话结束。在此过程中，客户端的用户不需要进行操作。通话完成，即表示交互记录符合预设交互要求。

场景二

中等级验证：向中间号码发起的呼叫被接听后，验证服务器播放提示用户按相应的按键的语音，并记录用户的按键操作。如果用户的按键操作与提示语音一致，则表示交互记录符合预设交互要求。

场景三

高等级验证：向中间号码发起的呼叫被接听后，验证服务器提示用户输入相应字符串的语音，并记录用户输入的字符串。如果用户输入的字符串与提示语音中的字符串一致，则表示交互记录符合预设交互要求。

其中，安全验证等级可根据身份验证请求对应的用户的身份、客户端的安全环境等设定。例如，如果用户为正常状态，客户端使用环境安全，则选择低等级验证；如果用户为异常状态(如异地登录登)，则选择中等级验证；如果用户被举报，或者客户端使用环境不安全(如被病毒或木马恶意攻击的环境)则选择高等级验证。

为了实现上述实施例，本申请还提出一种验证服务器。

图8为根据本申请一个实施例的验证服务器的结构示意图。

如图8，根据本申请实施例的验证服务器200，包括：接收模块210、分配模块220、返回模块230、获取模块240和验证模块250。

具体地，接收模块210用于接收业务服务器发送的第一用户识别码。

接收模块210可通过网际网络接收业务服务器发送的第一用户识别码。

其中，客户端可根据用户的操作向业务服务器发送相应的数据交互请求。业务服务器在接收到客户端发送的数据交互请求之后，可获取该客户端的用户的第一用户识别码。举例来 说，当用户通过客户端发起支付请求时，客户端可向业务服务器发送支付请求，然后由业务服务器发起后续验证过程。

分配模块220用于为第一用户识别码分配对应的中间号码。

其中，中间号码可为手机号码、特服号、固定电话号码或者网络电话号码等。

在本申请的实施例中，中间号码可为固定号码或者临时号码。

在本申请的一个实施例中，分配模块220可用于将预设的号码作为第一用户识别码对应的中间号码，即将一个预先设定的一个固定号码作为中间号码。

如果以固定号码作为中间号码，则需要将电话通信网络中该固定号码的路由指向验证服务器，以使对该固定号码的呼叫能够到达验证服务器。

在本申请的另一个实施例中，分配模块220也可用于从预设的号码池中随机选择一个临时号码，并将临时号码作为第一用户识别码对应的中间号码。其中，预设的号码池可为业务服务器从通信运营商处预先申请的。

如果以临时号码作为中间号码，则验证服务器在选择临时号码后，需要进行同步位置更新。即如图4所示，通知电话通信网络中的HLR(Home Location Register，归属位置寄存器)被选择的临时号码的路由指向验证服务器。从而，对该临时号码的呼叫能够到达验证服务器。使其中，验证服务器通过HSTP/LSTP(High/Low Signal Transfer Point，传统通信网中的信令转接点)与HLR发送进行通信。

返回模块230用于将中间号码返回至业务服务器，以通过业务服务器将中间号码提供给用户的客户端。

业务服务器从验证服务器获取与第一用户识别码对应的中间号码之后，可将该中间号码发送至用户的客户端。客户端将该中间号码显示给用户，从而，客户端的用户可通过电话通信网络向该中间号码发起呼叫请求。

获取模块240用于从电话通信网络获取向中间号码发起呼叫的第二用户识别码。

由于中间号码的路由指向验证服务器，因此，当中间号码被呼叫时，验证服务器可接收到呼叫请求，获取模块240可从电话通信网络中获取向中间号码发起呼叫的号码，即第二用户识别码。

验证模块250用于验证第一用户识别码与第二用户识别码是否一致，并将验证结果返回至业务服务器。

如验证模块250的验证结果为第一用户识别码与第二用户识别码一致，则可判断客户端的用户通过验证(本次呼叫由用户本人发起)，业务服务器可响应该数据交互请求；如果验证模块250的验证结果为第一用户识别码与第二用户识别码不一致，则可判断客户端的用户未通过验证(本次呼叫并非由用户本人发起)，业务服务器可拒绝响应该数据交互请求，并 提示客户端的用户验证失败。

在本申请的一个实施例中，验证模块250还可记录呼叫过程中用户的交互记录，并判断该交互记录是否符合预设交互要求。如果交互记录符合预设交互要求、且验证模块250返回的验证结果为第一用户识别码与第二用户识别码一致，则判断用户的身份验证通过，否则，二者中有任一条件不满足，则判断用户的身份验证未通过。然后将验证结果发送至业务服务器。

本申请实施例的验证服务器，可为业务服务器发送的第一用户识别码分配相应的中间号码，并通过业务服务器提供给用户的客户端，当中间号码接收到呼叫时，从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证第一用户识别码与第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

为了实现上述实施例，本申请还提出一种身份验证系统。

图9为根据本申请一个实施例的身份验证系统的结构示意图。

如图9所示，根据本申请实施例的身份验证系统，包括：业务服务器100、验证服务器200和客户端300。

其中，业务服务器100可为本申请任一实施例的业务服务器。

验证服务器200可为本申请任一实施例的验证服务器。

客户端300可为WEB页面端、APP端或WAP页面端等。

本申请实施例的身份验证系统，业务服务器在接收到客户端的数据交互请求时，可获取客户端对应的第一用户识别码，并从验证服务器获取与第一用户识别码相应的中间号码发送之客户端进行显示，以使客户端的用户通过电话通信网络向中间号码发起呼叫，验证服务器可从电话通信网络获取向中间号码发起呼叫的第二用户标识码，并通过验证第一用户识别码与第二用户识别码是否一致得到验证结果。该实施例将电话通信网络的封闭性与网际网络的开放性特点相结合，而基于电话通信网络封闭性，电话通信网络相对于网际网络来说接入门槛较高，不易被外界接入，因此将高安全性的电话通信网络应用到传统的网际网络中的身份验证，且将身份验证过程从异步流程变成一个同步的流程，有效提高了身份验证的可靠性和安全性。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根 据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的 是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本申请的实施例，本领域的普通技术人员可以理解：在不脱离本申请的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本申请的范围由权利要求及其等同限定。