CN102946397B - 用户认证方法及系统 - Google Patents

Abstract

本发明公开了一种用户认证方法及系统。其中用户认证方法包括：当用户登录用户代理并通过所述用户代理访问第三方应用服务器时，将第一用户标识传送给第三方应用服务器；接收第三方应用服务器发出的服务接口地址请求消息，将所述第一用户标识发送给宿主网站服务器；获取用户密钥，将其附加在服务接口地址中，将服务接口地址传送给第三方应用服务器，宿主网站服务器解析服务接口地址，获取用户密钥，然后根据第一用户标识与第二用户标识是否一致来确定是否要向第三方应用服务器提供服务。通过本发明提供的技术方案，用户只需一次登录即可通过访问第三方应用服务器使用宿主网站服务器提供的服务，而且还避免了给其它用户造成损失。

Description

用户认证方法及系统

技术领域

本发明涉及网络安全技术领域，具体涉及一种用户认证方法及系统。

背景技术

cookie是互联网网站为了辨别用户身份而存储在用户使用的本地客户端上的数据。当用户需要某网站提供的服务时，用户登录该网站，网站会在本地客户端上存储一个小文本文件，用于记录用户ID（标识）、密码、网页地址和停留时间等cookie信息，接下来用户在该网站进行类似业务预定、下单、购买或其它消费等各种服务时，网站通过cookie确认用户身份，完成提供服务的流程。cookie识别方案是RFC（RequestForComments，一系列以编号排定的文件）协议中的标准流程。cookie只能在宿主网站使用，第三方网站不能使用其它网站生成的cookie。如果用户通过第三方网站（如网站A）需要使用宿主网站（如网站B）提供的服务，则必须要求用户通过网站A中的链接到达网站B，进行二次登录（第一次登录网站A，第二次登录网站B）。现有技术还提供了一种oauth协议，该协议为用户资源的授权提供了一个安全、开放而又简易的标准。根据oauth协议的规定，第三方网站（如网站A）为了使用宿主网站（如网站B）的一些需要用户身份的接口或服务，需要引导用户到达网站B，在网站B完成登录和授权等相应流程，网站B会颁发一个在一定时间内（称为有效期）唯一标识该用户的标记（Token）给网站A，网站A可以使用这个Token在有效期内多次获取用户的信息，继而提供相应的服务。oauth协议为了取得宿主网站的用户的授权，从而获取该用户的各种信息的服务，但其核心目的不是为了标识用户身份。为了使得第三方网站能在较长时间内获取用户的信息，宿主网站颁发的Token的有效期一般都比较长，这样第三方网站可能会利用该Token恶意长期使用宿主网站提供的服务，尤其是针对某些宿主网站提供的扣费服务，假如被恶意使用，会给用户造成很大的损失。另外，oauth协议也需要用户登录宿主网站，而且需要得到宿主网站的授权，操作起来十分复杂。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的用户认证系统和相应的用户认证方法。

根据本发明的一个方面，提供了一种用户认证系统，包括用户代理装置、宿主网站服务器以及第三方应用服务器；

所述用户代理装置包括：登录器，适于当用户登录时获取包括第一用户标识的用户登录信息；第一发送器，适于当用户访问第三方应用服务器时，将所述第一用户标识传送给所述第三方应用服务器；第一接收器，适于接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息；第二发送器，适于根据所述服务接口地址请求消息，将所述第一用户标识发送给宿主网站服务器；第二接收器，适于获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥；附加器，适于将所述用户密钥附加在服务接口地址中；所述第一发送器还适于将所述服务接口地址传送给第三方应用服务器；

所述宿主网站服务器，包括：第三接收器，适于接收用户代理装置发送的第一用户标识，所述第一用户标识是所述用户代理装置在用户登录并访问第三方应用服务器时，将所述用户的第一用户标识传送给所述第三方应用服务器之后，接收到所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息而发送的；生成器，适于根据所述第一用户标识生成用户密钥；第三发送器，适于将所述用户密钥发送给所述用户代理装置，以供所述用户代理装置将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器；第四接收器，适于接收所述第三方应用服务器发出的包括第二用户标识和所述服务接口地址的服务提供请求消息；查询器，适于解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取所述第一用户标识；第一认证器，适于根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务。

根据本发明的另一方面，提供了一种用户认证方法，包括：

