跨应用的单态登录方法及装置与流程

文档序号:12729662阅读:313来源:国知局
跨应用的单态登录方法及装置与流程

本申请涉及通信领域,尤其涉及跨应用的单态登录方法及装置。



背景技术:

随着移动互联网的发展,用户的移动终端中安装的应用也越来越多。为了避免用户针对不同的应用进行重复登录,当用户成功登录移动终端上某一个应用后,通常可以在与该应用对应的服务端上保存该应用的登录状态,并为该登录状态设置有效期限,在有效期限内用户可以直接使用该应用,而不需要进行重复登录。

然而,通过保存应用的登录状态,虽然可以有效避免用户针对不同的应用进行重复登录,但一旦用户的移动终端发生遗失,移动终端上的应用将处于一种“免登录”即可使用的状态,因此可能会造成用户隐私泄露或者财产损失。



技术实现要素:

有鉴于此,本申请提供一种跨应用的单态登录方法,包括:

当成功登录第一终端上同一账号体系下的多个应用时,记录所述多个应用的登录状态信息;所述登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;

当基于相同的登录账号成功登录第二终端上的所述多个应用中的任一应用时,查询所述登录状态信息,获取所述多个应用中对应的安全风险等级高于该应用的其它应用;

清除该应用以及所述其它应用的登录状态信息,以使所述第一终端上已成功登录的该应用以及所述其它应用退出登录状态。

可选的,所述登录状态信息还包括自动登录验证标识;其中,所述自动登录验证标识被预先设置了有效期限;

所述方法还包括:

将所述自动登录验证标识返回至与所述登录账号对应的登录应用。

可选的,还包括:

接收到所述第一终端上任一应用发送的应用请求;所述应用请求中携带自动登录验证标识以及应用标识;

基于所述应用标识查找对应的登录状态信息;

如果未查找到与该应用标识对应的登录状态信息,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

可选的,还包括:

如果查找到与该应用标识对应的登录状态信息,校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致;

如果不一致,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

可选的,所述校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致之前,还包括:

判断查找到的所述登录状态信息中记录的自动登录验证标识的有效期限是否超时;

如果超时,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

本申请还提出一种跨应用的单态登录装置,包括:

记录模块,当成功登录第一终端上同一账号体系下的多个应用时,记录所述多个应用的登录状态信息;所述登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;

查询模块,当基于相同的登录账号成功登录第二终端上的所述多个应用中的任一应用时,查询所述登录状态信息,获取所述多个应用中对应的安全风险等级高于该应用的其它应用;

清除模块,清除该应用以及所述其它应用的登录状态信息,以使所述第一终端上已成功登录的该应用以及所述其它应用退出登录状态。

可选的,所述登录状态信息还包括自动登录验证标识;其中,所述自动登录验证标识被预先设置了有效期限;

所述记录模块进一步:

将所述自动登录验证标识返回至与所述登录账号对应的登录应用。

可选的,还包括:

接收模块,接收到所述第一终端上任一应用发送的应用请求;所述应用请求中携带自动登录验证标识以及应用标识;基于所述应用标识查找对应的登录状态信息;

返回模块,如果未查找到与该应用标识对应的登录状态信息,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

可选的,所述返回模块进一步:

如果查找到与该应用标识对应的登录状态信息,校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致;

如果不一致,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

可选的,所述返回模块进一步:

在校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致之前,判断查找到的所述登录状态信息中记录的自动登录验证标识的有效期限是否超时;

如果超时,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

