CN108650098B - 用户自定义验证方式的方法及装置 - Google Patents

Abstract

本说明书实施例提供一种用户自定义验证方式的方法和装置。在设置阶段，接收用户针对某项业务而设置的验证方式，从而允许用户根据自己对于某项业务的重要性判断，自己定义该项业务所需的核身方式。在用户使用业务的阶段，客户端针对本次业务请求事件，向服务端查询用户针对该业务设置的验证方式，并依据这样的验证方式对用户进行核身验证。

Description

用户自定义验证方式的方法及装置

技术领域

本说明书一个或多个实施例涉及计算机技术领域，尤其涉及安全核身和身份认证。

背景技术

随着计算机和互联网技术的发展，各种客户端应用和App的种类、数量与日俱增，涉及的日用场景也越来越丰富，生活中的各方面事务都可以通过各种客户端应用和App来实现。随着这些应用和App的使用场景和使用频率越来越高，也带来越来越多的不安全因素，例如不法分子盗用别人的账号进行支付、转账、发信息等。因此，安全核身和身份验证越来越重要。

常规技术中，一般的应用或App是采用单一的安全验证方式来验证用户身份，例如通过交易密码，或者短信验证，或者指纹等方式进行身份验证。但是这样的验证方式仍然比较单薄。如果手机或者密码被盗，信息很容易就泄露了。

因此，希望能有改进的方案，能够更加有效地对用户进行安全核身和身份验证。

发明内容

本说明书一个或多个实施例描述了一种方法和装置，允许用户针对不同业务，设置不同的验证方式，从而满足用户对核身验证的安全要求。

根据第一方面，提供了一种设置验证方式的方法，该方法在客户端执行，该方法包括：

响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；

响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作；

接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式；

向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。

根据一种可能的设计，在向服务端发送设置信息之前，还根据***设置的验证方式，对用户身份进行验证。

在一个实施例中，上述验证方式选项可以包括：针对所述第一业务推荐的多个验证方式；或者所述用户已通过验证的多个验证方式。

在一个实施例中，用户可以从以下验证方式中进行选择：交易密码验证，短信验证，人脸验证，指纹验证，声纹验证。

根据第二方面，提供一种设置验证方式的方法，该方法在服务端执行，该方法包括：

接收设置信息，所述设置信息至少包括用户的信息，第一业务的信息，以及至少一个验证方式的信息，其中所述至少一个验证方式由所述用户针对所述第一业务而设置；

针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系。

在一种可能的设计中，采用多级映射表存储上述关联关系，所述多级映射表包括第一级表项、第二级表项和第三级表项，所述第一级表项用于存储多个用户的用户信息，第二级表项用于存储各个用户的可用业务的信息，第三级表项用于存储各个用户针对各个可用业务设置的验证方式信息。

根据第三方面，提供一种安全验证的方法，该方法在客户端执行，包括：

响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

从服务端获取至少一个验证方式，所述至少一个验证方式由所述用户针对所述业务请求事件对应的业务而设置；

采用所述至少一个验证方式对用户身份进行验证。

在一种实施方式中，客户端包括业务平台和验证平台，相应地，向服务端发出查询请求具体包括：

响应于所述业务请求事件，所述业务平台用所述业务请求事件的事件信息向服务端请求事件验证ID；

所述业务平台从所述服务端获得所述事件验证ID，并将该事件验证ID发送给所述验证平台；

所述验证平台基于所述事件验证ID向所述服务端发出所述查询请求。

根据第四方面，提供一种用于安全验证的方法，该方法在服务端执行，用于辅助客户端进行安全验证，所述方法包括：

接收所述客户端响应于用户的业务请求事件而发送的查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

根据所述查询请求，查询所述用户针对所述业务请求事件对应的业务而设置的至少一个验证方式；

将所述至少一个验证方式发送给所述客户端。

在一种实施方式中，客户端包括业务平台和验证平台，相应地，接收查询请求具体包括：

接收所述业务平台响应于用户的业务请求事件而发送的事件信息，基于所述事件信息为所述业务请求事件生成事件验证ID；

将所述事件验证ID发送给所述业务平台；

从所述验证平台接收所述查询请求，所述查询请求基于所述事件验证ID而产生。

在一个实施例中，通过以下方式查询用户针对所述业务请求事件对应的业务而设置的至少一个验证方式：

根据查询请求所基于的事件验证ID，获取该事件验证ID所对应的业务请求事件的事件信息；

确定根据业务请求事件所对应的用户和业务；

在预先存储的设置信息中查询所述用户针对所述业务而设置的至少一个验证方式。

根据第五方面，提供一种设置验证方式的装置，该装置位于客户端，并包括：

第一提供单元，配置为响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；

第二提供单元，配置为响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作；

接收单元，配置为接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式；

发送单元，配置为向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。

根据第六方面，提供一种设置验证方式的装置，该装置位于服务端，并包括：

