一种信任登录方法和装置与流程

本申请涉及网络技术，特别涉及一种信任登录方法和装置。

背景技术：

信任登录也可以称为发生在两个应用之间的免登录，例如，用户在购物网站登录购物，当需要付款时跳转到支付网站，此时无需再输入支付网站的登录信息就可以直接支付，这就是从购物网站到支付网站的信任登录，即支付网站对于已经在购物网站登录的用户是信任的，因此用户不用在支付网站再次登录就可以直接在支付网站操作。

相关技术中，两个应用之间信任登录的方式可以是，当用户在应用A登录后，在应用A进行数字签名，并将签名添加到应用B的网站链接地址，作为链接地址的其中一个参数，该携带签名的地址可以称为信任登录网址。当用户点击信任登录网址访问应用B时，应用B校验该签名后获知已在应用A登录，则设置用户也在应用B登录。这种方式下，如果将信任登录网址随意复制，例如将其复制到另一个终端，则仍然能够访问应用B，存在安全隐患。

技术实现要素：

有鉴于此，本申请提供一种信任登录方法和装置，以提高信任登录的安全性。

具体地，本申请是通过如下技术方案实现的：

第一方面，提供一种信任登录方法，包括：

在建立用户在第一应用的第一登录态后，获取用户登录设备的设备标识 信息，关联所述设备标识信息与所述第一登录态；

将所述设备标识信息与第一登录态，发送至第二应用的服务器，所述第二应用是与所述第一应用信任登录的关联应用，以使得所述服务器根据所述第一登录态建立所述用户在所述第二应用的第二登录态，并关联所述设备标识信息与所述第二登录态。

第二方面，提供一种信任登录方法，包括：

接收第一应用的服务器发送的第一登录态和设备标识信息，所述第一应用是与第二应用信任登录的关联应用，所述第一登录态表示用户在所述第一应用登录，所述设备标识信息用于表示用户登录第一应用的登录设备；

根据所述第一登录态，建立所述用户在所述第二应用的第二登录态，关联并存储所述设备标识信息与第二登录态；

在接收到对于所述第二应用的应用访问请求时，若确定发送所述应用访问请求的设备标识信息及对应的第二登录态已经存储，返回应用访问响应。

第三方面，提供一种信任登录装置，包括：

登录态生成模块，用于在建立用户在第一应用的第一登录态后，获取用户登录设备的设备标识信息，关联所述设备标识信息与所述第一登录态；

登录态同步模块，用于将所述设备标识信息与第一登录态，发送至第二应用的服务器，所述第二应用是与所述第一应用信任登录的关联应用，以使得所述服务器根据所述第一登录态建立所述用户在所述第二应用的第二登录态，并关联所述设备标识信息与所述第二登录态。

第四方面，提供一种信任登录装置，包括：

登录态接收模块，用于接收第一应用的服务器发送的第一登录态和设备标识信息，所述第一应用是与第二应用信任登录的关联应用，所述第一登录态表示用户在所述第一应用登录，所述设备标识信息用于表示用户登录第一应用的登录设备；

登录态建立模块，用于根据所述第一登录态，建立所述用户在所述第二应用的第二登录态，关联并存储所述设备标识信息与第二登录态；

访问管理模块，用于在接收到对于所述第二应用的应用访问请求时，若确定发送所述应用访问请求的设备标识信息及对应的第二登录态已经存储，返回应用访问响应。

本申请提供的信任登录方法和装置，通过由具有信任登录的关联关系的第一应用和第二应用的服务器之间进行登录态的传输，使得服务器可以根据该登录态获知用户已经在关联应用登录，从而在关联应用之间建立信任登录，这种方式由于是依靠服务器之间相互通知获得信任登录的执行，相对于传统方式中的客户端之间传输登录信息的方式，将更可以提高信任登录的安全性。

附图说明

图1是本申请一示例性实施例示出的一种信任登录方法的流程图；

图2是本申请一示例性实施例示出的另一种信任登录方法的流程图；

图3是本申请一示例性实施例示出的一种信任登录装置的结构图；

图4是本申请一示例性实施例示出的另一种信任登录装置的结构图；

图5是本申请一示例性实施例示出的又一种信任登录装置的结构图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