当用户登录用户代理并通过所述用户代理访问第三方应用服务器时，将所述用户的第一用户标识传送给所述第三方应用服务器；

接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息，将所述第一用户标识发送给宿主网站服务器；

获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥，将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器，以供所述第三方应用服务器向所述宿主网站服务器发出包括第二用户标识和所述服务接口地址的服务提供请求消息，所述宿主网站服务器解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取所述第一用户标识，根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务；

其中，所述宿主网站服务器根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务进一步包括：

所述宿主网站服务器比较所述第一用户标识与所述第二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

通过本发明提供的技术方案，用户只需一次登录（即登录用户代理）即可通过访问第三方应用服务器使用宿主网站服务器提供的服务。而且，本发明中用户代理从宿主网站服务器处获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务器来说，用户密钥是透明的，第三方应用服务器无法获知用户密钥，因此也无法获知用户密钥及与其匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户标识发起服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提供服务，从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供的服务，给其它用户造成损失。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的用户认证方法的流程图；

图2示出了根据本发明一个实施例的用户代理装置的结构框图；

图3示出了根据本发明一个实施例的宿主网站服务器的结构框图；

图4示出了根据本发明一个实施例的用户认证系统的结构框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

用户代理（useragent）是用户通过本地浏览器或本地客户端的工具（如360桌面）等软件实现的基于Http（HypertextTransportProtocol，超文本传输协议）或Tcp（TransmissionControlProtocol，传输控制协议）的互联互通的依托宿主环境。随着互联网的飞速发展，大量用户代理均可以提供互联的业务，为了让这些软件可以正确识别用户的身份、使用自身服务器端（或者某些需要用户身份的服务端）提供的各种需要较强的安全性的服务，例如小额多次频繁扣费等服务，同时兼顾用户体验，遂提出了本发明的以下技术方案。在本文中，宿主网站服务器是指与用户代理通信的、提供各种安全性服务的自身服务器端设备，例如背景技术提到的网站B的服务器。第三方应用服务器是指用户通过用户代理访问的、提供第三方应用的服务器，例如背景技术提到的网站A的服务器。

图1示出了根据本发明一个实施例的用户认证方法100的流程图。如图1所示，方法100始于步骤S101，当用户登录用户代理时，用户代理获取包括第一用户标识的用户登录信息。其中第一用户标识是在用户代理上登录的用户的标识。

随后，方法100进入步骤S102，其中当用户通过用户代理访问第三方应用服务器时，用户代理将第一用户标识传送给第三方应用服务器。在用户登录用户代理后，用户可以通过用户代理访问其链接的各种第三方应用，此时用户代理会将第一用户标识发送给第三方应用服务器，第三方应用服务器获取到该第一用户标识后，在第三方应用的平台上显示“欢迎您，张三”，“张三”的用户标识即为第一用户标识。

随后，方法100进入步骤S103，其中用户代理接收第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息。用户在对第三方应用的访问过程中，进行了类似业务预定、下单、购买或其它消费等服务请求时，第三方应用服务器向用户代理发送服务接口地址请求消息，用于请求获取提供扣费服务的接口地址。该服务接口地址请求消息中包括第一用户标识。

方法100随后进入步骤S104，其中用户代理将第一用户标识发送给宿主网站服务器。

方法100随后进入步骤S105，其中用户代理获取宿主网站服务器根据第一用户标识生成的用户密钥，将用户密钥附加在服务接口地址中，将服务接口地址传送给第三方应用服务器。宿主网站服务器在接收到第一用户标识后，根据第一用户标识生成用户密钥（如Token），并记录下第一用户标识与其用户密钥的对应关系。作为一种实施方式，宿主网站服务器获取提供扣费等服务的服务接口地址，将该服务接口地址和用户密钥一并返回给用户代理，用户代理将用户密钥附加在服务接口地址中，接着将服务接口地址传送给第三方应用服务器。作为另一种实施方式，用户代理自己获取提供扣费等服务的服务接口地址，在接收到宿主网站服务器返回的用户密钥后，将用户密钥附加在服务接口地址中，接着将服务接口地址传送给第三方应用服务器。本方法中，用户密钥是字符串的形式，服务接口地址本身也是字符串的形式，将用户密钥附加在服务接口地址中后服务接口地址仍然是字符串的形式，对于第三方应用服务器来说，它并不知道接收到的服务接口地址中附加了用户密钥，也即用户密钥对第三方应用服务器是透明的。