接收单元，配置为接收设置信息，所述设置信息至少包括用户的信息，第一业务的信息，以及至少一个验证方式的信息，其中所述至少一个验证方式由所述用户针对所述第一业务而设置；

存储单元，配置为针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系。

根据第七方面，提供一种安全验证的装置，该装置位于客户端，包括：

请求单元，配置为响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

获取单元，配置为从服务端获取至少一个验证方式，所述至少一个验证方式由所述用户针对所述业务请求事件对应的业务而设置；

验证单元，配置为采用所述至少一个验证方式对用户身份进行验证。

根据第八方面，提供一种用于安全验证的装置，该装置位于服务端，用于辅助客户端进行安全验证，所述装置包括：

接收单元，配置为接收所述客户端响应于用户的业务请求事件而发送的查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

查询单元，配置为根据所述查询请求，查询所述用户针对所述业务请求事件对应的业务而设置的至少一个验证方式；

发送单元，配置为将所述至少一个验证方式发送给所述客户端。

根据第九方面，提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面到第四方面的方法。

根据第十方面，提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一方面到第四方面的方法。

通过本说明书实施例的方法和装置，允许用户根据自己对于某项业务的重要性判断，自己定义该项业务所需的核身方式。在用户使用业务的阶段，客户端针对本次业务请求事件，向服务端查询用户针对该业务设置的验证方式，并依据这样的验证方式对用户进行核身验证。如此，实现用户针对各种业务自定义验证方式的过程。

附图说明

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

图1为本说明书披露的一个实施例的实施场景示意图；

图2示出根据一个实施例的设置验证方式的方法流程图；

图3A示出提供给用户的业务选项的一个示意性界面；

图3B示出提供给用户的验证方式选项的一个示意性界面；

图4示出根据一个实施例的映射表的示意图；

图5示出根据一个实施例的安全验证的方法；

图6示出根据一个实施例的在服务端执行的用于辅助客户端进行安全验证的方法；

图7示出根据一个实施例的安全验证的过程；

图8示出根据一个实施例的在客户端设置验证方式的装置的示意性框图；

图9示出根据一个实施例的在服务端设置验证方式的装置的示意性框图；

图10示出根据一个实施例的在客户端的安全验证装置的示意性框图；

图11示出根据一个实施例的在服务端的安全验证装置的示意性框图。

具体实施方式

下面结合附图，对本说明书提供的方案进行描述。

图1为本说明书披露的一个实施例的实施场景示意图。如图1所示，实施例在客户端和服务端之间执行。客户端包括终端设备和安装在其中的各种客户端应用和App，例如支付宝App；服务端与客户端所提供的服务相对应。对于许多应用服务来说，会采用多个服务器分别执行对应功能，例如采用业务服务器执行业务功能，采用存储服务器来进行大规模数据的存储，采用安全服务器执行安全功能等。图1服务端中的服务器例如可以是支付宝采用的云端安全服务器。

客户端与服务端之间的交互分为两个阶段。在第一阶段，客户端向用户提供针对不同业务的验证方式选项。如此，用户可以根据自己对于某项业务的重要性判断，自己定义该项业务所需的核身方式。例如如图1所示，用户可以针对贷款业务，设置交易密码、短信和人脸三种验证方式。用户自定义的验证方式可以存储在服务端，例如安全服务器中。

在第二阶段，用户使用业务，产生业务请求。例如，用户准备申请贷款，从而产生贷款请求。此时，客户端针对本次业务请求事件，向服务端查询所需的验证方式。服务端查询该用户针对该业务所设置的验证方式，将验证方式返回给客户端。例如，服务端查询到，该用户之前针对贷款业务设置了交易密码、短信和人脸三种核身方式，于是将这三种验证方式返回客户端。客户端于是依次对用户进行交易密码、短信和人脸的验证。如此，实现用户针对各种业务自定义验证方式的过程。下面描述以上过程的具体执行方式。

图2示出根据一个实施例的设置验证方式的方法流程图。该方法在客户端执行。客户端可以包括各种计算终端(例如PC机)、智能便携设备(例如手机、平板电脑)以及其上安装的应用和App。如图2所示，上述设置验证方式的方法包括，步骤21，响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；步骤22，响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作；步骤23，接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式；步骤24，向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。下面描述各个步骤的执行。

首先，在步骤21，响应于用户的启动验证方式设置的操作，向用户提供业务选项。为简单和区别起见，上述用于启动验证方式设置的操作又称为第一操作。

在一个实施例中，在客户端应用中为用户提供定制验证方式的入口，例如，在支付宝“我的”栏目中增加“设置安全验证”，在其他App的类似“个人中心”的栏目中增加“设置安全验证”等。如此，用户点击进入上述入口的操作即为上述第一操作，用于启动验证方式的设置。一旦接收到用户启动验证方式设置的操作，则向用户提供业务选项。一般地，业务选项包括该用户可用的、并且支持用户定制验证方式的多个业务。