由以上技术方案可见,本申请通过在成功登录第一终端上同一账号体系下的多个应用时,记录该多个应用的登录状态信息;该登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;当基于相同的登录账号成功登录第二终端上的该多个应用中的任一应用时,可以查询所述登录状态信息,获取该多个应用中对应的安全风险等级高于该应用的其它应用,并清除该应用以及所述其它应用的登录状态信息,以使第一终端上已成功登录的该应用以及所述其它应用退出登录状态;实现了当用户的移动终端发生丢失,用户只需在另一个移动终端上重新登录同一账号体系下的任一应用,就可以将发生丢失的移动终端上,已成功登录的该应用,以及与该应用处于同一账号体系下的安全风险等级高于该应用的其它应用,退出登录状态,从而可以最大程度的避免由于移动终端丢失而造成的用户隐私泄露以及财产损失。

附图说明

图1是本申请一示例性实施例中一种跨应用的单态登录方法的流程图;

图2是本申请一实施例提供的一种跨应用的单态登录装置的逻辑框图;

图3是本申请一实施例提供的承载所述一种跨应用的单态登录装置的服务端的硬件结构图。

具体实施方式

在相关技术中,为了避免用户针对终端上不同的应用进行重复登录,当用户使用登录账号和密码等信息,成功登录终端上某一个应用后,与该应用对应的服务端通常会记录该应用的登录状态,并为该登录状态设置有效期限,在有效期限内用户可以直接使用该应用,而不需要进行重复登录。

同时,对于用户已经成功登录,并且服务端已经记录了登录状态的应用,将呈现一种单态登录的模式。所谓单态登录,是指用户使用相同的登录账号和密码,只能在一台终端上登录某应用,而无法在多台终端上同时登录该应用。

一方面,当用户使用登录账号和密码,成功登录第一终端上某一个应用,并且服务端已记录了该应用的登录状态后,如果此时用户使用相同的登录账号和密码在第二终端上成功登录该应用,服务端则可以将已经记录的该应用在第一终端上的登录状态清除,从而使得该应用在第一终端上退出登录状态。

另一方面,用户的终端上通常可能会安装同一账号体系的多个应用,在这种情况下,用户可以使用同一登录账号和密码,同时登录同一账号体系下的多个应用。

因此,当用户使用同一登录账号和密码,成功登录第一终端上同一账号体系的多个应用,并且服务端已记录了该多个应用的登录状态后,如果此时用户使用相同的登录账号和密码,在第二终端上成功登录上述多个应用中的任一应用,服务端可以将已经记录的该多个应用在第一终端上的登录状态清除,从而使得该多个应用在第一终端上均退出登录状态。

可见,通过上述单态登录模式,当用户的终端丢失后,用户可以在另一终端上重新登录某一应用,将丢失的终端上处于已登录状态的该应用,或者与该应用使用同一登录账号登录的多个应用退出登录状态,从而可以确保这些应用在丢失的终端上将不再处于一种“免登录”的状态,避免造成用户隐私泄露以及财产损失,提升应用的安全性。

然而,基于上述单态登录模式,虽然可以在某种程度上提升应用的安全性,但如果用户的终端上安装同一账号体系下的多个应用时,基于现有的单态登录模式,可能无法满足实际的安全性要求。

例如:

一方面,在用户使用登录账号和密码,成功登录第一终端上某一个应用的情形下,虽然用户的终端发生遗失后,用户可以第一时间在第二终端上使用相同的登录账号和密码重新登录该应用,退出该应用在第一终端上的登录状态;

然而,通过这种方式,用户执行一次重新登录的流程,通常只能退出一个应用在遗失终端上的登录状态,而用户的终端上安装的应用众多,因此用户的操作上将非常繁琐。而且,一旦用户遗忘了某个应用的登录账号和密码,则无法第一时间将该应用在遗失终端上到的登录状态退出,因而仍然可能造成用户的隐私泄露。

另一方面,在用户使用同一登录账号和密码,成功登录第一终端上同一账号体系的多个应用的情形下,虽然用户的终端发生遗失后,用户可以第一时间在第二终端上使用相同的登录账号和密码,重新登录以上多个应用中的任一应用,将该多个应用在第一终端上的登录状态同时退出;