信任登录是一种可以方便用户在不同应用之间无缝切换的免登录方式，例如，用户在登录了应用A之后，也就同时拥有了应用B的访问权限，应用B信任已经在应用A登录的用户。通常，可以信任登录的应用A和应用B的用户是同一用户(例如，用户使用同一账户分别在应用A和应用B注册)，或者两个应用的用户存在绑定关系(例如，用户分别在这两个应用注册的账 户不同，但是具有绑定关系)。实际应用中，比如，在购物网站付款时跳转到支付网站的方式，就是一种信任登录的实现方式。

本申请实施例的信任登录方法和装置，用于在两个应用之间实现信任登录，并且，该方法将实现更加安全的信任登录。以购物应用和支付应用，两个应用之间的信任登录为例，其中，购物应用可以称为第一应用，支付应用可以称为第二应用。应用采用客户端/浏览器(Browser/Server)模式，用户可以在终端(例如，电脑、智能手机等)上通过浏览器打开购物网站的网址，访问该购物应用，终端上访问的购物网站是该购物应用的客户端，应用内容是由后端的购物应用服务器传输至客户端解析显示。

参见图1的示例，在101中，用户在终端上输入账号和密码登录购物应用，在102中，购物应用的服务器对账号、密码等登录信息进行验证，本实施例假设通过验证。则在103中，服务器建立第一登录态，该第一登录态表示“上述账号和密码对应的用户，在终端上登录购物应用，并且登录成功”，登录态是记录的上述登录信息，例如可以包括：用户信息(账号)、登录时长、登录设备的环境(例如，浏览器版本、终端型号、终端的IP地址、MAC地址、手机的SIM卡号)等。也就是说，当用户登录应用成功后，该应用的服务器将会记录关于该应用登录的一些信息，这些信息就是登录态。

本申请实施例的信任登录方法中，描述登录态在图1所示的购物应用服务器与支付应用服务器之间的传输；其中，以用户从购物应用的网站链接跳转到支付应用为例，在这一由购物应用到支付应用的信任登录过程中，购物应用与支付应用是相互关联的(能够进行信任登录的关联)，购物应用可以称为支付应用的关联应用，支付应用也同样可以称为购物应用的关联应用。

继续参见图1所示，购物应用服务器在103中为用户建立的登录态，可以称为第一登录态(该“第一”只是用于与后面的其他登录态相区别)。在104中，购物应用服务器可以获取用户登录设备的设备标识信息，并建立该设备标识信息与第一登录态的关联关系。其中，所述的设备标识信息，可以用于唯一标识用户登录购物应用的终端设备，例如，该设备标识信息可以是 购物应用服务器直接获取的可以标识设备的信息；或者，该设备标识信息也可以是购物应用服务器根据一些信息计算得到的。比如图1中的104示例的，可以通过终端的IP、MAC、进程ID(访问应用的进程)等信息计算出一个终端设备的ID作为设备标识信息，比如可以使用MD5算法对上述信息计算得到摘要信息。如果是不同的终端设备，那么通常上述的IP、MAC信息是不同的，因此计算得到的设备标识信息也不相同，从而使得设备标识信息唯一标识登录设备。

在105中，购物应用服务器可以将设备标识信息与第一登录态都发送至支付应用服务器。例如，购物应用服务器可以在用户在购物应用中要跳转至支付应用时，将上述的设备标识信息和第一登录态发送至支付应用服务器。由于本申请实施例要执行的是信任登录过程，用户登录了购物应用，就可以免登录的直接在支付应用访问，因此，购物应用服务器可以在建立用户的第一登录态后，就通知支付应用服务器，使得支付应用服务器获知用户已经在购物应用登录，并据此建立用户在支付应用服务器的登录态，即相当于确定了用户已经可以在支付应用登录，尽管此时用户实际上尚未登录支付应用，但是支付应用已经确定了该用户可以在支付应用登录。

需要说明的是，在105中的同步登录态的过程中，购物应用主要是通知支付应用用户已经在购物应用登录，购物应用服务器向支付应用服务器传输的信息只要能够达到上述目的即可，具体传输的信息内容可以灵活设定。例如，同步的第一登录态信息包括：登录状态为true，该true用于表示“已经登录”；又例如，还可以进一步包括手机型号、浏览器类型等终端信息。即购物应用服务器向支付应用服务器传输的第一登录态包括的信息，可以不完全与购物应用服务器记录的第一登录态信息相同，至少应通知支付应用服务器“已经登录”的状态，使得支付应用服务器获知用户已经在购物应用登录。