图3A示出提供给用户的业务选项的一个示意性界面。在用户进入“设置安全验证”功能后，即可向用户展示图3A所示的业务选项。在图3A中，业务选项示意性包括了贷款业务，转账业务，绑卡/解绑卡业务，以供用户进行选择。

于是，用户可以从业务选项中选择要设置验证方式的业务。该选择业务的操作被简称为第二操作，用户选中的业务被称为第一业务。在图3A中，假定用户选择了贷款业务。

接着，在步骤22，响应于用户的上述第二操作，向用户提供验证方式选项，该选项包括多个备选验证方式。备选验证方式可以包括例如交易密码验证，短信验证，人脸验证，指纹验证，声纹验证等等验证方式。

在一个实施例中，不管用户选择什么样的业务，在验证方式选项中向用户提供所有可能的验证方式，以供用户自由选择。在另一实施例中，验证方式选项包括***针对用户选择的第一业务推荐的验证方式。换而言之，用户选择不同的业务，验证方式选项中呈现的备选验证方式有可能有所不同。例如，***可以预先针对各个业务的安全要求级别进行评估，对于安全要求级别较高的业务，例如贷款业务，则推荐安全级别较高的验证方式，例如指纹、人脸；对于安全要求级别较低的业务，例如存款，则推荐安全级别一般的验证方式，例如交易密码。对于有特殊要求的业务，还可以针对性地推荐对应的验证方式。例如，如果用户选择的业务是针对公司账户进行的高安全级别业务，那么可以在验证方式选项中向用户提供例如基于LBS(基于位置的服务)的验证方式，该验证方式可以对操作位置进行验证，以确保公司账户仅在公司所在位置范围内进行操作。

基于以上的验证方式选项，用户可以从其中的备选验证方式中进行选择。相应地，在步骤23，客户端接收用户从所述验证方式选项中选择至少一个验证方式的操作，该操作又称为第三操作。

在一个实施例中，在验证方式选项中仅向用户提供该用户已通过验证的验证方式。在另一实施例中，在验证方式选项中提供所有可能的验证方式。此时，如果在步骤23中用户选择的验证方式中包括用户未验证过的特定验证方式，那么接下来要利用该特定验证方式对用户身份进行验证。例如，如果选择了指纹验证，但是之前并未验证过指纹，那么就要求用户输入指纹进行验证。

图3B示出提供给用户的验证方式选项的一个示意性界面。在图3B中，验证方式选项示意性包括了交易密码、短信、人脸、指纹，以供用户进行选择。于是，用户可以从验证方式选项中选择自己认为必要的验证方式。假定用户在图3A中选择贷款业务之后，针对该贷款业务，在图3B中选择了交易密码、短信和人脸三种验证方式。

在接收到用户选择验证方式的操作之后，在步骤24，客户端向服务端发送设置信息，其中至少包括用户的信息，用户选择的第一业务的信息，以及用户针对该第一业务而设置的至少一个验证方式的信息，这些设置信息用于供服务端存储和记录用户针对业务设置的验证方式。如此，完成了在客户端进行的验证方式的设置。

在一个实施例中，为了增加安全性，防止他人冒用用户进行验证方式设置，在用户进行上述第一操作之后，步骤24之前的任意阶段，先对用户进行一次核身验证。核身验证的方式可以由***预先设定。如此，增加验证方式设定的安全性。

与上述客户端相对应地，服务端接收上述客户端发送的设置信息，并对设置信息进行存储和记录。如前所述，所接收的设置信息至少包括用户的信息，用户选择的第一业务的信息，以及用户针对该第一业务而设置的至少一种验证方式的信息。为此，服务端需要针对各个用户，存储业务与设置的验证方式之间的关联关系。

在一个实施例中，服务端采用多级映射表存储上述关联关系。多级映射表包括第一级表项、第二级表项和第三级表项，所述第一级表项用于存储多个用户的用户信息，第二级表项用于存储各个用户的可用业务的信息，第三级表项用于存储各个用户针对各个可用业务设置的验证方式信息。

图4示出根据一个实施例的映射表的示意图。可以理解，该映射表是服务端用于存储各个用户的设置信息的映射表。如图4所示，在该映射表的第一级表项中，存储各个用户的信息，例如用户ID，包括User1，User2，…；在该映射表的第二级表项中，存储各个用户的可用业务的信息，例如用户User1的可用业务：贷款，转账，存款，绑卡等等；在该映射表的第三级表项中，存储各个用户针对各个可用业务设置的验证方式的信息，例如User1针对贷款业务设置了交易密码，短信，人脸三种验证方式，针对转账业务设置了交易密码和短信两种验证方式，针对存款和绑卡均设置了交易密码的验证方式。