然而,在实际应用中,用户终端上安装的同一账号体系下的多个应用,通常都具有独立的登录账号和密码,因而如果用户使用多个不同的登录账号和密码,分别登录第一终端上同一账号体系下的多个应用时,那么用户仍然需要在第二终端上针对各应用分别执行重新登录流程,来退出以上各应用在遗失终端上的登录状态,从而仍会面临用户操作非常繁琐,以及一旦用户遗忘了某个应用的登录账号和密码,可能造成的用户的隐私泄露的问题。

有鉴于此,本申请提出一种跨应用的单态登录方法,对现有的“单态登录”机制进行了改进,通过在成功登录第一终端上同一账号体系下的多个应用时,记录该多个应用的登录状态信息;该登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;当基于相同的登录账号成功登录第二终端上的该多个应用中的任一应用时,可以查询所述登录状态信息,获取该多个应用中对应的安全风险等级高于该应用的其它应用,并清除该应用以及所述其它应用的登录状态信息,以使第一终端上已成功登录的该应用以及所述其它应用退出登录状态;实现了当用户的移动终端发生丢失,用户只需在另一个移动终端上重新登录同一账号体系下的任一应用,就可以将发生丢失的移动终端上,已成功登录的该应用,以及与该应用处于同一账号体系下的安全风险等级高于该应用的其它应用,退出登录状态,从而可以最大程度的避免由于移动终端丢失而造成的用户隐私泄露以及财产损失。

下面通过具体实施例并结合具体的应用场景对本申请进行描述。

请参考图1,图1是本申请一示例性实施例提供的一种跨应用的单态登录方法的流程图,应用于服务端,该方法可以包括以下步骤:

步骤101,当成功登录第一终端上同一账号体系下的多个应用时,记录所述多个应用的登录状态信息;所述登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级。

步骤102,当基于相同的登录账号成功登录第二终端上的所述多个应用中的任一应用时,查询所述登录状态信息,获取所述多个应用中对应的安全风险等级高于该应用的其它应用;

步骤103,清除该应用以及所述其它应用的登录状态信息,以使所述第一终端上已成功登录的该应用以及所述其它应用退出登录状态。

上述第一终端以及第二终端,均可以是用户的移动终端;例如,智能手机、平板电脑等。在上述第一终端和第二终端上,均可以安装同一账号体系下的多个应用。

上述服务端,可以包括面向用户的终端上安装的同一账号体系下的多个应用,提供服务的服务端平台。其中,该服务端平台,具体可以是一服务器,也可以是一服务器集群,或者基于服务器集群构建的云平台。

在相关技术中,应用的开发者在开发应用时,通常都会为该应用设计独立的账号体系。通过为该应用设计独立的账号体系,可以将该应用产生的用户数据与用户的账号之间进行关联,从而到达将应用面向用户提供的服务,与用户的身份之间进行关联的目的。

在实际应用中,如果希望多个不同的应用之间的用户数据和服务能够共享,通常可以为该多个应用建立统一的账号体系,或者将该多个应用的账号体系在横向打通,将其纳入到同一个账号体系之中。

例如,不同的公司或者集团,通常会面向用户提供大量不同的应用,这些应用的账号体系通常互相独立,因此为了实现这些应用之间的用户数据和服务能够共享,可以将这些应用纳入到同一个账号体系;比如,以阿里巴巴集团为例,其面向用户提供支付宝、淘宝以及蚂蚁理财等APP的账号,通常会被纳入于阿里巴巴集团的同一账号体系之中。

当多个不同的应用被纳入到同一个账号体系之中后,各应用的服务端将处于同一个服务平台之中,各应用的服务端之间可以进行数据以及权限的互通和共享。

一方面,用户使用该同一个账号体系下的任一应用的登录账号,可以直接登录该账号体系下的其它应用,享受该其它应用面向用户提供的服务。

