用户验证方法、服务器、用户设备和系统
技术领域
本公开涉及信息安全领域,特别涉及一种用户验证方法、服务器、用户设备和系统。
背景技术
用户在应用中进行敏感操作时,例如,转账、修改交易密码等,应用提供方通常会对用户进行一些验证,以确认用户是否有权限进行当前的敏感操作。
通常来说,如果某个版本的应用已经发布,则在该版本的应用中,各种敏感操作对应的验证方式以及验证顺序等验证流程都是固定的。如果应用提供方想要更改某些敏感操作对应的验证方式或验证顺序等验证流程,需要发布新版本的应用,以支持这些更改。
发明内容
发明人发现,由于应用的研发和审核需要时间,因此,应用版本的更新需要一定的周期,并且如果用户没有选择升级应用,则用户使用的仍然是旧版本的应用,这些原因均会造成在一定时期内敏感操作对应的验证方式以及验证顺序等验证流程难以改变,对用户验证的灵活性和安全性造成不利影响。
在本公开中,对于用户执行例如敏感操作等预设业务操作的请求,用户设备可以将请求转发给服务器,服务器根据验证配置信息动态地确定该预设业务操作对应的验证方式以及验证顺序等验证流程,按照验证顺序依次指示用户设备按照相应的验证方式对用户进行验证。重新配置验证配置信息,就可以更改业务操作对应的验证流程,不需要应用升级,提高了用户验证的灵活性和安全性。
本公开的一些实施例提出一种用户验证方法,包括:
服务器接收用户设备发送的用户执行预设业务操作的请求;
所述服务器根据验证配置信息确定所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序;
所述服务器按照所述验证顺序依次指示所述用户设备按照相应的验证方式对所述用户进行验证,并通过所述用户设备获取所述用户提交的待验证信息;
所述服务器根据所述待验证信息确定所述用户是否验证成功,如果所述用户验证成功,允许所述用户执行所述预设业务操作,如果所述用户验证失败,拒绝所述用户执行所述预设业务操作。
在一些实施例中,所述验证配置信息中的可配置信息项包括:业务操作、验证方式和验证顺序。
在一些实施例中,所述验证配置信息中的可配置信息项还包括:辅助信息;所述方法还包括:所述服务器获取所述请求对应的实际辅助信息;其中,所述服务器根据验证配置信息确定所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序包括:所述服务器根据所述验证配置信息确定在所述实际辅助信息的情况下所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序。
在一些实施例中,所述辅助信息包括:应用、时间、用户、用户设备、用户位置中的一项或多项。
在一些实施例中,所述服务器按照所述验证顺序依次向所述用户设备发送携带相应验证方式的验证指示,其中,每次验证的验证指示还携带上次验证的第一令牌,其中,第一次验证的验证指示携带的是初始令牌;所述服务器接收所述用户设备返回的上次验证的第一令牌和所述用户提交的本次验证的待验证信息;所述方法还包括:所述服务器根据上次验证的第一令牌和本次验证的相关信息生成本次验证的第二令牌,将第二令牌与第一令牌和本次验证的相关信息进行关联性存储,其中,所述本次验证的相关信息包括本次验证的待验证信息以及验证结果。
在一些实施例中,将每次验证的关联性存储信息保存到区块链中。
在一些实施例中,所述如果所述用户验证成功,允许所述用户执行所述预设业务操作包括:如果所述用户验证成功,所述服务器向所述用户设备发送最终令牌,以使得所述用户设备展示所述预设业务操作的业务页面,并返回所述用户基于所述业务页面提交的业务操作信息和所述最终令牌,所述服务器对返回的所述最终令牌进行校验,如果校验成功,接受所述用户提交的业务操作信息,如果校验失败,拒绝所述用户提交的业务操作信息。
本公开的一些实施例提出一种用户验证方法,包括:
用户设备响应用户执行的预设业务操作,向服务器发送所述用户执行所述预设业务操作的请求,以使得所述服务器根据验证配置信息确定所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序,并按照所述验证顺序依次指示所述用户设备按照相应的验证方式对所述用户进行验证;
所述用户设备依次接收所述服务器发送的验证指示;
所述用户设备顺序地按照各次验证的验证指示指明的验证方式对所述用户进行验证,并向所述服务器返回所述用户提交的待验证信息,以使得所述服务器根据所述待验证信息,确定所述用户是否验证成功。
在一些实施例中,每次验证的验证指示还携带上次验证的第一令牌,其中,第一次验证的所述验证指示携带的是初始令牌;所述用户设备向所述服务器同时返回所述用户提交的待验证信息和上次验证的第一令牌,以使得所述服务器根据上次验证的第一令牌和本次验证的相关信息生成本次验证的第二令牌,将第二令牌与第一令牌和本次验证的相关信息进行关联性存储,其中,所述本次验证的相关信息包括本次验证的待验证信息以及验证结果。
在一些实施例中,如果所述用户验证成功,所述方法还包括:所述用户设备接收所述服务器发送的最终令牌,展示所述预设业务操作的业务页面,获取所述用户基于所述业务页面提交的业务操作信息,向所述服务器返回所述业务操作信息和所述最终令牌,以使得所述服务器根据返回的所述最终令牌的校验结果,接受或拒绝所述用户提交的业务操作信息。
本公开的一些实施例提出一种服务器,包括:
存储器;以及
耦接至所述存储器的处理器,所述处理器被配置为基于存储在所述存储器中的指令,执行任一个实施例的用户验证方法。
本公开的一些实施例提出一种用户设备,其特征在于,包括:
存储器;以及
耦接至所述存储器的处理器,所述处理器被配置为基于存储在所述存储器中的指令,执行任一个实施例的用户验证方法。
本公开的一些实施例提出一种用户验证系统,包括:任一个实施例的服务器;以及任一个实施例的用户设备。
本公开的一些实施例提出一种非瞬时性计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现任一个实施例的用户验证方法。
附图说明
下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍。根据下面参照附图的详细描述,可以更加清楚地理解本公开,
显而易见地,下面描述中的附图仅仅是本公开的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1为本公开用户验证方法一些实施例的流程示意图。
图2为本公开以“修改交易密码”敏感操作为例描述的用户验证方法一些实施例的流程示意图。
图3为本公开易追溯的用户验证方法一些实施例的流程示意图。
图4为本公开数据块的链式结构示意图。
图5为本公开以“修改交易密码”敏感操作为例描述的易追溯的用户验证方法一些实施例的流程示意图。
图6为本公开“修改交易密码”敏感操作对应的数据块的链式结构示意图。
图7为本公开用于用户验证的服务器一些实施例的示意图。
图8为本公开用于用户验证的用户设备一些实施例的示意图。
图9为本公开用户验证系统一些实施例的示意图。
具体实施方式
下面将结合本公开实施例中的附图,对本公开实施例中的技术方案进行清楚、完整地描述。
图1为本公开用户验证方法一些实施例的流程示意图。如图1所示,该实施例的方法包括步骤11-15:
在步骤11,用户设备响应用户执行的预设业务操作,向服务器发送用户执行预设业务操作的请求。
其中,预设业务操作可以预先设置为某些敏感操作,例如,支付、转账、修改登录密码或交易密码等,但不限于所举示例。
在步骤12,服务器接收用户设备发送的用户执行预设业务操作的请求,服务器根据验证配置信息确定预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序。
验证配置信息中的可配置信息项包括:业务操作、验证方式和验证顺序,还可以选择性地包括:辅助信息。辅助信息例如包括:应用、时间、用户、用户设备、用户位置中的一项或多项。
其中,应用是指用户执行预设业务操作的业务环境。时间是指执行预设业务操作的时间。用户是指执行预设业务操作的用户。用户设备是指执行预设业务操作的用户设备。用户位置例如可以是用户执行预设业务操作时所在的位置。
如果验证配置信息中的可配置信息项包括辅助信息,则服务器还需要获取请求对应的实际辅助信息,实际辅助信息可以由用户设备发送给服务器,以便服务器根据验证配置信息确定在实际辅助信息的情况下预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序。从而,基于各种辅助信息,实现对用户验证流程的更精准的控制。
例如,如果验证配置信息中的可配置信息项包括应用,则用户设备向服务器发送的请求中还携带用户执行预设业务操作的应用信息,则服务器确定该应用的预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序。
验证方式例如包括密码验证、手机短信验证码验证、人脸识别、指纹验证、活体检测验证、银行卡四要素(银行卡号、身份证号、手机号、姓名)验证等。
服务器可以根据业务需要,针对每一种敏感操作,配置或者重新配置其所需要的验证方式以及验证方式之间的验证顺序等验证流程。验证流程的配置或者重新配置可以由人工完成,也可以根据风险控制策略自动完成。
在步骤13,服务器按照验证顺序依次指示用户设备按照相应的验证方式对用户进行验证。
在步骤14,用户设备依次接收服务器发送的验证指示,顺序地按照各次验证的验证指示指明的验证方式对用户进行验证,并向服务器返回用户提交的待验证信息。
其中,用户设备可以向用户展示验证方式对应的验证页面,用户通过验证页面输入待验证信息。
在步骤15,服务器根据各次验证的待验证信息确定用户是否验证成功,如果用户验证成功,允许用户执行预设业务操作,如果用户验证失败,拒绝用户执行预设业务操作。
如果预设业务操作对应多种验证方式,用户成功通过所有验证方式,则该用户验证成功,用户未成功通过任意一种验证方式,则该用户验证失败。通常情况下,按照验证顺序,如果用户未成功通过排序在前的验证方式,则无需用户再验证排序在后的验证方式,就可以判定该用户验证失败。
上述实施例,对于用户执行例如敏感操作等预设业务操作的请求,用户设备可以将请求转发给服务器,服务器根据验证配置信息动态地确定该预设业务操作对应的验证方式以及验证顺序等验证流程,按照验证顺序依次指示用户设备按照相应的验证方式对用户进行验证。重新配置验证配置信息,就可以更改业务操作对应的验证流程,不需要应用升级,提高了用户验证的灵活性和安全性。
下面以“修改交易密码”敏感操作为例,说明用户验证方法。
如图2所示,在步骤21,服务器配置“修改交易密码”敏感操作的验证配置信息,例如服务器配置需要验证旧交易密码以及手机短信验证码,且验证顺序为先验证旧交易密码,然后验证手机短信验证码。
在步骤22,用户设备检测到用户执行“修改交易密码”的操作,向服务器发送用户执行“修改交易密码”操作的请求。
接着,在步骤23,服务器响应该请求,根据“修改交易密码”敏感操作的验证配置信息,向用户设备发送验证指示1,指示用户设备对用户进行旧交易密码验证。
接着,在步骤24,用户设备响应验证指示1,展示旧交易密码验证页面,用户通过旧交易密码验证页面输入“旧交易密码”并提交,用户设备将用户提交的“旧交易密码”作为待验证信息发送给服务器。
接着,在步骤25,服务器验证用户提交的“旧交易密码”是否为该用户真实的“旧交易密码”,如果是,则旧交易密码验证成功,如果否,则旧交易密码验证失败。
然后,在步骤26,在旧交易密码验证成功的情况下,服务器向用户设备发送验证指示2,指示用户设备对用户进行手机短信验证,随后服务器向用户手机发送短信验证码。
接着,在步骤27,用户设备响应验证指示2,展示手机短信验证页面,用户通过手机短信验证页面输入手机上接收到的“短信验证码”并提交,用户设备将用户提交的“短信验证码”作为待验证信息发送给服务器。
接着,在步骤28,服务器验证用户提交的“短信验证码”是否为之前发送给该用户的真实“短信验证码”,如果是,则手机短信验证成功,如果否,则手机短信验证失败。
在步骤29,如果旧交易密码验证成功,并且手机短信验证成功,服务器判定用户验证成功,允许用户执行“修改交易密码”的操作,指示用户设备可向用户展示修改交易密码的业务页面。
接着,在步骤210,用户设备根据服务器的指示,向用户展示修改交易密码的业务页面,用户通过该业务页面填写新的交易密码并提交,用户设备将用户的新的交易密码发送给服务器进行存储。
在步骤211,如果旧交易密码验证失败或者手机短信验证失败,服务器拒绝用户执行“修改交易密码”的操作。
上述实施例,基于“修改交易密码”敏感操作的验证配置信息,使得用户先验证旧交易密码,然后验证手机短信验证码,二者均验证通过,才允许执行“修改交易密码”敏感操作。重新配置“修改交易密码”敏感操作的验证配置信息,就可以更改“修改交易密码”敏感操作对应的验证流程,不需要应用升级,提高了用户验证的灵活性和安全性。
本公开不仅可以动态地确定业务操作对应的验证流程,而且还可以实现历史验证信息的可追溯。此外,历史验证信息还可以存储在区块链中,使得历史验证信息不容易被篡改,提高了历史验证信息的可靠性。下面结合图3进行描述。
图3为本公开易追溯的用户验证方法一些实施例的流程示意图。如图3所示,该实施例的方法包括步骤31-311:
在步骤31,用户设备响应用户执行的预设业务操作,向服务器发送用户执行预设业务操作的请求。
本步骤31的更多详细内容可以参考步骤11,这里不再赘述。
在步骤32,服务器接收用户设备发送的用户执行预设业务操作的请求,服务器根据验证配置信息确定预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序。
本步骤32的更多详细内容可以参考步骤12,这里不再赘述。
在步骤33,服务器按照验证顺序依次向用户设备发送验证指示,每次验证的验证指示携带本次验证的验证方式以及上次验证的第一令牌,其中,第一次验证的验证指示携带的是初始令牌。
其中,可以利用哈希算法生成令牌,即,将相关信息输入哈希算法,输出值为令牌,令牌为相关信息的摘要信息。在追溯信息时,通过校验令牌,可以确定相关信息是否被篡改,如果计算的相关信息的令牌与真实令牌不符,说明相关信息可能被篡改。
在本公开中,将上次验证的令牌和本次验证的相关信息输入哈希算法,输出得到本次验证的令牌。本次验证的相关信息包括用户提交的本次验证的待验证信息以及验证结果等信息。
初始令牌例如可以根据预设业务操作类型、操作发起时间、操作人等信息生成。即,将预设业务操作类型、操作发起时间、操作人等信息输入哈希算法,输出得到初始令牌。
在步骤34,用户设备依次接收服务器发送的验证指示,顺序地按照各次验证的验证指示指明的验证方式对用户进行验证,并向服务器同时返回用户提交的本次验证的待验证信息和上次验证的第一令牌。
如果预设业务操作对应一种验证方式,则步骤35-36会被执行一次,如果预设业务操作对应多种验证方式,则步骤35-36会被执行多次,且执行次数等于预设业务操作对应的验证方式的数量。
在步骤35,服务器接收用户设备返回的上次验证的第一令牌和用户提交的本次验证的待验证信息,先对第一令牌进行校验,如果第一令牌合法,再对本次验证的待验证信息进行验证,如果本次验证的待验证信息验证通过,说明本次验证成功,如果第一令牌不合法或者本次验证的待验证信息验证未通过,说明本次验证失败。
例如,如果第一令牌的格式符合要求且存在,则认为校验成功,否则,认为校验失败。
在验证待验证信息之前,先对令牌进行校验,使得验证过程不容易被伪冒,提高了验证过程的安全性。
在步骤36,服务器根据上次验证的第一令牌和本次验证的相关信息生成本次验证的第二令牌,将第二令牌与第一令牌和本次验证的相关信息进行关联性存储,其中,本次验证的相关信息包括本次验证的待验证信息以及验证结果等信息。
其中,可以将每次验证的关联性存储信息保存到区块链中,使得历史验证信息不容易被篡改,提高了历史验证信息的可靠性。
在步骤37,服务器根据各次验证的待验证信息确定用户是否验证成功,如果用户验证成功,允许用户执行预设业务操作,如果用户验证失败,拒绝用户执行预设业务操作。
本步骤37的更多详细内容可以参考步骤15,这里不再赘述。
在步骤38,如果用户验证成功,服务器向用户设备发送最终令牌。
在步骤39,用户设备展示预设业务操作的业务页面,并返回用户基于业务页面提交的业务操作信息和最终令牌。
在步骤310,服务器对返回的最终令牌进行校验,如果校验成功,接受用户提交的业务操作信息,如果校验失败,拒绝用户提交的业务操作信息。
例如,如果最终令牌的格式符合要求且存在,则认为校验成功,否则,认为校验失败。此外,服务器还可以规定最终令牌的时效性,从而进一步提高用户业务操作的安全性。如果最终令牌的格式符合要求且存在,并且在有效期内,认为校验成功,否则,认为校验失败。
在步骤311,服务器将最终令牌与用户提交的业务操作信息以及最终令牌的校验结果等信息进行关联性存储。
通过服务器的多次关联性存储,业务操作及其验证过程中的多个数据块形成链式结构,易于追溯。此外,如前所述,这些数据块可以保存在区块链中,形成数据区块链,提高数据的安全性和可靠性。
假设某个业务操作对应n种验证方式,则服务器最终形成(n+2)个数据块的链式结构。如图4所示,初始令牌对应的数据块0包括初始令牌以及业务操作类型、操作发起时间、操作人等业务操作请求信息;令牌1对应的数据块1包括令牌1、初始令牌以及第一次验证的相关信息;令牌2对应的数据块2包括令牌2、令牌1以及第二次验证的相关信息;以此类推,最终令牌对应的数据块(n+1)包括最终令牌、令牌n、用户提交的业务操作信息以及最终令牌的校验结果等信息。每次验证的数据块存储有前一次验证的令牌,由此可以追溯前一次验证的数据块。例如,通过第二次验证的数据块2中的令牌1可以追溯到第一次验证的数据块1。
上述实施例,不仅可以动态地确定业务操作对应的验证流程,而且还实现了历史验证信息的可追溯。
下面以“修改交易密码”敏感操作为例,说明用户验证方法。
如图5所示,在步骤51,服务器配置“修改交易密码”敏感操作的验证配置信息,例如服务器配置需要验证旧交易密码以及手机短信验证码,且验证顺序为先验证旧交易密码,然后验证手机短信验证码。
在步骤52,用户设备检测到用户执行“修改交易密码”的操作,向服务器发送用户执行“修改交易密码”操作的请求。
接着,在步骤53,服务器响应该请求,根据“修改交易密码”敏感操作的验证配置信息,向用户设备发送验证指示1,其中携带验证方式1和初始令牌,验证方式1指示用户设备对用户进行旧交易密码验证,初始令牌例如为用户信息、“修改交易密码”的操作类型以及操作发起时间等信息的哈希值。
接着,在步骤54,用户设备响应验证指示1,展示旧交易密码验证页面,用户通过旧交易密码验证页面输入“旧交易密码”并提交,用户设备将初始令牌以及用户提交的“旧交易密码”作为待验证信息发送给服务器。
接着,在步骤55,服务器先校验初始令牌是否合法,如果初始令牌合法,再验证用户提交的“旧交易密码”是否为该用户真实的“旧交易密码”,如果是,则旧交易密码验证成功,如果否,则旧交易密码验证失败。服务器根据初始令牌和第一次验证的相关信息(如用户提交的“旧交易密码”,以及旧交易密码验证成功或失败的验证结果)生成第一次验证的令牌1,将令牌1与初始令牌和第一次验证的相关信息进行关联性存储,进一步的,可关联性存储到区块链中。
其中,如果初始令牌的格式符合要求且存在,则判定初始令牌合法,否则,判定初始令牌不合法。
然后,在步骤56,在旧交易密码验证成功的情况下,服务器向用户设备发送验证指示2,其中携带验证方式2和上次验证的令牌1,验证方式2指示用户设备对用户进行手机短信验证,随后服务器向用户手机发送短信验证码。
接着,在步骤57,用户设备响应验证指示2,展示手机短信验证页面,用户通过手机短信验证页面输入手机上接收到的“短信验证码”并提交,用户设备将令牌1和用户提交的“短信验证码”作为待验证信息发送给服务器。
接着,在步骤58,服务器先校验令牌1是否合法,如果令牌1合法,再验证用户提交的“短信验证码”是否为之前发送给该用户的真实“短信验证码”,如果是,则手机短信验证成功,如果否,则手机短信验证失败。服务器根据令牌1和第二次验证的相关信息(如用户提交的“短信验证码”,以及手机短信验证成功或失败的验证结果)生成第二次验证的令牌2,将令牌2与令牌1和第二次验证的相关信息进行关联性存储,进一步的,可关联性存储到区块链中。
其中,如果令牌1的格式符合要求且存在,则判定令牌1合法,否则,判定令牌1不合法。
在步骤59,如果旧交易密码验证成功,并且手机短信验证成功,服务器判定用户验证成功,允许用户执行“修改交易密码”的操作,指示用户设备可向用户展示修改交易密码的业务页面,同时向用户设备发送最终令牌。
最终令牌例如为用户信息、“修改交易密码”的操作类型以及当前时间等信息的哈希值。
接着,在步骤510,用户设备根据服务器的指示,向用户展示修改交易密码的业务页面,用户通过该业务页面填写新的交易密码并提交,用户设备将最终令牌以及用户的新的交易密码发送给服务器。
接着,在步骤511,服务器先校验最终令牌是否合法,如果最终令牌合法,再接受并记录用户提交的新的交易密码,如果最终令牌不合法,拒绝用户提交的新的交易密码。服务器将最终令牌与令牌2和新的交易密码等信息进行关联性存储,进一步的,可关联性存储到区块链中。
在步骤512,如果旧交易密码验证失败或者手机短信验证失败,服务器拒绝用户执行“修改交易密码”的操作。
如图6所示,针对用户的“修改交易密码”敏感操作,则服务器最多形成4个数据块的链式结构,分别为初始令牌对应的数据块0,令牌1对应的数据块1,令牌2对应的数据块2,最终令牌对应的数据块3。其中,每次验证的数据块存储有前一次验证的令牌,由此可以追溯前一次验证的数据块。
上述实施例,基于“修改交易密码”敏感操作的验证配置信息,使得用户先验证旧交易密码,然后验证手机短信验证码,二者均验证通过,才允许执行“修改交易密码”敏感操作。重新配置“修改交易密码”敏感操作的验证配置信息,就可以更改“修改交易密码”敏感操作对应的验证流程,不需要应用升级,提高了用户验证的灵活性和安全性。并且,基于链式结构的数据块存储形式,使得历史验证信息易于追溯。此外,历史验证信息还可以存储在区块链中,使得历史验证信息不容易被篡改,提高了历史验证信息的可靠性。
图7为本公开用于用户验证的服务器一些实施例的示意图。如图7所示,该实施例的服务器70包括:
存储器71;以及
耦接至71的处理器72,处理器72被配置为基于存储在存储器中的指令,执行任一个实施例中的用户验证方法。
例如,接收用户设备发送的用户执行预设业务操作的请求;根据验证配置信息确定所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序;按照所述验证顺序依次指示所述用户设备按照相应的验证方式对所述用户进行验证,并通过所述用户设备获取所述用户提交的待验证信息;根据所述待验证信息确定所述用户是否验证成功,如果所述用户验证成功,允许所述用户执行所述预设业务操作,如果所述用户验证失败,拒绝所述用户执行所述预设业务操作。
又例如,按照所述验证顺序依次向所述用户设备发送携带相应验证方式的验证指示,其中,每次验证的验证指示还携带上次验证的第一令牌,其中,第一次验证的验证指示携带的是初始令牌;接收所述用户设备返回的上次验证的第一令牌和所述用户提交的本次验证的待验证信息;根据上次验证的第一令牌和本次验证的相关信息生成本次验证的第二令牌,将第二令牌与第一令牌和本次验证的相关信息进行关联性存储,其中,所述本次验证的相关信息包括本次验证的待验证信息以及验证结果。
其中,存储器71例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)以及其他程序等。
图8为本公开用于用户验证的用户设备一些实施例的示意图。如图8所示,该实施例的用户设备80包括:
存储器81;以及
耦接至81的处理器82,处理器82被配置为基于存储在存储器中的指令,执行任一个实施例中的用户验证方法。
例如,响应用户执行的预设业务操作,向服务器发送所述用户执行所述预设业务操作的请求,以使得所述服务器根据验证配置信息确定所述预设业务操作对应的至少一种验证方式以及每种验证方式的验证顺序,并按照所述验证顺序依次指示所述用户设备按照相应的验证方式对所述用户进行验证;依次接收所述服务器发送的验证指示;顺序地按照各次验证的验证指示指明的验证方式对所述用户进行验证,并向所述服务器返回所述用户提交的待验证信息,以使得所述服务器根据所述待验证信息,确定所述用户是否验证成功。
又例如,每次验证的验证指示还携带上次验证的第一令牌,其中,第一次验证的所述验证指示携带的是初始令牌;向所述服务器同时返回所述用户提交的待验证信息和上次验证的第一令牌,以使得所述服务器根据上次验证的第一令牌和本次验证的相关信息生成本次验证的第二令牌,将第二令牌与第一令牌和本次验证的相关信息进行关联性存储,进一步的,可以关联性存储到区块链中,其中,所述本次验证的相关信息包括本次验证的待验证信息以及验证结果。
又例如,接收所述服务器发送的最终令牌,展示所述预设业务操作的业务页面,获取所述用户基于所述业务页面提交的业务操作信息,向所述服务器返回所述业务操作信息和所述最终令牌,以使得所述服务器根据返回的所述最终令牌的校验结果,接受或拒绝所述用户提交的业务操作信息。
其中,存储器81例如可以包括系统存储器、固定非易失性存储介质等。系统存储器例如存储有操作系统、应用程序、引导装载程序(Boot Loader)以及其他程序等。
图9为本公开用户验证系统一些实施例的示意图。如图9所示,该实施例的用户验证系统90包括:服务器70以及用户设备80。
在通常情况下,一台服务器70可以为多个用户设备80提供验证服务。
本公开还提出一种非瞬时性计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现任一个实施例的用户验证方法。
本领域内的技术人员应当明白,本公开的实施例可提供为方法、系统、或计算机程序产品。因此,本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本公开是参照根据本公开实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解为可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述仅为本公开的较佳实施例,并不用以限制本公开,凡在本公开的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。