可以理解，服务端也可以采用其他形式存储用户的设置信息，在此不对此进行限定。

如此，在本说明书实施例的第一阶段，即用户进行验证方式设置的阶段，客户端接收用户的设置操作，并将其整理为设置信息发送到服务端，服务端对各个用户的设置信息进行存储和记录，从而使得，用户可以根据自己的需要，基于自己对各项业务的重要性判断，针对各项业务分别设置不同的验证方式。

接下来描述在实施例的第二阶段，即用户为使用业务而进行安全验证的阶段，如何根据用户的个性化设置引导用户完成身份验证。

图5示出根据一个实施例的安全验证的方法，该方法在客户端执行。如图5所示，该方法包括：步骤51，响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；步骤52，从服务端获取由用户针对所述业务请求事件对应的业务而设置的至少一个验证方式；步骤53，采用上述至少一个验证方式对用户身份进行验证。

在一个实施例中，客户端包括业务平台和验证平台，业务平台用于处理业务相关的请求，验证平台用于针对各种业务对用户进行身份验证。在这样的情况下，步骤51进一步包括以下过程：用户向业务平台发出业务请求事件，业务平台用该业务请求事件的事件信息向服务端请求事件验证ID。在从服务端获得所请求的事件验证ID之后，业务平台将该事件验证ID发送给验证平台。然后，验证平台基于该事件验证ID向服务端发出所述查询请求，用以请求查询所述业务请求事件对应的验证方式。

接着，在步骤52，客户端从服务端获取业务请求事件对应的验证方式。在客户端包括业务平台和验证平台的情况下，在该步骤中，由验证平台从服务端接收返回的验证方式。

然后在步骤53，客户端采用从服务端获取的验证方式对用户身份进行验证。更具体地，可以由客户端中的验证平台进行用户身份验证。

在一个实施例中，在步骤53，客户端，特别是其中的验证平台，依次获取用户针对所设置的各个验证方式提供的各个验证信息，将各个验证信息发送到核身验证中心，使得核身验证中心对用户身份进行验证。

与图5所示的在客户端执行的方法相对应地，图6示出根据一个实施例的在服务端执行的方法，该方法用于辅助客户端进行安全验证，并包括：步骤61，接收客户端响应于用户的业务请求事件而发送的查询请求，该查询请求用于请求查询所述业务请求事件对应的验证方式；步骤62，根据查询请求，查询所述用户针对所述业务请求事件对应的业务而设置的至少一个验证方式；步骤63，将上述至少一个验证方式发送给所述客户端。

在一个实施例中，客户端包括业务平台和验证平台。相应地，上述步骤61包括以下过程：服务端接收客户端业务平台响应于用户的业务请求事件而发送的事件信息，基于事件信息为所述业务请求事件生成事件验证ID。在一个实施例中，服务端按照预定规则，对事件信息中的项目进行编码，从而生成上述的事件验证ID。在另一实施例中，服务端根据流水号生成当前的事件验证ID。然后，将生成的事件验证ID发送给业务平台。如前所述，业务平台会将该事件验证ID转发给验证平台。于是，接下来，服务端会从验证平台接收到基于该事件验证ID而产生的查询请求，用以查询业务请求事件对应的验证方式。

接下来，在步骤62，查询用户针对业务请求事件对应的业务而设置的验证方式。如前所述，服务端中存储和记录了各个用户的设置信息，其中包括各个用户针对各项可用业务设置的验证方式，例如图4所示。相应地，在接收到来自客户端的查询请求时，服务端就可以从存储的设置信息中查询，当前用户针对当前业务请求事件的业务设置了什么样的验证方式。

在一个实施例中，查询请求包括当前用户信息和请求的业务信息。在这样的情况下，服务端可以直接从设置信息中查询，当前用户针对所请求的业务设置的验证方式。

在另一个实施例中，查询请求基于上述事件验证ID生成。在此情况下，上述查询过程可以包括，首先根据查询请求所基于的事件验证ID，获取该事件验证ID所对应的业务请求事件的事件信息。然后，根据上述事件信息，确定根据业务请求事件所对应的用户和业务；接着，在预先存储的设置信息映射表中查询上述用户针对该业务而设置的验证方式。

然后，在步骤63，将查询到的验证方式发送给客户端，以供客户端进行安全验证。

下面结合图7描述第二阶段的验证过程。图7示出根据一个实施例的安全验证的过程。在图7的示例中，客户端包括业务平台和验证平台。

首先，在步骤S01，用户向业务平台发出业务请求，形成业务请求事件。例如，在一个例子中，用户(user01)使用贷款业务。在用户填写完个人信息、贷款金额、收款***后，点击“确定贷款”时，即向业务平台发出贷款业务请求，形成一次业务请求事件。