另一方面,当用户使用登录账号成功登录该账号体系下的任一应用,并且该应用对应的服务端在后台记录了该应用的登录状态后,由于同一个账号体系下的各应用对应的服务端之间可以实现数据互通和共享,因此该应用的服务端记录的该登录状态,将可以被该账号体系下的其它应用的服务端访问到。在这种情况下,被该账号体系下的其它应用的服务端可以直接认可该登录状态,从而当用户在成功登录同一个账号体系下的某一应用时,可以在不重新登录该账号体系下的其它应用的前提下,直接取得其它应用相关数据的访问权限(比如一些需要登录后才能够取得的权限)。

例如,仍以阿里巴巴集团为例,阿里巴巴集团面向用户提供的支付宝、淘宝以及蚂蚁理财等APP可以被纳入同一账号体系,这些APP对应的服务端,可以隶属于同一服务端平台,实现数据以及权限的互通和共享;

一方面,用户可以使用支付宝、淘宝以及蚂蚁理财等APP中任一APP的登录账号,直接登录该账号体系下的其它APP;比如,服务端平台可以授权用户使用支付宝APP的账号,来登录淘宝或者蚂蚁理财等APP;此时用户可以通过使用支付宝APP的账号直接登录淘宝或者蚂蚁理财等APP。

另一方面,支付宝、淘宝以及蚂蚁理财等APP对应的服务端之间可以实现数据的互通和共享,用户成功登录支付宝、淘宝以及蚂蚁理财等APP中的任一APP后,该APP对应的服务端在后台记录的登录状态,可以共享给其它APP的服务端,从而用户通过登录支付宝、淘宝以及蚂蚁理财等APP中的任一APP后,可以直接取得其它APP相关数据的访问权限;比如,用户成功登录支付宝APP后,支付宝的服务端可以将记录的用户的登录状态共享给淘宝或者蚂蚁理财等APP的服务端,从而用户可以在支付宝APP中直接跳转至淘宝或者蚂蚁理财等APP,享受淘宝或者蚂蚁理财等APP面向用户提供的服务,而不需要使用淘宝或者蚂蚁理财等APP的账号执行重复的登录认证。

在本例中,用户可以通过在APP的登录界面中输入登录账号和密码等信息,来登录第一终端上同一账号体系下的多个应用。

其中,用户在登录同一账号体系下的上述多个应用时,可以使用同一登录账号和密码,同时登录上述多个应用;也可以使用上述多个应用各自的独立登录账号,来分别登录上述多个应用。

例如,假设第一终端上安装了隶属于阿里巴巴集团的账号体系下的支付宝、淘宝以及蚂蚁理财等APP,用户可以使用支付宝APP的登录账号,同时登录支付宝、淘宝以及蚂蚁理财等APP,也可以使用支付宝、淘宝以及蚂蚁理财等APP各自的登录账号,分别登录支付宝、淘宝以及蚂蚁理财等APP。

在本例中,对于同一账号体系下的应用,可以预先分别定义对应的安全风险等级。

其中,在为同一账号体系下的应用定义安全风险等级时,所采用的具体策略,在本例中不进行特别限定,可以基于实际的业务需求由应用的开发人员或者管理人员,在服务端一侧进行自定义。

在示出的一种实施方式中,在为同一账号体系下的应用定义安全风险等级时,可以基于各应用的类型以及特点,将各应用划分为若干个分类,然后针对每一个分类的应用实际存在的风险特性,来分别定义安全风险等级。

例如,可以将同一账号体系下的应用,划分为工具类、社交类以及理财类。工具类的应用,通常不会涉及到用户的隐私数据,因此可以为工具类的应用,定义一个最低的安全风险等级。社交类的应用,通常会涉及到大量用户的个人信息以及隐私数据,因此可以为社交类的应用定义一个较高的安全风险等级。而理财类的应用,通常会涉及到用户的财产安全,因而可以为理财类的应用定义一个最高的安全风险等级。