随后，方法100进入步骤S106，其中第三方应用服务器向宿主网站服务器发出包括第二用户标识和服务接口地址的服务提供请求消息。在第三方应用服务器接收到服务接口地址之后，第三方应用服务器知道可以向该服务接口地址发起扣费等服务提供请求消息，该服务提供请求消息中需要携带用户标识，指明向哪个用户的账户发起扣费请求。在正常情况下，该服务器提供请求消息中携带的用户标识应该与之前发出的服务接口地址请求消息中携带的用户标识一致；但在非正常情况下，两者携带的用户标识会不一致。举例来说，用户“张三”登录用户代理并通过用户代理访问第三方应用服务器，第三方应用服务器根据“张三”的用户标识请求得到了服务接口地址（包含宿主服务器为“张三”分配的Token），接着第三方应用服务器仍应该使用“张三”的用户标识发起对“张三”账户的扣费请求消息，但是在非正常情况下，第三方应用服务器有可能恶意使用宿主网站服务器为“张三”分配的Token，使用“李四”的用户标识发起对“李四”账户的扣费请求消息，从而造成“李四”账户的损失。

随后，方法100进入步骤S107，其中宿主网站服务器解析服务接口地址，获取用户密钥，根据用户密钥获取第一用户标识。宿主网站服务器解析服务接口地址获取用户密钥，根据之前记录的第一用户标识与用户密钥的对应关系，得到第一用户标识。

随后，方法100进入步骤S108，其中宿主网站服务器根据第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用提供服务。具体地，宿主网站服务器比较第一用户标识与第二用户标识是否一致，若一致，则确定向第三方应用服务器提供服务。在上述例子中，宿主网站服务器根据用户密钥得到的第一用户标识为“张三”的用户标识，如果宿主网站服务器从接收到的服务提供请求消息中提取出的第二用户标识也是“张三”的用户标识，通过对比发现两者一致，那么则确定向第三方应用服务器提供扣费等服务；如果宿主网站服务器从接收到的服务提供请求消息中提取出的第二用户标识是“李四”的用户标识，那么确定暂时不向第三方应用服务器提供服务。

通过本实施例提供的方法，用户只需一次登录（即登录用户代理）即可通过访问第三方应用服务器使用宿主网站服务器提供的服务。而且，本方法中用户代理从宿主网站服务器处获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务器来说，用户密钥是透明的，第三方应用服务器无法获知用户密钥，因此也无法获知用户密钥及与其匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户标识发起服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提供服务，从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供的服务，给其它用户造成损失。进一步的，宿主网站服务器提供的用户密钥可以是一次性的，第三方应用服务器只可以发起一次针对该用户密钥的服务提供请求消息。

可选地，在上述实施例的基础上，在步骤S102中用户代理将第一用户标识发送给第三方应用服务器的同时，还将第一请求IP发送给第三方应用服务器。该第一请求IP是用户代理所对应客户端的IP地址，用户代理所对应的客户端是指用户登录用户代理时所使用的客户端。在步骤S104中用户代理将第一用户标识发送给宿主网站服务器的同时，还将第一请求IP发送给宿主网站服务器。在步骤S105中宿主网站服务器根据第一用户标识和第一请求IP生成用户密钥，并记录下第一用户标识和第一请求IP与其用户密钥的对应关系，用户代理获取该用户密钥。在步骤S106中，第三方应用服务器向宿主网站服务器发出包括第二用户标识、第二请求IP和服务接口地址的服务提供请求消息。在步骤S107中，宿主网站服务器解析服务接口地址，获取用户密钥，根据用户密钥获取第一用户标识和第一请求IP。在步骤S108中，宿主网站服务器比较第一用户标识和第一请求IP与第二用户标识和第二请求IP是否分别一致，若一致，则确定要向第三方应用服务器提供服务；否则，确定暂不3第三方应用服务器提供服务。该方案中通过对用户标识和请求IP同时进行认证，进一步保证了安全性。

为了本方法的兼容性，在宿主网站服务器确定暂不向第三方应用服务器提供服务之后，本方法还包括：宿主网站服务器请求获取第一用户标识对应的用户登录信息，也即宿主网站服务器要求用户重新登录宿主网站，接着宿主网站服务器根据用户登录信息生成认证信息；宿主网站服务器根据认证信息完成用户认证后，向第三方应用服务器提供服务。