业务平台接收到这样的业务请求后，在步骤S02，获取该业务请求事件的事件信息。在一个实施例中，业务平台提取业务请求事件的要素，形成事件信息。事件信息可以包括：用户信息(例如userID)，设备信息，业务类型，业务流水号等。例如，在上述用户user01使用贷款业务的情况下，事件信息例如可以包括，用户名user01，贷款业务的类型编号S01，贷款金额10k，业务流水号xxxxxx，等等。

然后，在步骤S03，业务平台将上述事件信息发送给服务端，即，使用该事件信息向服务端请求事件验证ID。

在服务端接收到上述事件信息后，首先在步骤S04，对于该业务请求事件进行初步验证。这包括，例如验证其中的userID是否合法，验证各种信息的格式是否正确，等等。

在初步验证通过之后，在步骤S05，服务端针对该业务请求事件生成事件验证ID，又称为VID(Verify ID)。在一个例子中，服务端按照预定规则，对事件信息中的项目进行编码，从而生成上述的事件验证ID。例如，可以将事件信息中各个项目组成一个字符串，对该字符串施加预定编码形式，从而生成VID。在另一例子中，服务端根据流水号生成当前事件的事件验证ID。或者，在又一例子中，服务端随机生成字符串作为当前事件的事件验证ID。

在一个例子中，对于上述用户user01使用贷款业务的业务请求事件，假定为其生成的事件验证ID为EV001。

可以理解，在生成事件验证ID的同时，服务端存储所生成的事件验证ID与事件信息的对应关系，以备后续查询。

接着在步骤S06，服务端将生成的事件验证ID返回给业务平台。

然后，在步骤S07，业务平台将事件验证ID转发给验证平台。由于事件验证ID本身只是一个ID(例如EV001)，并不包含业务请求事件中与业务相关的信息，如此避免验证平台获取到不必要的业务信息，从而提高安全性。

验证平台从业务平台接收到事件验证ID之后，在步骤S08，可以基于该事件验证ID向服务端发出查询请求，以请求查询当前业务请求事件所需的验证方式。

在步骤S09，服务端查询当前业务请求事件对应的验证方式。如前所述，服务端在生成一个事件验证ID的同时，会存储所生成的事件验证ID与事件信息的对应关系。因此，在接收到查询请求时，服务端首先根据上述对应关系，获取查询请求中包含的事件验证ID所对应的业务请求事件的事件信息。然后，根据上述事件信息，确定业务请求事件所对应的用户和业务；接着，在预先存储的用户设置信息中查询上述用户针对该业务而设置的验证方式。例如，服务端接收到的查询请求中包含事件验证ID：EV001，于是服务端可以基于该ID定位出事件信息，其中包括，用户名user01，贷款业务的类型编号S01，贷款金额10k，业务流水号xxxxxx，等等。根据以上的事件信息，可以确定业务请求事件所对应的用户为user01，业务为S01。然后，在预先存储的用户设置信息中，可以查询用户user01针对业务S01所设置的验证方式，例如包括交易密码，短信和人脸。

接着，在步骤S10，服务端将查询到的验证方式返回给验证平台。

在步骤S11，验证平台针对获取的各个验证方式，依次向用户发出验证要求，并在步骤S12，依次获取用户的验证信息。例如，如果获取的验证方式为交易密码、短信和人脸，那么在步骤S11，依次要求用户输入密码，验证短信和人脸信息，在步骤S12，分别获取用户输入的密码，验证短信内容和人脸信息。

接着，在步骤S13，验证平台将用户输入的验证信息发送到验证中心。在多数业务应用场景中，采用与客户端，以及与服务端的安全服务器均独立的验证中心，专用于进行身份验证。当然在一些场景中，验证中心也可被集成在服务端的某些服务器中。

验证中心从客户端验证平台接收到验证信息后，在步骤S14，对验证信息进行验证。然后在步骤S15，将验证结果，比如验证通过或验证失败，发送给客户端验证平台，然后验证平台可以将验证结果通知给业务平台。

业务平台于是可以根据验证结果，确定是否允许用户继续进行当前的业务请求。

在用户针对当前业务设置有多个验证方式的情况下，需要多个验证方式均通过验证才认为是验证通过。例如，在一个例子中，验证平台将交易密码、短信验证内容和人脸信息均发送到验证中心，验证中心分别对这三种验证方式进行验证，仅当每一项验证信息与预留的标准信息分别匹配时，才将验证通过的结果返回给客户端。

通过以上的方式，在用户使用业务时，根据用户针对该业务所设置的验证方式对用户身份进行验证。

