终端应用程序的一键登录的方法、设备及系统与流程

1.本公开涉及应用程序安全领域，更具体地，涉及一种终端应用程序的一键登录的方法、设备及系统。


背景技术：

2.当前市场最常见到的终端尤其是移动终端用户进行应用程序登录的方式包括使用手机验证码登录。使用这种登录方式，负责应用程序运营的企业可以准确的验证用户的身份是否合法，用户也无需每次输入帐号和密码，一定程度上提升了用户体验。但当用户使用相同的手机号在同一个终端多次登录应用程序时，如果每次都让用户通过获取验证码的方式后才可登录，那么繁琐而耗时的操作也会使用户体验变差，甚至可能导致用户的流失。


技术实现要素：

3.针对现有技术的不足，提供了本公开以解决现有技术中存在的上述问题。
4.需要一种终端应用程序的一键登录的方法，其能够在用户首次在终端基于验证码登录应用程序的过程中，在应用程序客户端及应用程序服务器端生成并存储后续进行一键登录所需的用户身份认证的信息，从而使用户首次在终端基于验证码成功登录应用程序之后，在后续的登录过程中可以实现一键登录，不必再次输入用户帐号以及获取、输入验证码，即可在不降低安全性能的前提下实现用户身份的认证，大幅提高用户体验，降低用户的流失。
5.根据本公开的第一方案，提供一种终端应用程序的一键登录的方法，应用于终端。该方法包括当所述终端的用户的第一用户帐号在所述终端基于验证码请求登录所述应用程序时，在所述验证码验证成功的情况下，从服务器获取第一用户标识。该方法还包括生成与所述第一用户标识以及所述终端相关联的第一识别码，以及与所述第一用户标识相关联的非对称密钥对，并将所生成的非对称密钥对存储于所述终端的安全芯片内，所述非对称密钥对中的私钥不可被导出至所述安全芯片外部，以及向所述服务器发送所述非对称密钥对中的公钥和所述第一识别码，并从所述服务器接收与所述第一用户标识相关联的第二令牌。该方法进一步包括将所述第一用户帐号、所述第一用户标识、所述第一识别码和所述第二令牌关联存储作为所述应用程序的登录信息。当所述第一用户帐号在所述终端基于验证码登录成功后再次请求登录所述应用程序时，基于所述登录信息向所述服务器请求一键登录。
6.根据本公开的第二方案，提供一种终端应用程序的一键登录的方法，应用于服务器。该方法包括在所述终端的用户的第一用户帐号在所述终端基于验证码请求登录所述应用程序时，在所述验证码验证成功的情况下，向所述终端发送与所述终端以及所述第一用户帐号相关联的第一用户标识。该方法还包括接收来自所述终端的非对称密钥对中的公钥和第一识别码，其中，所述非对称密钥对由所述终端与所述第一用户标识相关联地生成，所述第一识别码由所述终端与所述第一用户标识以及所述终端相关联地生成，并向所述终端
发送与所述第一用户标识关联的第二令牌。该方法进一步包括将所述第一用户帐号、所述第一用户标识、所述第一识别码以及所述公钥关联存储于设备密钥表中。当所述第一用户帐号在所述终端基于验证码登录成功后再次请求一键登录所述应用程序时，基于所述设备密钥表确定是否允许所述第一用户帐号登录所述应用程序。
7.根据本公开的第三方案，提供一种终端，该终端包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的应用程序，所述应用程序被所述处理器运行时，执行根据本公开各个实施例的终端应用程序的一键登录的方法应用于终端的步骤。
8.根据本公开的第四方案，提供一种服务器，包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的应用程序，所述应用程序被所述处理器运行时，执行根据本公开各个实施例的终端应用程序的一键登录的方法应用于服务器的步骤。
9.根据本公开的第五方案，还提供一种用于应用程序一键登录的系统，所述系统包括至少一个执行根据本公开各个实施例的终端应用程序的一键登录的方法应用于终端的步骤的终端，以及执行根据本公开各个实施例的终端应用程序的一键登录的方法应用于服务器的步骤的服务器。
10.根据本公开各个实施例的终端应用程序的一键登录的方法，用户只需第一次在新终端上登录帐号时使用验证码登录到应用程序，后续的登录便可实现一键登录到应用程序。由于在用户首次在终端基于验证码登录应用程序的过程中，在应用程序客户端及应用程序服务器端生成并存储了后续进行一键登录所需的用户身份认证的信息，因此可以保证在后续的一键登录过程，可以实现在用户身份可认证、系统安全性能增强的情况下的用户使用体验大幅提高，降低用户流失的可能性。
附图说明
11.在不一定按比例绘制的附图中，相同的附图标记可以在不同的视图中描述相似的部件。附图大体上通过举例而不是限制的方式示出各种实施例，并且与说明书以及权利要求书一起用于对所公开的实施例进行说明。在适当的时候，在所有附图中使用相同的附图标记指代同一或相似的部分。这样的实施例是例证性的，而并非旨在作为本装置或方法的穷尽或排他实施例。
12.图1示出根据本公开实施例的用于应用程序一键登录的系统的示例性组成及其应用环境的框图；
13.图2示出根据本公开实施例的在终端基于验证码请求登录应用程序时终端的操作的流程图；
14.图3示出根据本公开实施例的在终端基于验证码请求登录应用程序时服务器的操作的流程图；
15.图4示出根据本公开实施例的在终端请求一键登录应用程序时终端的操作的流程图；
16.图5示出根据本公开实施例的在终端请求一键登录应用程序时服务器的操作的流程图；
17.图6示出根据本公开实施例的用户在终端首次基于验证码登录应用程序的示例的时序图；
18.图7示出根据本公开实施例的用户在终端一键登录应用程序的示例的时序图；以及
19.图8示出根据本公开实施例的终端的应用程序客户端的界面的示意图。
具体实施方式
20.为使本领域技术人员更好的理解本公开的技术方案，下面结合附图和具体实施方式对本公开作详细说明。下面结合附图和具体实施例对本公开的实施例作进一步详细描述，但不作为对本公开的限定。本文中所描述的各个步骤，如果彼此之间没有前后关系的必要性，则本文中作为示例对其进行描述的次序不应视为限制，本领域技术人员应知道可以对其进行顺序调整，只要不破坏其彼此之间的逻辑性导致整个流程无法实现即可。
21.除非上下文明确要求，否则整个说明书和权利要求书中的“包括”、“包含”等类似词语应当解释为包含的含义而不是排他或穷举的含义；也就是说，是“包括但不限于”的含义。
22.在本公开的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本公开的描述中，除非另有说明，“多个”的含义是两个或两个以上。
23.下面将参考附图描述本公开的各种方案以及特征。
24.图1示出根据本公开实施例的用于应用程序一键登录的系统100的示例性组成及其应用环境的框图。如图1所示，用于应用程序一键登录的系统包括服务器20和一个或多个终端，例如终端10a、终端10b等。此外，该系统的运行在一定的阶段，还需要运营商服务器30的参与，其具体的操作和信息交互将在后文中详述。在一些实施例中，运营商服务器30可以是任意的能够为终端10a和服务器20提供诸如短信、电话、互联网等验证码服务的运营商的服务器，上述运营商例如可以是诸如移动、联通、电信等手机运营商，也可以是提供互联网数据传送业务及通信设施服务业务的广电运营商等，在此不做限制。
25.在一些实施例中，终端10a和终端10b中可以分别安装有根据本公开实施例的用于应用程序一键登录的方法的应用程序客户端11a和11b，其中，应用程序客户端11a和11b执行相同或类似的功能，但其可以根据终端10a和终端10b平台、操作系统等方面的差异而采用不同的程序架构，例如基于安卓系统、windows系统、ios系统等的应用程序，在此不具体限制。
26.在一些实施例中，服务器20中可以安装有根据本公开实施例的用于应用程序一键登录的方法的应用程序服务器端21，其可以部署在本地，也可以部署在云端，只要其可以实现与系统100中的各个终端及运营商服务器30的信息交换即可。
27.在下文中，仅以终端10a为例，描述其在系统100中的操作方式，但须知，终端10b和其他的终端(未示出)与终端10a在用于应用程序一键登录的系统100中具有相同或相似的操作方式。如无特别指出是运营商服务器，则下文中提及的服务器是指应用程序的服务器。
28.在上述应用程序客户端11a和应用程序服务器端21运行时，通过终端10a、服务器20以及运营商服务器30的协同工作以及彼此之间的信息交互，来实现根据本公开实施例的用于应用程序一键登录的方法。在系统100中，终端10a与运营商服务器30之间可以为单向信息交互，即，终端10a从运营商服务器30处接收诸如短信验证码等用于基于验证码登录应
用程序所需的验证码信息。服务器20与运营商服务器30之间主要在基于验证码请求登录应用程序的过程中进行信息交互，示例性地可以包括验证码请求信息、验证码发送状态应答信息等。服务器20与终端10a之间则可以交互包括但不限于帐号信息、登录请求信息、登录结果信息、验证信息及授权信息等，以便在保证安全性的基础上，实现便捷的基于验证码请求登录应用程序或一键登录应用程序的操作。
29.在一些实施例中，例如当终端10a是用户(未示出)使用的手机，而应用程序例如可以是视频播放软件，当用户打开终端10a中的视频软件客户端11a，用户操作、运营商服务器30、应用程序客户端11a及应用程序服务器端21将协同实现根据本公开实施例的用于应用程序一键登录的方法，例如用户使用手机号作为帐号，进行基于验证码请求登录应用程序的操作，或者在该用户之前已经使用该手机号成功登录过该应用程序的情况下，也可以是不必请求验证码而直接一键登录该应用程序等。在一些实施例中，用户帐号是运营商(或者区别于应用程序服务器的另一个服务器)为终端的用户分配的帐号。在另一些实施例中，用户也可以使用其他形式的帐号进行应用程序的登录，例如在应用程序注册过程中，由用户向服务器申请的由字母和数字等组成的用户名所代表的用户帐号等。在其他一些实施例中，用户可以使用能够(例如通过短信、电话、互联网网页等)有效接收由运营商生成并发送的登录应用程序所需的验证码的任何形式的用户帐号。
30.注意，图1中示出的运营商服务器30，其在根据本公开实施例的用于应用程序一键登录的系统100中，只负责根据用户帐号的验证码请求，提供相应的验证码服务，即，只在基于验证码请求登录应用程序的处理中参与系统100的运行，而在其他的操作中，例如一键登录应用程序的过程中，不必参与系统100的运行。如此，可以大大降低应用程序和系统开发和运行的成本，包括开发和运营的费用和时间成本，特别是，一键登录应用程序的流程不涉及运营商，将可以有效避免运营商的服务质量波动对系统100运行的影响，从而为用户提供稳定的用户体验。
31.图2示出根据本公开实施例的在终端基于验证码请求登录应用程序时终端的操作的流程图。本公开实施例的终端应用程序的一键登录的方法，可以应用于终端和服务器，并且可以包括两种不同的登录方式，第一种登录方式为，当终端的用户使用用户帐号在该终端基于验证码请求登录应用程序的方式，以及第二种登录方式，当上述用户帐号在同一终端基于验证码登录成功后再次请求登录该应用程序时，基于登录信息向服务器请求一键登录的方式。在不同的登录方式中，终端和服务器分别执行不同的操作。
32.为便于区分和描述，本公开实施例中将某个终端的用户所使用的用户账号称为第一用户账号，并以此为例介绍本方案。下面结合图2，描述第一种登录方式中，根据本公开实施例的终端基于验证码请求登录应用程序时终端的操作的流程。
33.首先，在步骤s201中，由终端的用户的第一用户帐号在终端上发起基于验证码登录终端上的应用程序的请求。获取应用程序登录所需的验证码可以采用各种适用的方式，在一些实施例中，第一用户帐号是运营商(或者区别于应用程序服务器的另一个服务器)为终端的用户分配的帐号，例如用户的第一用户帐号可以为手机号。在一些实施例中，当第一用户帐号为手机号，或者该第一用户帐号与用户所持有的手机号相关联时，可以通过从运营商处获取短信验证码的方式来得到登录终端上的应用程序所需的验证码。但该验证码并不限于短信验证码，例如也可以是运营商通过电话获取的验证码。在另一些实施例中，获取
验证码的手段也不一定是短信或电话，还可以是通过互联网等其他的手段，例如在网页上呈现等，在此不一一列举。在一些实施例中，由终端的用户或终端自动地将所获取的验证码发送到服务器，由服务器对验证码进行验证。
34.在步骤s202中，在验证码验证成功的情况下，从服务器获取第一用户标识。第一用户标识为服务器为终端的用户分配的标识，可以在一定范围内唯一标识某个用户。
35.在一些实施例中，在验证码验证成功的情况下，还将从服务器获取与第一用户标识关联的第一令牌。第一令牌为服务器在本次基于验证码登录的过程中针对该第一用户标识或者该第一用户账号分配的临时令牌。在基于终端的应用程序基于验证码请求登录的阶段，终端可以利用第一令牌来合法地与服务器交互信息，例如s205步骤的公钥、第一识别码等。
36.在步骤s203中，生成与所述第一用户标识以及终端相关联的第一识别码，以及与第一用户标识相关联的非对称密钥对。在一些实施例中，第一识别码可以基于第一用户标识以及该终端的硬件和/或软件参数来生成。在一些实施例中，还可以基于时间戳信息生成与第一用户标识和终端相关联的第一识别码。示例性地，例如结合第一用户标识、终端的硬件参数和终端当前的时间等信息来生成第一识别码。如此，可以保证对于每一次在终端基于验证码登录应用程序的请求，终端所生成的第一识别码都是唯一的，即使是在同一终端上卸载又重装了应用程序，或者用不同的用户帐号在同一终端登录，或者同一用户账号在不同的终端上登录，其所生成的第一识别码理论上应该都是不同的，终端或服务器不应该会存在与本次相同的第一识别码，如此，可以通过对第一识别码的唯一性的判别，来体现系统安全性的状态。更近一步地，即使第一识别码被意外泄露或被非法窃取，由于其是唯一的，例如带有时间戳信息，也不易被非法使用。
37.在步骤s204中，将所生成的非对称密钥对存储于终端的安全芯片内，所述非对称密钥对中的私钥不可被导出至所述安全芯片外部，所有与私钥有关的操作只能在安全芯片内进行。示例性地，安全芯片还可以是安全容器，例如keystore、keychain等。
38.如此，可以保证即使在硬件丢失或其他信息泄露的情况下，私钥也不被非法复制和非法使用。在一些实施例中，上述非对称密钥对可以是rsa非对称密钥，可替换地，也可使用ecc非对称密钥算法等任何适用的非对称密钥算法来替换rsa非对称密钥算法。相对于对称密钥算法，非对称密钥在终端本地生成，并且密钥尤其是私钥不在信道中传输，具有较好的安全性。同时，也避免了对称密钥一方泄露则无法保证整个系统安全性的问题。
39.在步骤s205中，向服务器发送非对称密钥对中的公钥和第一识别码。在一些实施例中，除上述公钥和第一识别码外，还可以向服务器发送待验证令牌，该令牌即为在步骤s202中获取的由服务器发送的第一令牌。
40.在步骤s206中，从服务器接收与第一用户标识相关联的第二令牌。
41.可选地，可以在服务器利用存储在服务器上的第一令牌验证待验证令牌通过的情况下，从服务器接收与第一用户标识相关联的第二令牌。在另一些实施例中，由于服务器的设备密钥表中存储有基于验证码成功登陆过应用程序的用户帐号所对应的识别码，因此，在服务器的设备密钥表中不存在与第一识别码匹配的识别码的情况下，从服务器接收与第一用户标识相关联的第二令牌。第二令牌可以作为合法使用应用程序的通行证，例如，用于应用程序客户端后续调用和帐户相关的业务接口等。反之，若经查验在服务器的设备密钥
表中已经存在与第一识别码匹配的识别码，则存在该数据为通过非法途径获取已有数据的风险，服务器将不为终端颁发第二令牌，具体原因将在下文中详述。
42.在步骤s207中，将第一用户帐号、第一用户标识、第一识别码和第二令牌关联存储作为应用程序的登录信息；
43.至此，根据本公开实施例的终端的用户的第一用户帐号完成了在该终端基于验证码成功登录的过程，当该第一用户帐号在同一终端上再次请求登录该应用程序时，将不必再使用验证码登录，而是可以基于上述已经存储于终端中的登录信息向服务器请求一键登录。
44.图3示出根据本公开实施例的在终端基于验证码请求登录应用程序时服务器的操作的流程图。上文所述两种登录方式的任何一种，都需要终端和服务器协同完成各种验证和操作。下面结合图3，描述在上述第一种登录方式中，根据本公开实施例的终端基于验证码请求登录应用程序时服务器的操作的流程。
45.在一些实施例中，在终端的用户利用其所持有的第一用户帐号在终端基于验证码请求登录应用程序时，将向服务器发送其从例如运营商服务器处接收到的验证码。在步骤s301中，服务器接收终端的用户的第一用户帐号在终端基于验证码请求登录应用程序时发送的验证码，并在步骤s302中，由服务器对验证码进行验证，当验证码验证失败，服务器将在步骤s303中，向终端发送提示登录失败的信息。
46.若在步骤s303中，验证码验证成功，则在步骤s304中，由服务器向终端发送与终端以及第一用户帐号相关联的第一用户标识。在一些实施例中，在验证码验证成功的情况下，还可以向终端发送与第一用户标识关联的第一令牌。
47.在步骤s305中，接收来自终端的非对称密钥对中的公钥和第一识别码，其中，非对称密钥对由终端与第一用户标识相关联地生成，第一识别码由终端与第一用户标识以及终端相关联地生成。在另外一些实施例中，除接收来自终端的非对称密钥对中的公钥和第一识别码外，当在步骤s303中向终端发送了第一令牌时，还可以接收来自终端的待验证令牌。
48.在步骤s306中，向终端发送与第一用户标识关联的第二令牌。具体地，在一些实施例中，可以在利用存储在服务器上的第一令牌验证待验证令牌通过的情况下，向终端发送与第一用户标识关联的第二令牌。特别地，当经查验在服务器的设备密钥表中不存在与第一识别码匹配的识别码的情况下，向终端发送与第一用户标识关联的第二令牌，否则认为存在已有信息被非法盗用的可能，不予颁发证明终端合法性的第二令牌。上述判定准则的原因是：第一识别码为终端与来自服务器的第一用户标识以及该特定终端相关联地生成。在一些实施例中，第一识别码还可能是基于时间戳信息生成的，并且，对于终端每次基于验证码登录应用程序的请求，服务器所生成的第一用户标识也不相同，因此，每次基于验证码登录时，终端所生成的第一识别码也应是唯一的，当出现与历史信息相同的第一用户标识符时，可以怀疑例如在终端发生了信息泄露，因此不应为终端颁发作为登录应用程序并合法操作应用程序许可的第二令牌。通过上述的安全验证措施，不仅能够避免传统的帐号密码登录方式中，由于密码的后台泄露或被暴力猜测而导致的安全性问题，服务器还可以及时识别由于其他原因的信息泄露而导致的安全隐患，进而避免用户损失，提升用户信任度。
49.在步骤s307中，将第一用户帐号、第一用户标识、第一识别码以及公钥关联存储于设备密钥表中。
50.至此，在服务器与终端的协同操作下，根据本公开实施例的终端的用户的第一用户帐号完成了在该终端基于验证码成功登录的过程。在一些实施例中，应用程序服务器的设备密钥表中的信息可以与使用该应用程序的各个用户帐号在各个终端成功登录的历史相对应，例如其所存储的每一条记录，都代表特定的第一用户帐号在特定的终端成功登录的信息，记录中对应的公钥信息等，将在后续的一键登录过程中用于用户身份和安全性的验证。
51.图4示出根据本公开实施例的在终端请求一键登录应用程序时终端的操作的流程图。当通过执行图2和图3中的各个步骤，根据本公开实施例的终端的用户的第一用户帐号在该终端完成了基于验证码成功登录的过程，在一些实施例中，当在同一终端，该应用程序被再次启动时(可以由用户人工启动，也可以由其他应用程序等调用，在此不做限制)，将不再重复基于验证码登录的过程，而是执行上述第二种方式的登录，即，一键登录的过程。
52.在步骤s401中，终端首先获取最近一次在终端上成功登录应用程序时存储的登录信息中的第一用户帐号和第一识别码。
53.在步骤s402中，向服务器发送一键登录请求，一键登录请求包含最近一次在终端上成功登录应用程序时存储的登录信息中的第一用户帐号和第一识别码。
54.在步骤s403中，在服务器的设备密钥表中存在与第一用户帐号和第一识别码匹配的用户帐号和识别码的情况下，从服务器获取第一校验信息。在一些实施例中，第一校验信息可以包含加密随机信息。
55.在步骤s404中，利用存储于终端的安全芯片内的、与第一用户标识相关联的非对称密钥对中的私钥，处理第一校验信息，得到第二校验信息。
56.在一些实施例中，在生成第二校验信息时，可以采用第一类方法，即：利用存储于终端的安全芯片内的、与第一用户标识相关联的非对称密钥对中的私钥，对加密随机信息解密，得到明文随机信息，将该明文随机信息包含在第二校验信息中。
57.在另一些实施例中，在生成第二校验信息时，可以采用第二类方法，即：可以利用存储于终端的安全芯片内的、与第一用户标识相关联的非对称密钥对中的私钥，对随机信息签名，得到签名信息，将该签名信息包含在第二校验信息内。
58.在其他实施例中，第二校验信息还可以包含以其他方式生成的信息，在此不做具体限制。但须知，不同的第二校验信息生成方式对应与不同的由服务器实施的第一校验信息的生成方法，以及相应的验证方法，具体将在下文中描述。
59.在步骤s405中，在第二校验信息通过服务器的验证的情况下，从服务器接收与第一用户标识相关联的第三令牌。
60.在步骤s406中，将登录信息更新为第一用户帐号、第一用户标识、第一识别码和第三令牌。第三令牌的作用与前述第二令牌类似，都是应用程序客户端基于同一次登录的所有操作的合法性证明的统一的通行证，例如，用于应用程序客户端调用和帐户相关的业务接口等。在一些实施例中，通过每一次一键登录由新的第三令牌替换原有的令牌的操作，可以保证只有持有合法的第三令牌的应用程序客户端可以对应用程序进行合法操作，而例如过时的会话由于其所持有的令牌不是由服务器颁发的最新令牌，因此无法进行合法的操作，如此，进一步保证了用户合法身份的认证，提高了系统的安全性。
61.图5示出根据本公开实施例的在终端请求一键登录应用程序时服务器的操作的流
程图。与图4所示的根据本公开实施例的在终端请求一键登录应用程序时终端的操作相协同地，服务器在这一登录方式中执行如图5所示的步骤，以实现基于设备密钥表确定是否允许第一用户帐号登录应用程序的处理。
62.在步骤s501中，接收来自终端的一键登录请求，该一键登录请求包含最近一次在终端上成功登录应用程序时存储的登录信息中的第一用户帐号和第一识别码。
63.在步骤s502中，判定服务器的设备密钥表中是否存有与第一用户帐号和第一识别码匹配的用户帐号和识别码，若两个中的至少一个不匹配，则在步骤s503中，向终端发送提示登录失败的信息。
64.当在步骤s502中判定的结果为“是”，即，在服务器的设备密钥表中存有与第一用户帐号和第一识别码匹配的用户帐号和识别码的情况下，则服务器将在步骤s504中，向终端发送第一校验信息，其中，第一校验信息为服务器利用设备密钥表中与第一用户帐号和第一识别码关联的公钥处理得到。在一些实施例中，与上文所述生成第二校验信息的方法相对应，生成第一校验信息具体也至少可以按如下两类方式，对应的第一类的步骤为：首先获取设备密码表中与第一用户帐号关联的公钥，并生成诸如数字或字符串等随机信息，然后利用公钥对随机信息加密，生成加密随机信息，作为第一校验信息，并向终端发送。在另一些实施例中，可以采用第二类方法生成第一校验信息：首先生成诸如数字或字符串等随机信息，然后向终端发送作为第一校验信息的所生成的随机信息。可选地，服务器也可以将随机信息采用非对称密钥对中的公钥，或者其他事先协商好的通信密钥加密。
65.接下来，在步骤s505中，服务器接收来自终端的第二校验信息。在步骤s506中，服务器对第二校验信息进行验证。在一些实施例中，服务器可以利用公钥或基于公钥生成的其他信息，对第二校验信息进行验证。在一些实施例中，对应于第一类方法所生成的第二校验信息，可以采用第一类验证方法，即：在第二校验信息中的明文随机信息与服务器中存储的随机信息一致的情况下，确定第二校验信息通过服务器的验证。在另一些实施例中，对应于采用第二类方法所生成的第二校验信息，可以采用第二类验证方法，具体包括：首先获取设备密码表中与第一用户帐号关联的公钥，然后利用随机信息和公钥，验证第二校验信息中包含的签名信息，在签名信息通过验证的情况下，确定第二校验信息通过服务器的验证。可选地，当终端接收到的随机信息为采用非对称密钥对中的公钥，或者其他事先协商好的通信密钥加密的信息时，终端可以采用非对称密钥对中的私钥，或者其他事先协商好的通信密钥相应地解密，然后再采用非对称密钥对中的私钥对解密得到的随机信息签名，以得到签名信息。
66.若步骤s506中判定的结果为“否”，即，验证不通过，则在步骤s507中，向终端发送提示登录失败的信息。
67.当在步骤s506中判定的结果为“是”，即，在第二校验信息通过服务器的验证的情况下，在步骤s508中，可以由服务器向终端发送与第一用户标识相关联的第三令牌，以允许第一用户帐号在终端上登录应用程序。
68.结合图4和图5所描述的流程可以得知，当已经成功基于验证码登录终端应用程序的第一用户帐号在同一终端上再次请求登录该应用程序时，将不必再使用验证码登录，而是可以基于上述已经存储于终端中的登录信息向服务器请求一键登录，而服务器接收到上述第一用户帐号在同一终端上对应用程序进行一键登录的请求时，将不必与运营商服务器
发生任何交互，仅基于服务器中的设备密钥表即可确定是否允许该第一用户帐号登录该终端的应用程序，如此，不仅简化了用户及整个系统的操作流程，进而缩短了登录时间，大大提升了用户使用应用程序的体验，减少因此流失客户的可能性。
69.本公开的发明人还发现，图2
‑
图5所描述的根据本公开实施例的用户在终端基于验证码请求登录应用程序和基于验证码登录应用程序成功后的一键登录的过程，与传统的一键登录方案相比，还具有缩短应用程序开发时间和开发成本，以及降低应用程序运营成本的有益效果。具体而言，传统的终端(例如手机终端)应用程序的开发在实现一键登录时，需要通过接入手机运营商提供的sdk包，并需要应用程序开发者分别在运营商(例如移动、联通、电信等手机运营商)申请开发者帐号，分别集成到手机端应用内，开发者的开发难度和开发、测试的工作量，以及产品上市时间都会受影响，并且，在使用过程中，运营商还会向提供应用程序服务的平台收取服务费用和流量费用，更增加了应用程序的运营成本。而根据本公开的实施例中，仅在用户首次在终端基于验证码请求登录应用程序时，由应用程序的服务器向运营商服务器请求发送验证码，而终端只从运营商处接收验证码，无需其他交互，因此，应用程序开发者不必在终端集成开发者帐号，如此，可以大大降低开发难度，缩短开发时间，降低开发成本。并且，在后续的一键登录过程中，仅利用在首次基于验证码登录应用程序过程中，存储于终端和应用程序服务器端的相对应的用户的登录信息，即可便捷地实现一键登录，而不必再依赖运营商的参与，因此，可以大大减少应用程序运营的费用。与此同时，本公开的实施例还可以有效避免由于运营商服务质量不佳而导致的用户流失，例如在传统的依赖验证码的一键登录过程中，由于运营商网络信号不好或流量压力过大而导致获取验证码困难，进而用户等待时间变长，体验下降，流失的可能性增大。由于在根据本公开实施例的一键登录过程中，只在服务器和终端之间进行交互和验证，而不受运营商网络及服务的影响，因而有效避免了上述不利因素对用户使用应用程序的影响。
70.图6示出根据本公开实施例的用户在终端首次基于验证码登录应用程序的示例的时序图。下面将结合图6，描述用户22在其持有的诸如手机、pad、笔记本电脑等类型的终端(未示出)上，首次登录应用程序客户端11a时，用户22、应用程序客户端11a、应用程序服务端21、运营商服务器30各自的操作以及彼此之间交互的信息。在一些实施例中，首次可以是指用某一用户帐号首次登录应用程序，在另一些实施例中，首次也可以是指终端上的应用程序卸载并重装之后，曾经登录过的用户帐号的首次登录。在本实施例中，由于是首次登录，因此，当用户22打开终端(未示出)上的应用程序客户端11a时，将提示需要基于验证码登录。在一些实施例中，验证码可以采用任何适用的形式，在本示例中，以利用手机号获取含有验证码的短信为例进行说明。
71.在步骤s601中，用户22在应用程序客户端11a的界面中输入作为第一用户帐号的手机号，并在步骤s602中例如通过点击获取验证码的按钮，告知应用程序客户端11a其希望获取验证码。那么，其所输入的手机号将在后续的流程中作为应用程序客户端11a获取验证码的手段。
72.在步骤s603中，应用程序客户端11a获取用户22输入的手机号，并在步骤s604中，将获取的手机号作为参数，调用应用程序服务端21的获取验证码的接口，请求为该手机号生成验证码。
73.在步骤s605中，应用程序服务端21为从应用程序客户端11a获取的手机号生成验
证码，并将该验证码存入缓存中。在一些实施例中，缓存例如可以是redis缓存。在其他一些实施例中，也可以使用其它的缓存框架，例如ehcache等，只要是能够支持key、value的轻量级缓存即可，在此不做限制。接下来，在步骤s605中，应用程序服务端21将手机号和所生成的验证码作为参数，调用运营商服务器的发送短信验证码接口，请求将该验证码发送到该手机号。
74.运营商服务器30收到请求后，分别在步骤s607中将该验证码通过运营商网络例如以短信的方式推送到用户22所持有的手机号上；在步骤s608中，向应用程序服务端21返回验证码发送成功的信息。在收到上述来自运营商服务器30的验证码发送成功的信息后，在步骤s609中，应用程序服务端21也将向应用程序客户端11a返回验证码发送成功的信息。
75.应用程序客户端11a收到来自应用程序服务端21的验证码发送成功的反馈后，将在步骤s610中向用户22提示“短信验证码发送成功”。
76.在步骤s611中，用户22可以在应用程序客户端11a的界面中，输入其手机号所收到的验证码短信中的验证码，并在步骤s612中通过例如点击登录按钮来请求登录。
77.在步骤s613中，应用程序客户端11a获取了用户输入的验证码之后，在步骤s614中，携带手机号和验证码参数，调用应用程序服务端21的短信验证码登录接口，将手机号和对应的验证码发送到应用程序服务端21。
78.在步骤s615中，应用程序服务端21从缓存获取验证码，并与应用程序客户端11a提交的短信验证码进行比对，在比对结果不一致的情况下，判定为验证码验证失败，流程进入步骤s616，向应用程序客户端11a返回验证错误信息，在步骤s617中，应用程序客户端11a提示用户22，验证失败，并在s618中，提示用户22失败的登录结果。在一些实施例中，在提示用户22登录失败时，例如可以在规定的失败次数内，提示用户本次登录失败，是否再次尝试验证码登录，或者也可以采用任何适用的提示方式，取决于应用程序的设计，在此不做限制。用户22在接收到登录结果提示信息后，在步骤s619中结束本次基于验证码的登录，例如下一步可以成功进入应用程序的首页。
79.当在步骤s615中，验证码比对结果一致，则判定为验证码验证成功，在接下来的步骤s620至步骤s630中执行的一系列的操作和信息交换，使用户22后续在同一终端登录该应用程序时，能够不必进行验证码登录，而是可以使用更便捷的一键登录方式。
80.在步骤s620中，应用程序服务端21与用户22本次登录所使用的终端(未示出)及作为第一用户帐号的手机号相关联地生成第一用户标识，以及与第一用户标识关联的第一令牌，并在步骤s621中，与包含验证码验证成功的状态码一起，将上述所生成的第一用户标识和第一令牌发送到应用程序客户端11a。
81.在步骤s622中，应用程序客户端11a创建与终端及第一用户标识相关联的第一识别码，并创建与第一用户标识相关联的rsa非对称密钥对，并将其存储到终端中的安全芯片。在一些实施例中，非对称密钥对的公钥可以读出，而私钥不可被导出至所述安全芯片外部，以保证登录信息的安全。
82.在步骤s623中，应用程序客户端11a获取存储于安全芯片中的非对称密钥对中的公钥，并在步骤s624中，将公钥、第一识别码、第一令牌作为参数，调用应用程序服务端21的保存设备密钥接口，以便应用程序服务端21能够对上述信息进行验证。
83.在步骤s625中，应用程序服务端21将利用接收到的公钥信息，对第一令牌和第一
识别码的正确性和第一识别码的唯一性进行验证。当未能通过验证时，可以处理转到前面已经描述的步骤s616至步骤s619中的部分或全部步骤，结束本次登录。
84.在步骤s625中验证通过的情况下，应用程序服务端21将在步骤s626中，将手机号、第一用户标识、第一识别码及公钥关联地存储于设备密钥表中，以便于后续一键登录时用于相关信息的验证。在步骤s626中，应用程序服务端21还将生成第二令牌，并在步骤s627中，向应用程序客户端11a发送带有第二令牌的登录结果。
85.在步骤s628中，应用程序客户端11a将其收到的作为第一用户帐号的手机号、第一用户标识、第一识别码和第二令牌四元组，作为最后一次成功登录的登录信息进行保存，并在步骤s629中提示用户22成功完成基于验证码的登录。
86.在步骤s630中，用户22在接收到登录结果提示信息后，结束本次基于验证码的登录，例如下一步可以成功进入应用程序的首页。在一些实施例中，在成功登录应用程序后，用户22还需要在应用程序客户端11a执行其他的操作，在这种情况下，第二令牌将作为基于同一次登录的所有操作的合法性证明的统一的通行证，例如，用于应用程序客户端调用和帐户相关的业务接口等。
87.图7示出根据本公开实施例的用户在终端一键登录应用程序的示例的时序图。下面将结合图7，描述用户22在其持有的诸如手机、pad、笔记本电脑等类型的终端(未示出)上登录时，当在本次登录之前，已经基于验证码登录成功的情况下，一键登录应用程序时，用户22、应用程序客户端11a、应用程序服务端21各自的操作以及彼此之间交互的信息。请注意，与图6中示出的基于验证码登录应用程序不同，在本示例中，无需运营商服务器30参与，即可完成应用程序的登录。
88.在步骤s701中，用户22点击应用程序图标，并在步骤s702中进入应用程序客户端11a的登录页面。
89.接下来，应用程序客户端11a在步骤s703中获取最后一次成功登录的登录信息，包括手机号、第一用户标识、第一识别码和第二令牌，并在步骤s704中刷新登录页面，将手机号填充到界面中，并显示一键登录按钮。具体可以结合图8所示的终端的应用程序客户端的示意性界面，例如可以将手机号自动填充到帐号栏11a1中，并显示一键登录按钮11a2。在其他一些实施例中，在图8的应用程序客户端11a的界面中，还可以包括其他一些功能区，例如功能区11a3，其中的按钮1、按钮2和按钮3例如可以为用户提供诸如切换帐号、新注册、退出应用程序等其他所需的功能，在此不赘述。须知，在另外一些实施例中，也可以不出现如图8所示的需要用户手动点击“一键登录”按钮的界面，可替代地，当用户启动应用程序客户端11a时，也可以在一键登录验证通过的情况下，直接进入应用程序的进一步的功能界面。
90.当用户22在步骤s706中点击一键登录按钮时，将在步骤s707中向应用程序客户端11a请求一键登录到该应用程序，应用程序客户端11a将在步骤s708中调用应用程序服务端21的获取登录随机码接口，并将之前获取的最后一次成功登录的登录信息中的手机号和第一用户识别码，作为接口参数，传递给应用程序服务端21。
91.在步骤s709至步骤s711中，应用程序服务端21将利用在图6的各个步骤中获取的诸如设备密钥表中的公钥信息等，对从应用程序客户端11a获取的手机号和第一识别码进行查询和处理，以生成用于进一步验证的信息。具体地，在步骤s709中，应用程序服务端21首先根据作为用户帐号的手机号，在设备密钥表中查询是否存在与该手机号和该第一识别
码完全匹配的数据记录，若不存在，则向应用程序客户端11a提示一键登录错误信息(未示出)，进而由应用程序客户端11a向用户22提示一键登录失败的信息(未示出)。
92.若在步骤s709中判定存在完全匹配的数据记录，则进一步查询该条记录中对应的公钥信息，并且在步骤s710中，生成随机信息并存入缓存。在步骤s711中，利用从设备密钥表中获取的公钥，对该随机信息进行加密处理，以得到加密随机信息。进一步，在步骤s712中，向应用程序客户端11a返回包含加密随机信息的随机码。
93.在步骤s713中，应用程序客户端11a获取到应用程序服务端21返回的包含加密随机信息的随机码之后，例如可以通过调用终端提供的私钥解密接口，并将对应的与第一用户标识和加密随机信息提供给接口，以解密加密随机信息，得到解密后的随机信息明文。随后，在步骤s714中调用随机码登录接口，并将解密后的随机信息发送到应用程序服务端21。
94.在步骤715中，应用程序服务端21从缓存获取随机信息，并与从应用程序客户端11a获取的解密后的随机信息对比，在对比结果不一致的情况下，向应用程序客户端11a提示一键登录错误信息(未示出)，进而由应用程序客户端11a向用户22提示一键登录失败的信息(未示出)；在对比结果一致的情况下，携带其生成的第三令牌，向应用程序客户端11a返回一键登录结果。
95.在步骤s717中，更新登录信息，将登录信息中的第二令牌更新为第三令牌。在步骤s718中，应用程序客户端11a向用户22提示登录结果，在步骤s719中，结束本次一键登录过程，例如下一步可以成功进入应用程序的首页。在一些实施例中，在成功一键登录应用程序后，用户22还需要在应用程序客户端11a执行其他的操作，在这种情况下，第三令牌将作为基于同一次登录的所有操作的合法性证明的统一的通行证，例如，用于应用程序客户端调用和帐户相关的业务接口等。
96.本公开的实施例还提供一种终端，该终端包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的程序，所述程序被所述处理器运行时，执行前述各个实施例的终端应用程序的一键登录的方法应用于终端的步骤。
97.本公开的实施例还提供一种服务器，该服务器包括存储器、处理器和被存储在所述存储器中并被配置为由所述处理器执行的程序，所述程序被所述处理器运行时，执行前述各个实施例的终端应用程序的一键登录的方法应用于服务器的步骤。
98.此外，尽管已经在本文中描述了示例性实施例，其范围包括任何和所有基于本公开的具有等同元件、修改、省略、组合(例如，各种实施例交叉的方案)、改编或改变的实施例。权利要求书中的元件将被基于权利要求中采用的语言宽泛地解释，并不限于在本说明书中或本技术的实施期间所描述的示例，其示例将被解释为非排他性的。因此，本说明书和示例旨在仅被认为是示例，真正的范围和精神由以下权利要求以及其等同物的全部范围所指示。
99.以上描述旨在是说明性的而不是限制性的。例如，上述示例(或其一个或更多方案)可以彼此组合使用。例如本领域普通技术人员在阅读上述描述时可以使用其它实施例。另外，在上述具体实施方式中，各种特征可以被分组在一起以简单化本公开。这不应解释为一种不要求保护的公开的特征对于任一权利要求是必要的意图。相反，本发明的主题可以少于特定的公开的实施例的全部特征。从而，以下权利要求书作为示例或实施例在此并入具体实施方式中，其中每个权利要求独立地作为单独的实施例，并且考虑这些实施例可以
以各种组合或排列彼此组合。本发明的范围应参照所附权利要求以及这些权利要求赋权的等同形式的全部范围来确定。