从上述实施例提供的方法来看，如果第三方应用服务器按照正常的流程，模拟用户发起扣费请求，尽管用户密钥可以是一次性的，但第三方应用服务器可以多次获取用户密钥来对确实已经登录的用户的账户进行扣费操作，为了避免出现这种问题，提供如下解决方案：

对于隐私类接口，在上述步骤S106中，如果宿主网站服务器在预设时间内接收到第三方应用服务器发出的超过预设次数的服务提供请求消息，则要求用户输入验证码信息并验证。这样可以限制第三方应用服务器的调用次数，保证用户账户的安全性。

对于扣费类接口，在上述步骤S106中，如果宿主网站服务器接收到第三方应用服务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。这样可以限制第三方应用服务器调用金额，保证用户账户的安全性。

图2示出了根据本发明一个实施例的用户代理装置200的结构框图。该用户代理装置200就是上述方法实施例中所描述的用户代理。如图2所示，该用户代理装置200包括：登录器210、第一发送器220、第一接收器230、第二发送器240、第二接收器250和附加器260。

登录器210适于当用户登录时获取包括第一用户标识的用户登录信息。当用户登录用户代理装置时，登录器210获取包括第一用户标识的用户登录信息。其中第一用户标识是在用户代理装置上登录的用户的标识。

第一发送器220适于当用户访问第三方应用服务器时，将第一用户标识传送给第三方应用服务器。在用户登录用户代理装置后，用户可以通过用户代理装置访问其链接的各种第三方应用，此时第一发送器220会将第一用户标识发送给第三方应用服务器。

第一接收器230适于接收第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息。用户在对第三方应用的访问过程中，进行了类似业务预定、下单、购买或其它消费等服务请求，第三方应用服务器向用户代理发送服务接口地址请求消息，用于请求获取提供扣费服务的接口地址。第一接收器230接收包括第一用户标识的服务接口地址请求消息。

第二发送器240适于根据服务接口地址请求消息，将第一用户标识发送给宿主网站服务器。

第二接收器250适于获取宿主网站服务器根据第一用户标识生成的用户密钥。宿主网站服务器在接收到第一用户标识后，根据第一用户标识生成用户密钥（如Token），并记录下第一用户标识与其用户密钥的对应关系，然后将用户密钥发送给用户代理装置，第二接收器250接收该用户密钥。

附加器260适于将用户密钥附加在服务接口地址中。

第一发送器220还适于将服务接口地址传送给第三方应用服务器。用户密钥是字符串的形式，服务接口地址本身也是字符串的形式，将用户密钥附加在服务接口地址中后服务接口地址仍然是字符串的形式，对于第三方应用服务器来说，它并不知道接收到的服务接口地址中附加了用户密钥，也即用户密钥对第三方应用服务器是透明的。

可选地，第一发送器220具体适于当用户访问第三方应用服务器时，将第一用户标识和第一请求IP传送给第三方应用服务器，第一请求IP是用户代理装置所在客户端的IP。第二发送器240具体适于根据服务接口地址请求消息，将第一用户标识和第一请求IP发送给宿主网站服务器。第二接收器250具体适于获取宿主网站服务器根据第一用户标识和第一请求IP生成的用户密钥。

图3示出了根据本发明一个实施例的宿主网站服务器300的结构框图。如图3所示，该宿主网站服务器300包括：第三接收器310、生成器320、第三发送器330、第四接收器340、查询器350和第一认证器360。

第三接收器310适于接收用户代理装置发送的第一用户标识，该第一用户标识是用户代理装置在用户登录并访问第三方应用服务器时，将用户的第一用户标识传送给第三方应用服务器之后，接收到第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息而发送的。

生成器320适于根据第一用户标识生成用户密钥。宿主网站服务器300还记录下第一用户标识与其用户密钥的对应关系。

第三发送器330适于将用户密钥发送给用户代理装置，以供用户代理装置将用户密钥附加在服务接口地址中，将服务接口地址传送给第三方应用服务器。用户密钥是字符串的形式，服务接口地址本身也是字符串的形式，将用户密钥附加在服务接口地址中后服务接口地址仍然是字符串的形式，对于第三方应用服务器来说，它并不知道接收到的服务接口地址中附加了用户密钥，也即用户密钥对第三方应用服务器是透明的。