在一个实施例中，在通知业务平台验证通过的情况下，业务平台还进行二次验证，以增加安全性。该二次验证可以用于判断，验证平台是否确实向服务端发起了查询，并根据查询结果对用户进行了验证。二次验证的过程可以包括，业务平台再次将事件验证ID发送给服务端，请求服务端判断该事件验证ID是否被请求查询。如果之前验证平台基于事件验证ID向服务端发起了查询请求，那么就会调用相应的API接口。服务端可以通过对应API接口被调用的记录，判断对应事件验证ID是否被查询，并将这样的判断结果返回给业务平台。在一个实施例中，服务端还可以再次查询获取该事件验证ID所对应的验证方式，将其返回给业务平台。如此，业务平台可以将本次从服务端获取的验证方式和验证结果通知中的验证方式进行比对，以进行进一步的确认。

可以理解，还存在更多种二次验证的方式。这些方式均可以采用来进一步巩固核身验证的安全性。

通过以上实施方式，允许用户根据自己对于某项业务的重要性判断，自己定义该项业务所需的核身方式。在用户使用业务的阶段，客户端针对本次业务请求事件，向服务端查询用户针对该业务设置的验证方式，并依据这样的验证方式对用户进行核身验证。如此，实现用户针对各种业务自定义验证方式的过程。

根据另一方面的实施例，在客户端提供一种设置验证方式的装置。图8示出根据一个实施例的设置验证方式的装置的示意性框图。需要理解的是，图8的设置装置80位于客户端一侧。如图8所示，设置装置80包括：第一提供单元81，配置为响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；第二提供单元82，配置为响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作；接收单元83，配置为接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式；发送单元84，配置为向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。

在一个实施例中，上述装置80还包括第一验证单元(未示出)，配置为，在向服务端发送设置信息之前，根据***设置的验证方式，对用户身份进行验证。

在一个实施例中，第二提供单元82所提供的验证方式选项包括：针对所述第一业务推荐的多个验证方式；或者所述用户已通过验证的多个验证方式。

在一个实施例中，用户选择的所述至少一个验证方式包括用户未验证过的特定验证方式；相应地，装置80还包括第二验证单元(未示出)，配置为利用所述特定验证方式对用户身份进行验证。

根据一个实施例，上述至少一个验证方式包括以下中的一项或多项：交易密码验证，短信验证，人脸验证，指纹验证，声纹验证。

根据另一方面的实施例，在服务端提供一种设置验证方式的装置。图9示出根据一个实施例的设置验证方式的装置的示意性框图。需要理解的是，图9的设置装置90位于服务端一侧。如图9所示，设置装置90包括：接收单元91，配置为接收设置信息，所述设置信息至少包括用户的信息，第一业务的信息，以及至少一个验证方式的信息，其中所述至少一个验证方式由所述用户针对所述第一业务而设置；以及存储单元92，配置为针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系。

在一个实施例中，存储单元92配置为，采用多级映射表存储所述关联关系，所述多级映射表包括第一级表项、第二级表项和第三级表项，所述第一级表项用于存储多个用户的用户信息，第二级表项用于存储各个用户的可用业务的信息，第三级表项用于存储各个用户针对各个可用业务设置的验证方式信息。

根据又一方面的实施例，在客户端提供一种安全验证的装置。图10示出根据一个实施例的安全验证装置的示意性框图。需要理解的是，图10的验证装置100位于客户端一侧。如图10所示，验证装置100包括：请求单元101，配置为响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；获取单元102，配置为从服务端获取至少一个验证方式，所述至少一个验证方式由所述用户针对所述业务请求事件对应的业务而设置；验证单元103，配置为采用所述至少一个验证方式对用户身份进行验证。

在一个实施例中，请求单元101包括业务模块1011和验证模块1012，其中业务模块1011配置为，响应于所述业务请求事件，用所述业务请求事件的事件信息向服务端请求事件验证ID，从所述服务端获得所述事件验证ID，并将该事件验证ID发送给所述验证模块1012；验证模块1012配置为，基于所述事件验证ID向所述服务端发出所述查询请求。

根据一种实施方式，上述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

在一个实施例中，上述验证单元103配置为，依次获取用户针对所述至少一个验证方式中各个验证方式提供的各个验证信息，将各个验证信息发送到核身验证中心，使得核身验证中心对用户身份进行验证。

根据又一方面的实施例，在服务端提供一种用于安全验证的装置。图11示出根据一个实施例的安全验证装置的示意性框图。需要理解的是，图11的验证装置110位于服务端一侧，用于辅助客户端进行安全验证。如图11所示，装置110包括：接收单元111，配置为接收所述客户端响应于用户的业务请求事件而发送的查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；查询单元112，配置为根据所述查询请求，查询所述用户针对所述业务请求事件对应的业务而设置的至少一个验证方式；以及发送单元113，配置为将所述至少一个验证方式发送给所述客户端。

在一个实施例中，客户端包括业务平台和验证平台。相应地，服务端装置110的接收单元111配置为：接收业务平台响应于用户的业务请求事件而发送的事件信息，基于所述事件信息为所述业务请求事件生成事件验证ID；将所述事件验证ID发送给所述业务平台；从所述验证平台接收所述查询请求，所述查询请求基于所述事件验证ID而产生。