此外，由于支付应用是从购物应用中跳转，因此购物应用能够知道与其产生信任登录关联的支付应用的服务器地址，并向该地址同步第一登录态。

在106中，支付应用服务器可以根据第一登录态，建立用户在本端的支 付应用(即第二应用)的第二登录态，即记录用户在支付应用服务器已经登录的信息，比如上述的用户账号、手机型号、浏览器类型等信息；并且建立该第二登录态与设备标识信息的对应关系，以及存储该对应关系。

在107中，由于用户可以从购物应用跳转到支付应用，因此，购物应用服务器可以向终端返回支付应用的链接地址，例如是支付网站的URL；在本申请实施例中，购物应用服务器可以不需要在支付应用的链接地址URL中添加签名。在108中，用户可以点击该链接地址访问支付应用。

支付应用服务器在接收到108中用户发送的应用访问请求后，将计算设备标识信息，计算方法同购物应用服务器的方法，比如根据终端设备的IP地址、MAC地址等计算设备标识信息，并查看计算得到的设备标识信息在支付应用服务器自身是否有存储。假如是同一用户在同一终端由购物应用跳转到支付应用，那么支付应用服务器在108中计算到的设备标识信息，与104中购物应用服务器计算的设备标识信息是相同的，支付应用服务器将能够找到自身存储有该设备标识信息及其对应的第二登录态。

若支付应用服务器存储有上述的应用访问请求对应的第二登录态，则支付应用服务器可以确定该用户已经在其关联应用即购物应用上登录，据此支付应用服务器可以信任该用户，允许该用户的访问，在111中向用户返回应用访问响应，比如将支付应用的内容反馈至用户终端。

假设一种情况，例如，仍然执行复制信任登录网址的方式，用户本来是在终端z1上登录并访问购物应用，后来复制支付应用的信任登录网址(该网址指的是用于从购物应用网站跳转到支付应用的链接地址)到终端z2，想要从终端z2访问支付应用。按照传统方式，支付应用服务器将验证信任登录网址中的签名即可同意用户访问支付应用，而本实施例中，支付应用服务器采取的是本申请中的信任登录方法，即不再通过签名(或者该链接中根本就没有签名)验证，而是计算终端z2对应的设备标识信息。根据上面描述的方法，支付应用服务器中存储的是终端z1的设备标识信息及对应的登录态，并没有存储终端z2对应的设备标识信息及对应的登录态，则据此支付应用服务器可 以拒绝用户从终端z2发起的应用访问请求，防止不同终端之间的登录态的随意传输，提高应用访问的安全性。

由上述的描述可以看到，传统方式中登录态的传递(例如，支付应用获知用户在购物应用的已登录状态)是通过前端传输的，比如用户可以在前端的终端浏览器上点击应用跳转的链接触发这个传输(在链接中加入购物应用的已登录状态签名)，因此导致链接地址容易被随意复制，支付应用服务器侧也无法辨识和控制。而本申请实施例中，将这种前端登录态的传输转为后端同步，即购物应用服务器与支付应用服务器之间的登录态同步，用户在前端是无法看到的，后端的服务器之间执行信任登录的过程，使得信任登录过程不可见，支付应用服务器通过服务器之间的登录态同步来获知用户在购物应用登录，并同时建立对该用户的信任。并且，支付应用服务器还可以根据获得的服务器之间的同步登录态的设备标识信息，来控制和防止不同终端之间的随意复制，提高了信任登录的安全性。

在另一个例子中，信任登录通常会要求同一用户在同一终端以可信任的免登录的方式访问关联应用，据此可以在生成设备标识信息时，根据设备信息和登录信息生成所述设备标识信息。例如，设备信息包括：设备的IP地址、MAC地址、进程ID等，登录信息例如包括：用户的账号、密码等，如果用户采用不同的账号信息进行登录，那么计算出的设备标识信息将不一致，从而通过该设备标识信息可以保证同一终端和同一用户。

在又一个例子中，实际使用中还可能出现的情况是，信任登录关联的两个应用之间，可能出现其中一个应用的有效时间到达，而另一个应用无法感知仍然继续访问。比如，有些应用是存在有效时间控制的，假设购物应用的有效时间是30分钟，超过30分钟用户在该应用的登录态将失效，用户将重新登录该应用；那么当信任登录时，支付应用服务器也需要再重新查询下当前的购物应用侧的登录态是否有效，如果仍然有效且支付应用自身的登录态也有效，支付应用才执行信任登录。