第四接收器340适于接收第三方应用服务器发出的包括第二用户标识和服务接口地址的服务提供请求消息。

查询器350适于解析服务接口地址，获取用户密钥，然后根据用户密钥获取第一用户标识。

第一认证器360适于根据第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务。具体地，第一认证器360比较第一用户标识与第二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

可选地，第三接收器310进一步适于接收用户代理装置发送的第一请求IP；该第一请求IP是用户代理装置对应的客户端的IP。生成器320具体适于根据第一用户标识和第一请求IP生成的用户密钥。第四接收器340具体适于接收第三方应用服务器发出的包括第二用户标识、第二请求IP和服务接口地址的服务提供请求消息。查询器350具体适于解析服务接口地址，获取用户密钥，然后根据用户密钥获取第一用户标识和第一请求IP。第一认证器360具体适于比较第一用户标识和第一请求IP与第二用户标识和第二请求IP是否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

为了本装置的兼容性，宿主网站服务器300还包括：第五接收器370和第二认证器380。其中，第五接收器370适于向第三方应用服务器请求获取第一用户标识对应的用户登录信息；第二认证器380适于根据用户登录信息生成认证信息，根据认证信息完成用户认证后，向第三方应用服务器提供服务。

为了避免出现第三方应用服务器多次获取用户密钥对确实已经登录的用户的账户进行扣费操作，宿主网站服务器还可以包括：第一验证器或第二验证器390。其中，第一验证器适于在预设时间内接收到第三方应用服务器发出的超过预设次数的服务提供请求消息的情况下，要求用户输入验证码信息并验证。第二验证器适于在接收到第三方应用服务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。

图4示出了根据本发明一个实施例的用户认证系统400的结构框图。如图4所示，该用户认证系统400包括用户代理装置410、宿主网站服务器420和第三方应用服务器430。其中用户代理装置410可以为图2所示的用户代理装置，宿主网站服务器420可以为图3所示的宿主网站服务器。用户代理装置410、宿主网站服务器420以及第三方应用服务器430之间可以通过各种有线或无线网络方式进行连接。

通过本发明提供的上述装置，用户只需一次登录（即登录用户代理）即可通过访问第三方应用服务器使用宿主网站服务器提供的服务。而且，用户代理从宿主网站服务器处获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务器来说，用户密钥是透明的，第三方应用服务器无法获知用户密钥，因此也无法获知用户密钥及与其匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户标识发起服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提供服务，从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供的服务，给其它用户造成损失。进一步的，宿主网站服务器提供的用户密钥可以是一次性的，第三方应用服务器只可以发起一次针对该用户密钥的服务提供请求消息。

根据本发明提供的用户认证方法及系统、用户代理装置、宿主网站服务器，用户在用户代理的引导下进行一次登录，即可享受多方网站或多方接口提供的优质服务，给用户提供了良好的体验。与此同时，通过将用户密钥附加在服务接口地址中，第三方应用服务器无法获知该用户密钥，从而控制第三方应用服务器的非法操作，保证用户账户的安全性。总而言之，本发明提供了兼顾便利性和安全性的用户认证方案。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的用户代理装置、宿主网站服务器及用户认证系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (13)

1.一种用户认证系统，包括用户代理装置、宿主网站服务器以及第三方应用服务器；其中，

所述用户代理装置包括：

登录器，适于当用户登录时获取包括第一用户标识的用户登录信息；

第一发送器，适于当用户访问第三方应用服务器时，将所述第一用户标识传送给所述第三方应用服务器；

第一接收器，适于接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息；

第二发送器，适于根据所述服务接口地址请求消息，将所述第一用户标识发送给宿主网站服务器；

第二接收器，适于获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥；

附加器，适于将所述用户密钥附加在服务接口地址中；

所述第一发送器还适于将所述服务接口地址传送给第三方应用服务器；

所述宿主网站服务器包括：

第三接收器，适于接收用户代理装置发送的第一用户标识，所述第一用户标识是所述用户代理装置在用户登录并访问第三方应用服务器时，将所述用户的第一用户标识传送给所述第三方应用服务器之后，接收到所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息而发送的；

生成器，适于根据所述第一用户标识生成用户密钥；

第三发送器，适于将所述用户密钥发送给所述用户代理装置，以供所述用户代理装置将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器；