根据一种实施方式，上述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

在一个实施例中，上述接收单元111按照预定规则对所述事件信息中的项目进行编码，从而生成所述事件验证ID。

根据一种实施方式，查询单元112配置为：根据所述查询请求所基于的事件验证ID，获取该事件验证ID所对应的业务请求事件的事件信息；确定根据业务请求事件所对应的用户和业务；在预先存储的设置信息中查询所述用户针对所述业务而设置的至少一个验证方式。

根据另一方面的实施例，还提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行结合图2、图5和图6所描述的方法。

根据再一方面的实施例，还提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现结合图2、图5和图6所述的方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (34)

1.一种设置验证方式的方法，该方法在客户端执行，该方法包括：

响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；

响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式；

向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。

2.根据权利要求1所述的方法，其中在向服务端发送设置信息之前，还包括，根据***设置的验证方式，对用户身份进行验证。

3.根据权利要求1所述的方法，其中，所述验证方式选项包括：

针对所述第一业务推荐的多个验证方式；或者

所述用户已通过验证的多个验证方式。

4.根据权利要求1所述的方法，其中所述至少一个验证方式包括用户未验证过的特定验证方式，所述方法还包括，利用所述特定验证方式对用户身份进行验证。

5.根据权利要求1所述的方法，其中所述至少一个验证方式包括以下中的一项或多项：交易密码验证，短信验证，人脸验证，指纹验证，声纹验证。

6.一种设置验证方式的方法，该方法在服务端执行，该方法包括：

接收设置信息，所述设置信息至少包括用户的信息，第一业务的信息，以及至少一个验证方式的信息，其中所述至少一个验证方式由所述用户针对所述第一业务提供的验证方式选项而设置，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系。

7.根据权利要求6所述的方法，其中针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系包括，采用多级映射表存储所述关联关系，所述多级映射表包括第一级表项、第二级表项和第三级表项，所述第一级表项用于存储多个用户的用户信息，第二级表项用于存储各个用户的可用业务的信息，第三级表项用于存储各个用户针对各个可用业务设置的验证方式信息。

8.一种安全验证的方法，该方法在客户端执行，包括：

响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

从服务端获取至少一个验证方式，所述至少一个验证方式由所述用户针对所述业务请求事件对应的业务提供的验证方式选项而设置，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

采用所述至少一个验证方式对用户身份进行验证。

9.根据权利要求8所述的方法，其中所述客户端包括业务平台和验证平台，所述响应于用户的业务请求事件，向服务端发出查询请求包括：

响应于所述业务请求事件，所述业务平台用所述业务请求事件的事件信息向服务端请求事件验证ID；

所述业务平台从所述服务端获得所述事件验证ID，并将该事件验证ID发送给所述验证平台；

所述验证平台基于所述事件验证ID向所述服务端发出所述查询请求。

10.根据权利要求9所述的方法，其中所述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

11.根据权利要求8所述的方法，其中所述采用所述至少一个验证方式对用户身份进行验证包括，依次获取用户针对所述至少一个验证方式中各个验证方式提供的各个验证信息，将各个验证信息发送到核身验证中心，使得核身验证中心对用户身份进行验证。

12.一种用于安全验证的方法，该方法在服务端执行，用于辅助客户端进行安全验证，所述方法包括：

接收所述客户端响应于用户的业务请求事件而发送的查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

根据所述查询请求，查询所述用户针对所述业务请求事件对应的业务提供的验证方式选项而设置的至少一个验证方式，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

将所述至少一个验证方式发送给所述客户端。

13.根据权利要求12所述的方法，其中所述客户端包括业务平台和验证平台，所述接收所述客户端响应于用户的业务请求事件而发送的查询请求包括：

接收所述业务平台响应于用户的业务请求事件而发送的事件信息，基于所述事件信息为所述业务请求事件生成事件验证ID；

将所述事件验证ID发送给所述业务平台；

从所述验证平台接收所述查询请求，所述查询请求基于所述事件验证ID而产生。

14.根据权利要求13所述的方法，其中所述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

15.根据权利要求13或14所述的方法，其中基于所述事件信息为所述业务请求事件生成事件验证ID包括：按照预定规则对所述事件信息中的项目进行编码，从而生成所述事件验证ID。

16.根据权利要求13所述的方法，其中查询所述用户针对所述业务请求事件对应的业务而设置的至少一个验证方式包括：

根据所述查询请求所基于的事件验证ID，获取该事件验证ID所对应的业务请求事件的事件信息；

确定根据业务请求事件所对应的用户和业务；

在预先存储的设置信息中查询所述用户针对所述业务而设置的至少一个验证方式。

17.一种设置验证方式的装置，该装置位于客户端，并包括：

第一提供单元，配置为响应于用户的第一操作，向用户提供业务选项，其中所述第一操作用于启动验证方式设置；