当然,在实际应用中,在为同一账号体系下的应用定义安全风险等级时,所采用的具体策略,并不限于以上示出的具体策略,本领域技术人员可以基于实际的需求灵活的进行选择。

在本例中,当用户通过输入登录账号和密码,成功登录第一终端上同一账号体系下的多个应用时,此时上述服务端可以在后台记录该多个应用的登录状态信息,以保存该多个应用的登录状态。

在相关技术中,上述服务端生成的上述登录状态信息中,通常可以包括登录账号、应用标识、以及自动登录验证标识等信息。

在本例中,可以对上述登录状态信息中所包含的信息进行扩展,在上述登录状态信息中进一步引入为该应用预先定义的安全风险等级。即上述服务端为用户成功的登录的应用生成的登录状态信息,除了可以包含登录账号、应用标识以及自动登录验证标识等信息以外,还可以包含为该应用预先定义的安全风险等级。

其中,上述登录账号,即为用户成功登录该应用所使用的账号。

上述应用标识,即为用户本次成功登录的应用的标识;比如,在Android系统中,该应用标识可以是该应用的包名(Package Name)。

上述自动登录验证标识,可以是用户在成功登录上述应用时,上述服务端基于一定的随机算法,针对上述应用上传的参数进行计算得到的一个随机字符串。

其中,该自动登录验证标识还可以预先设置一个有效期限(比如三个月),使得该自动登录验证标识可以只在一定的期限内有效,从可以避免该应用一直处于“免登录”状态。

在示出的一种实施方式中,上述自动登录验证标识,可以是用户在成功登录终端上的应用后,上述服务端基于预设的随机算法(比如hash算法)为该应用生成的一个Token ID。

用户在登录终端上的应用时,除了需要向与该应用对应的服务端提交登录账号和密码等登录认证信息以外,还可以向上述服务端提交用于生成上述Token ID的参数,当用户登录认证通过成功登录该应用后,上述服务端可以基于预设的随机算法对用户提交的该参数进行计算,为该应用生成Token ID。