第四接收器，适于接收所述第三方应用服务器发出的包括第二用户标识和所述服务接口地址的服务提供请求消息；

查询器，适于解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取所述第一用户标识；

第一认证器，适于根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务。

2.根据权利要求1所述的用户认证系统，所述第一发送器具体适于当用户访问第三方应用服务器时，将所述第一用户标识和第一请求IP传送给所述第三方应用服务器，所述第一请求IP是用户代理装置所在客户端的IP；

第二发送器进一步适于根据所述服务接口地址请求消息，将所述第一用户标识和第一请求IP发送给所述宿主网站服务器；

所述第二接收器进一步适于获取所述宿主网站服务器根据所述第一用户标识和第一请求IP生成的用户密钥。

3.根据权利要求1或2所述的用户认证系统，所述第一认证器进一步适于比较所述第一用户标识与所述第二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

4.根据权利要求1或2所述的用户认证系统，所述第三接收器进一步适于接收用户代理装置发送的第一请求IP；所述第一请求IP是所述用户代理装置对应的客户端的IP；

所述生成器进一步适于根据所述第一用户标识和第一请求IP生成的用户密钥；

所述第四接收器进一步适于接收所述第三方应用服务器发出的包括第二用户标识、第二请求IP和所述服务接口地址的服务提供请求消息；

所述查询器进一步适于解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取所述第一用户标识和第一请求IP；

所述第一认证器进一步适于比较所述第一用户标识和第一请求IP与第二用户标识和第二请求IP是否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

5.根据权利要求3或4所述的用户认证系统，其中，所述宿主网站服务器还包括：

第五接收器，适于向所述第三方应用服务器请求获取第一用户标识对应的用户登录信息；

第二认证器，适于根据所述用户登录信息生成认证信息，根据所述认证信息完成用户认证后，向第三方应用服务器提供服务。

6.根据权利要求1所述的用户认证系统，其中，所述宿主网站服务器还包括：

第一验证器，适于在预设时间内接收到第三方应用服务器发出的超过预设次数的服务提供请求消息的情况下，要求用户输入验证码信息并验证。

7.根据权利要求1所述的用户认证系统，其中，所述宿主网站服务器还包括：

第二验证器，适于在接收到第三方应用服务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。

8.一种用户认证方法，包括：

当用户登录用户代理并通过所述用户代理访问第三方应用服务器时，将所述用户的第一用户标识传送给所述第三方应用服务器；

接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息，将所述第一用户标识发送给宿主网站服务器；

获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥，将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器，以供所述第三方应用服务器向所述宿主网站服务器发出包括第二用户标识和所述服务接口地址的服务提供请求消息，所述宿主网站服务器解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取所述第一用户标识，根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务；

其中，所述宿主网站服务器根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务进一步包括：

所述宿主网站服务器比较所述第一用户标识与所述第二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

9.根据权利要求8所述的方法，将所述第一用户标识传送给第三方应用服务器的同时，还将第一请求IP传送给第三方应用服务器；将所述第一用户标识发送给宿主网站服务器的同时，还将第一请求IP发送给宿主网站服务器，所述第一请求IP是用户代理所对应客户端的IP；

所述获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥进一步为：获取所述宿主网站服务器根据所述第一用户标识和第一请求IP生成的用户密钥。

10.根据权利要求9所述的方法，所述服务提供请求消息还包括第二请求IP；

所述宿主网站服务器根据所述用户密钥获取所述第一用户标识，根据所述第一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务进一步包括：

所述宿主网站服务器根据所述用户密钥获得所述第一用户标识和第一请求IP；

所述宿主网站服务器比较所述第一用户标识和第一请求IP与第二用户标识和第二请求IP是否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。

11.根据权利要求8或10所述的方法，在所述宿主网站服务器确定暂不向第三方应用服务器提供服务之后还包括：

所述宿主网站服务器请求获取所述第一用户标识对应的用户登录信息，根据该用户登录信息生成认证信息；

根据所述认证信息完成用户认证后，向第三方应用服务器提供服务。

12.根据权利要求8至10任一项所述的方法，还包括：如果所述宿主网站服务器在预设时间内接收到第三方应用服务器发出的超过预设次数的服务提供请求消息，则要求用户输入验证码信息并验证。

13.根据权利要求8至10任一项所述的方法，还包括：如果所述宿主网站服务器接收到第三方应用服务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。