第二提供单元，配置为响应于用户的第二操作，向用户提供验证方式选项，其中所述第二操作为从所述业务选项中选择第一业务的操作；

接收单元，配置为接收用户的第三操作，所述第三操作为从所述验证方式选项中选择至少一个验证方式，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

发送单元，配置为向服务端发送设置信息，所述设置信息至少包括所述用户的信息，所述第一业务的信息，以及所述用户针对所述第一业务而设置的所述至少一个验证方式的信息。

18.根据权利要求17所述的装置，还包括第一验证单元，配置为，在向服务端发送设置信息之前，根据***设置的验证方式，对用户身份进行验证。

19.根据权利要求17所述的装置，其中，所述验证方式选项包括：

针对所述第一业务推荐的多个验证方式；或者

所述用户已通过验证的多个验证方式。

20.根据权利要求17所述的装置，其中所述至少一个验证方式包括用户未验证过的特定验证方式，所述装置还包括第二验证单元，配置为利用所述特定验证方式对用户身份进行验证。

21.根据权利要求17所述的装置，其中所述至少一个验证方式包括以下中的一项或多项：交易密码验证，短信验证，人脸验证，指纹验证，声纹验证。

22.一种设置验证方式的装置，该装置位于服务端，并包括：

接收单元，配置为接收设置信息，所述设置信息至少包括用户的信息，第一业务的信息，以及至少一个验证方式的信息，其中所述至少一个验证方式由所述用户针对所述第一业务提供的验证方式选项而设置，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

存储单元，配置为针对所述用户存储所述第一业务与所述至少一个验证方式之间的关联关系。

23.根据权利要求22所述的装置，其中所述存储单元配置为，采用多级映射表存储所述关联关系，所述多级映射表包括第一级表项、第二级表项和第三级表项，所述第一级表项用于存储多个用户的用户信息，第二级表项用于存储各个用户的可用业务的信息，第三级表项用于存储各个用户针对各个可用业务设置的验证方式信息。

24.一种安全验证的装置，该装置位于客户端，包括：

请求单元，配置为响应于用户的业务请求事件，向服务端发出查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

获取单元，配置为从服务端获取至少一个验证方式，所述至少一个验证方式由所述用户针对所述业务请求事件对应的业务提供的验证方式选项而设置，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

验证单元，配置为采用所述至少一个验证方式对用户身份进行验证。

25.根据权利要求24所述的装置，其中所述请求单元包括业务模块和验证模块，

所述业务模块配置为，响应于所述业务请求事件，用所述业务请求事件的事件信息向服务端请求事件验证ID，从所述服务端获得所述事件验证ID，并将该事件验证ID发送给所述验证模块；

所述验证模块配置为，基于所述事件验证ID向所述服务端发出所述查询请求。

26.根据权利要求25所述的装置，其中所述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

27.根据权利要求24所述的装置，其中所述验证单元配置为，依次获取用户针对所述至少一个验证方式中各个验证方式提供的各个验证信息，将各个验证信息发送到核身验证中心，使得核身验证中心对用户身份进行验证。

28.一种用于安全验证的装置，该装置位于服务端，用于辅助客户端进行安全验证，所述装置包括：

接收单元，配置为接收所述客户端响应于用户的业务请求事件而发送的查询请求，所述查询请求用于请求查询所述业务请求事件对应的验证方式；

查询单元，配置为根据所述查询请求，查询所述用户针对所述业务请求事件对应的业务提供的验证方式选项而设置的至少一个验证方式，所述验证方式选项包括基于对所述第一业务的安全要求级别评估而确定的备选验证方式；

发送单元，配置为将所述至少一个验证方式发送给所述客户端。

29.根据权利要求28所述的装置，其中所述客户端包括业务平台和验证平台，所述接收单元配置为：

接收所述业务平台响应于用户的业务请求事件而发送的事件信息，基于所述事件信息为所述业务请求事件生成事件验证ID；

将所述事件验证ID发送给所述业务平台；

从所述验证平台接收所述查询请求，所述查询请求基于所述事件验证ID而产生。

30.根据权利要求29所述的装置，其中所述事件信息包括以下中的至少一项：用户信息，设备信息，业务类型，业务流水号。

31.根据权利要求29或30所述的装置，其中所述接收单元基于所述事件信息为所述业务请求事件生成事件验证ID包括：按照预定规则对所述事件信息中的项目进行编码，从而生成所述事件验证ID。

32.根据权利要求29所述的装置，其中所述查询单元配置为：

根据所述查询请求所基于的事件验证ID，获取该事件验证ID所对应的业务请求事件的事件信息；

确定根据业务请求事件所对应的用户和业务；

在预先存储的设置信息中查询所述用户针对所述业务而设置的至少一个验证方式。

33.一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行权利要求1-16中任一项的所述的方法。

34.一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现权利要求1-16中任一项所述的方法。

Images