为实现上述目的，图2示例的流程中(相比图1省略了相同的101-104)， 支付应用服务器在建立用户在本端的第二登录态之后，还可以执行201，即建立第一登录态和第二登录态的对应关系。例如，这两个登录态都与上述的设备标识信息对应，只要根据设备标识信息就可以找到对应的第一登录态和第二登录态；又例如，在105中购物应用服务器在同步登录态时，可以随机生成一个登录态ID(不限制生成方式及具体的ID形式)，该登录态ID可以用于标识具有关联关系的第一登录态和第二登录态，即支付应用服务器会将第一登录态和第二登录态都与该登录态ID对应，根据该登录态ID就可以找到对应的第一登录态和第二登录态。

当支付应用服务器接收到应用访问请求并且获取到对应的第二登录态以后，可以根据上述的对应关系记录，查找到与该第二登录态对应的第一登录态，并据此得知该第一登录态是购物应用服务器发送的(接收同步的第一登录态时可以记录源设备的地址)，支付应用服务器可以在202中向购物应用服务器查询第一登录态的有效性。

在购物应用服务器侧，判断第一登录态的有效性的方式可以有多种，例如，服务器可以设置登录态有效性的标识信息，比如，记录状态为true表示正在有效，记录状态为false表示已经失效；服务器可以根据该标识信息查询登录态的有效性。又例如，服务器可以记录有效时间阈值比如30分钟，当支付应用服务器查询登录态状态时，服务器将登录时长与该有效时间阈值比较，如果超过或达到30分钟则可以确定失效。

购物应用服务器可以在203中向支付应用的服务器反馈，第一登录态有效；并且，支付应用服务器可以在204中确定第一登录态和第二登录态均有效后(第二登录态的有效性判断方式同第一登录态)，向终端返回应用访问响应。可以看到，通过在关联应用的登录态之间也建立关联，可以容易跟踪用户的跟踪过程，掌握登录态的失效时间。

图3示例了一种信任登录装置，该装置可以应用于例如购物应用服务器，使得购物应用服务器可以执行上述的信任登录方法。如图3所示，该装置可以包括：登录态生成模块31和登录态同步模块32；其中，

登录态生成模块31，用于在建立用户在第一应用的第一登录态后，获取用户登录设备的设备标识信息，关联所述设备标识信息与所述第一登录态；

登录态同步模块32，用于将所述设备标识信息与第一登录态，发送至第二应用的服务器，所述第二应用是与所述第一应用信任登录的关联应用，以使得所述服务器根据所述第一登录态建立所述用户在第二应用的第二登录态，并关联所述设备标识信息与第二登录态。

进一步的，登录态生成模块31，在获取用户登录设备的设备标识信息时，具体用于：根据设备信息和登录信息生成所述设备标识信息。

参见图4的示例，该装置还可以包括：登录态管理模块33，用于接收所述服务器发送的对于第一登录态的有效性查询请求，并将所述第一登录态的有效性反馈至所述服务器。

图5示例了一种信任登录装置，该装置可以应用于例如支付应用服务器，使得支付应用服务器可以执行上述的信任登录方法。如图5所示，该装置可以包括：登录态接收模块51、登录态建立模块52和访问管理模块53；其中，

登录态接收模块51，用于接收第一应用的服务器发送的第一登录态和设备标识信息，所述第一应用是与第二应用信任登录的关联应用，所述第一登录态表示用户在所述第一应用登录，所述设备标识信息用于表示用户登录第一应用的登录设备；

登录态建立模块52，用于根据所述第一登录态，建立所述用户在第二应用的第二登录态，关联并存储所述设备标识信息与第二登录态；

访问管理模块53，用于在接收到对于所述第二应用的应用访问请求时，若确定发送所述应用访问请求的设备标识信息及对应的第二登录态已经存储，返回应用访问响应。

进一步的，登录态建立模块52，还用于：在建立所述用户在第二应用的第二登录态之后，建立第一登录态和第二登录态的对应关系；

所述访问管理模块53，还用于：在确定发送应用访问请求的设备标识信息及对应的第二登录态已经存储之后，返回应用访问响应之前，向所述服务 器发送第一登录态的有效性查询请求，并确定第一登录态和第二登录态有效。

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