其中,上述用于生成上述Token ID的参数,在本实施例中不进行特别限定,在实际应用中,生成上述Token ID的参数可以由应用与服务端之间进行协商;比如,用于生成上述Token ID的参数可以包括应用在启动时随机生成的字符串、用户终端的IMEI(International Mobile Equipment Identity,国际移动设备身份码)码、IMSI(International Mobile Subscriber Identity,国际移动用户识别码、或者由应用生成的虚拟IMEI码和虚拟IMSI码。

需要说明的是,上述自动登录验证标识,除了可以是上述服务端在用户成功登录应用时,为该应用生成的Token ID以外,也可以是诸如Cookie、Session等随机字符串,在本例中不再一一详述,本领域技术人员在将本申请记载的技术方案付诸实施时,可以参考现有技术中的记载。

在本例中,上述服务端为用户成功登录的第一终端上的多个应用,分别生成了上述自动登录验证标识后,还可以将该自动登录标识返回给第一终端上对应的登录应用。第一终端上的这些应用,在收到该服务端返回的该自动登录标识后,可以将该自动登录标识在其本地进行缓存。

后续当用户操作第一终端上的任一应用时,该应用可以向上述服务端发送应用请求;其中,在该应用请求中,可以携带该应用的应用标识,以及服务端向该应用返回的上述作为自动登录标识的随机字符串。

当服务端在收到该应用发送的应用请求后,可以将该应用请求中的应用标识作为索引,在已经记录的登录状态信息中查找与该应用对应的登录状态信息。

当查找到与该应用对应的登录状态信息后,该服务端可以判断查找到的该登录状态信息中记录的自动登录验证标识的有效期限是否超时。

一方面,如果未超过,此时该应用的登录状态有效。

在这种情况下,上述服务端可以进一步校验该应用请求中携带的自动登录验证标识,该查找到的该登录状态信息中记录的自动登录验证标识是否一致;如果一致,此时上述服务端可以确认该应用为已登录状态,上述服务端可以向该应用返回与上述应用请求对应的数据即可,此时该应用无需执行重新登录流程。如果不一致,上述服务端可以向上述第一终端返回一个错误消息。

其中,该错误消息可以是一个触发消息,在该错误消息中可以携带该应用的应用标识。当第一终端接收到该错误消息后,可以读取该错误消息中携带的应用标识,将与该应用标识对应的该应用退出登录状态,并输出登录界面,以提示用户重新输入登录账号和密码,完成重新登录流程。

另一方面,如果已超过,此时该应用的登录状态无效。

在这种情况下,上述服务端可以向上述第一终端返回上述错误消息;上述第一终端接收到该错误消息后,可以将该应用退出登录状态,并输出登录界面,以提示用户重新输入登录账号和密码,完成重新登录流程。

通过以上的描述可知,当用户成功登录第一终端上同一账号体系的多个应用后,上述服务端可以通过记录该多个应用的登录状态信息,来保存该多个应用的登录状态。对于该多个应用中的任一应用来说,都可以在向上述服务端发送的应用请求中携带正确的自动登录认证标识,由上述服务端对该自动登录认证标识进行校验后,来维持该多个应用在上述自动登录验证标识的有效期限内,处于一种“免登录”的状态,从而可以避免用户在操作应用的过程中,重复执行登录流程。

在本例中,当用户成功登录第一终端上同一账号体系下的多个应用后,如果用户的第一终端发生遗失,为了最大程度的保证用户隐私和财产安全,可以对现有的“单态登录”机制进行改进,使得用户可以在第二终端上登录上述多个应用中的任一应用,将第一终端上的该应用,以及安全风险等级高于该应用的其它应用,同时踢出登录状态。

以下结合用户使用不同的多个不同的登录账号和密码,分别登录第一终端上同一账号体系下的多个应用的使用场景为例,对本申请改进后的“单态登录”机制的实现过程进行详述。

在本例中,当用户的第一终端发生遗失,由于用户已在第一终端上成功登录了同一账号体系下的多个应用,并且该多个应用已有上述服务端保存了登录状态,处于一种“免登录”的状态,因此用户可能会面临着隐私泄露以及财产损失的风险。

基于现有的“单态登录”机制,用户可以使用上述多个应用各自的登陆账号和密码,分别在第二终端上重新登录上述多个应用,来触发上述服务端将已记录的上述多个应用的登录状态信息依次清除,将第一终端上已经成功登录的上述多个应用依次踢出登录状态。

可见,基于现有的“单态登录”机制,用户需要在第二终端上针对上述多个应用依次执行重新登录的操作,非常繁琐,而且一旦用户遗忘了某个应用的登录账号和密码,仍然无法踢出该应用在第一终端上的登录状态。

在本例中,当用户的第一终端发生遗失,此时用户仍然可以通过输入登录账号和密码,在第二终端上重新登录上述多个应用中的任一应用。

当用户在第二终端上重新登录了上述多个应用中的任一用户后,此时上述服务端已经记录了上述多个应用在第一终端上的登录状态信息:

一方面,上述服务端可以清除已经记录的该应用在第一终端上的登录状态信息;其中,上述服务端在清除已经记录的登录状态信息时,可以采用直接删除的方式,也可以采用将该登录状态信息标记为无效的方式,在本例中不进行特别限定。

当该应用在第一终端上的登录状态信息被清除后,后续捡拾到第一终端的用户在第一终端上操作该应用时,由于该应用在上述服务端上记录的登录状态信息已经被清除,该应用在第一终端上将不再处于一种“免登录”状态,该服务端对第一终端上的该应用发送的应用请求进行处理后,会向该第一终端返回错误消息,触发第一终端将该应用退出登录状态,并输出登录界面,以提示用户重新输入登录账号和密码,完成重新登录流程。在这种情况下,捡拾到第一终端的用户无法获知正确的登录账号和密码,因此可以确保该应用的安全性。

另一方面,由于上述服务端记录的上述多个应用在第一终端上的登录状态信息中,还记录了该多个应用对应的安全风险等级,因此上述服务端除了可以清除用户在第二终端上重新登录的上述应用的登录状态信息,还可以通过查询已经记录的上述多个应用在第一终端上的登录状态信息,获取该多个应用中对应的安全风险等级高于该应用的其它应用。

当查询到安全风险等级高于该应用的其它应用后,上述服务端还可以将已经记录的该其它应用在第一终端上的登录状态信息,也一并清除。

当服务端将已经记录的该其它应用在第一终端上的登录状态信息,也一并清除以后,除了用户在第二终端上重新登录的应用以外,同一账号体系下的上述多个应用中,安全风险等级高于该应用的其它应用,在第一终端上也将不再处于一种“免登录”状态。

捡拾到第一终端的用户在第一终端上操作这些安全风险等级高于该应用的其它应用时,服务端对第一终端上的这些应用发送的应用请求进行处理后,仍然会向该第一终端返回错误消息,触发第一终端将该这些应用退出登录状态,并输出登录界面,以提示用户重新输入登录账号和密码,完成重新登录流程。

当然,需要说明的是,对于安全风险等级低于该应用的其它应用,在第一终端上将仍然处于一种“免登录”的状态,捡拾到第一终端的用户仍然可以进入这些应用进行正常操作。

可见,通过这种方式,当用户的第一终端发生遗失,用户通过在第二终端上重新登录已在第一终端上成功登录的同一账号体系下的多个应用中的任意一个应用,就可以将该应用,以及该多个应用中安全风险等级高于该应用的其它应用也一并踢出登录状态,从而可以在用户的移动终端发生丢失的情况下,最大程度的避免用户隐私泄露以及财产损失。

以下以上述应用为移动终端上安装的APP为例,通过一个具体的实例对以上实施例中的技术方案进行详细阐述。当然,在实际应用中,上述应用也可以是web应用,在本例中不再进行详述。

假设用户的第一终端上安装了同一账号体系下的APP1、APP2和APP3。APP1、APP2和APP3的登录账号分别为账号1、账号2和账号3。预先定义的安全风险等级为APP1>APP2>APP3。

用户使用账号1、账号2和账号3成功在第一终端上登录了APP1、APP2和APP3后,一方面,服务端可以为APP1、APP2和APP3分别生成Token ID,并将生成的Token ID分别返回给APP1、APP2和APP3;另一方面,服务端可以分别记录APP1、APP2和APP3的登录状态信息,在记录的登录状态信息中,除了各APP的登录账号、APP标识以及自动登录验证标识以外,还包括各APP对应的安全风险等级。

如果用户的第一终端发生遗失,用户可以第一时间在第二终端上重新登录APP1、APP2和APP3中的任意一个APP。

假设用户在第二终端上重新登录的APP为APP3,当登录成功后,服务端可以查询已经记录的APP1、APP2和APP3的登录状态信息,获取安全风险等级高于APP3的其它APP。

由于预先定义的安全风险等级为APP1>APP2>APP3,此时APP1和APP2的安全风险等级均高于APP3,服务端可以将已经记录的APP1、APP2和APP3在第一终端上的登录状态信息全部清除。

当服务端将APP1、APP2和APP3在第一终端上的登录状态信息全部清除后,捡拾到第一终端的用户在非法操作APP1、APP2和APP3时,APP1、APP2和APP3向服务端发送的应用请求中仍然携带APP表示以及服务端为各APP生成的Token ID。

当服务端收到捡拾到第一终端的用户在非法操作APP1、APP2和APP3时,第一终端发送的应用请求后,可以基于该应用请求中的APP标识查找对应的登录状态信息。由于服务端已经将APP1、APP2和APP3在第一终端上的登录状态信息全部清除,因此此时无法查找到对应的登陆状态信息,即APP1、APP2和APP3在第一终端上的“免登录”状态已经不再有效,服务端无法完成针对该应用请求中携带的Token ID的校验,因此服务端可以向第一终端返回错误消息,以触发第一终端基于该错误消息将APP1、APP2和APP3在第一终端上的登录状态退出,并输出登录界面提示捡拾到第一终端的用户,重新输入登录账号和密码完成登录。此时捡拾到第一终端的用户,无法进入APP1、APP2和APP3执行正常的APP操作,从而最大程度的保护了用户的隐私和财产安全。

通过以上实施例可知,本申请提出一种跨应用的单态登录方法,通过对现有的“单态登录”机制进行了改进,在成功登录第一终端上同一账号体系下的多个应用时,记录该多个应用的登录状态信息;该登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;当基于相同的登录账号成功登录第二终端上的该多个应用中的任一应用时,可以查询所述登录状态信息,获取该多个应用中对应的安全风险等级高于该应用的其它应用,并清除该应用以及所述其它应用的登录状态信息,以使第一终端上已成功登录的该应用以及所述其它应用退出登录状态;实现了当用户的移动终端发生丢失,用户只需在另一个移动终端上重新登录同一账号体系下的任一应用,就可以将发生丢失的移动终端上,已成功登录的该应用,以及与该应用处于同一账号体系下的安全风险等级高于该应用的其它应用,退出登录状态,从而可以最大程度的避免由于移动终端丢失而造成的用户隐私泄露以及财产损失。

与上述方法实施例相对应,本申请还提供了装置的实施例。

请参见图2,本申请提出一种跨应用的单态登录装置20,应用于服务端;其中,请参见图3,作为承载所述跨应用的单态登录装置30的服务端所涉及的硬件架构中,通常包括CPU、内存、非易失性存储器、网络接口以及内部总线等;以软件实现为例,所述跨应用的单态登录装置20通常可以理解为加载在内存中的计算机程序,通过CPU运行之后形成的软硬件相结合的逻辑装置,所述装置30包括:

记录模块301,当成功登录第一终端上同一账号体系下的多个应用时,记录所述多个应用的登录状态信息;所述登录状态信息包括登录账号,应用标识,以及与该应用对应的安全风险等级;

查询模块302,当基于相同的登录账号成功登录第二终端上的所述多个应用中的任一应用时,查询所述登录状态信息,获取所述多个应用中对应的安全风险等级高于该应用的其它应用;

清除模块303,清除该应用以及所述其它应用的登录状态信息,以使所述第一终端上已成功登录的该应用以及所述其它应用退出登录状态。

在本例中,所述登录状态信息还包括自动登录验证标识;其中,所述自动登录验证标识被预先设置了有效期限;

所述记录模块301进一步:

将所述自动登录验证标识返回至与所述登录账号对应的登录应用。

在本例中,还包括:

接收模块304,接收到所述第一终端上任一应用发送的应用请求;所述应用请求中携带自动登录验证标识以及应用标识;基于所述应用标识查找对应的登录状态信息;

返回模块305,如果未查找到与该应用标识对应的登录状态信息,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

在本例中,所述返回模块305进一步:

如果查找到与该应用标识对应的登录状态信息,校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致;

如果不一致,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

在本例中,所述返回模块305进一步:

在校验所述应用请求中携带的自动登录验证标识与该登录状态信息中记录的自动登录验证标识是否一致之前,判断查找到的所述登录状态信息中记录的自动登录验证标识的有效期限是否超时;

如果超时,向所述第一终端返回错误消息,以触发所述第一终端上已经成功登录的该应用退出登录状态,并输出登录界面执行重新登录流程。

以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1