《用户认证方法及系统.pdf》由会员分享，可在线阅读，更多相关《用户认证方法及系统.pdf（16页珍藏版）》请在专利查询网上搜索。
1、(10)申请公布号 CN 102946397 A (43)申请公布日 2013.02.27 C N 1 0 2 9 4 6 3 9 7 A *CN102946397A* (21)申请号 201210487730.X (22)申请日 2012.11.26 H04L 29/06(2006.01) (71)申请人北京奇虎科技有限公司 地址 100088 北京市西城区新街口外大街 28号D座112室（德胜园区） 申请人奇智软件（北京）有限公司 (72)发明人张玉智 东玮 (74)专利代理机构北京市浩天知识产权代理事 务所 11276 代理人靳春鹰 宋菲 (54) 发明名称 用户认证方法及系统 (57)。
2、 摘要 本发明公开了一种用户认证方法及系统。其 中用户认证方法包括：当用户登录用户代理并通 过所述用户代理访问第三方应用服务器时，将第 一用户标识传送给第三方应用服务器；接收第三 方应用服务器发出的服务接口地址请求消息，将 所述第一用户标识发送给宿主网站服务器；获取 用户密钥，将其附加在服务接口地址中，将服务接 口地址传送给第三方应用服务器，宿主网站服务 器解析服务接口地址，获取用户密钥，然后根据第 一用户标识与第二用户标识是否一致来确定是否 要向第三方应用服务器提供服务。通过本发明提 供的技术方案，用户只需一次登录即可通过访问 第三方应用服务器使用宿主网站服务器提供的服 务，而且还避免了给其。
3、它用户造成损失。 (51)Int.Cl. 权利要求书3页 说明书9页 附图3页 (19)中华人民共和国国家知识产权局 (12)发明专利申请 权利要求书 3 页 说明书 9 页 附图 3 页 1/3页 2 1.一种用户认证系统，包括用户代理装置、宿主网站服务器以及第三方应用服务器； 其中， 所述用户代理装置包括： 登录器，适于当用户登录时获取包括第一用户标识的用户登录信息； 第一发送器，适于当用户访问第三方应用服务器时，将所述第一用户标识传送给所述 第三方应用服务器； 第一接收器，适于接收所述第三方应用服务器发出的包括第一用户标识的服务接口地 址请求消息； 第二发送器，适于根据所述服务接口地址请。
4、求消息，将所述第一用户标识发送给宿主 网站服务器； 第二接收器，适于获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥； 附加器，适于将所述用户密钥附加在服务接口地址中； 所述第一发送器还适于将所述服务接口地址传送给第三方应用服务器； 所述宿主网站服务器包括： 第三接收器，适于接收用户代理装置发送的第一用户标识，所述第一用户标识是所述 用户代理装置在用户登录并访问第三方应用服务器时，将所述用户的第一用户标识传送给 所述第三方应用服务器之后，接收到所述第三方应用服务器发出的包括第一用户标识的服 务接口地址请求消息而发送的； 生成器，适于根据所述第一用户标识生成用户密钥； 第三发送器，适于将。
5、所述用户密钥发送给所述用户代理装置，以供所述用户代理装置 将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器； 第四接收器，适于接收所述第三方应用服务器发出的包括第二用户标识和所述服务接 口地址的服务提供请求消息； 查询器，适于解析所述服务接口地址，获取所述用户密钥，然后根据所述用户密钥获取 所述第一用户标识； 第一认证器，适于根据所述第一用户标识与第二用户标识是否一致的比较结果确定是 否要向第三方应用服务器提供服务。 2.根据权利要求1所述的用户认证系统，所述第一发送器具体适于当用户访问第三方 应用服务器时，将所述第一用户标识和第一请求IP传送给所述第三方应用服务器。
6、，所述第 一请求IP是用户代理装置所在客户端的IP； 第二发送器进一步适于根据所述服务接口地址请求消息，将所述第一用户标识和第一 请求IP发送给所述宿主网站服务器； 所述第二接收器进一步适于获取所述宿主网站服务器根据所述第一用户标识和第一 请求IP生成的用户密钥。 3.根据权利要求1或2所述的用户认证系统，所述第一认证器进一步适于比较所述第 一用户标识与所述第二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服 务；否则确定暂不向第三方应用服务器提供服务。 4.根据权利要求1或2所述的用户认证系统，所述第三接收器进一步适于接收用户代 理装置发送的第一请求IP；所述第一请求IP是所述用户。
7、代理装置对应的客户端的IP； 权 利 要 求 书CN 102946397 A 2/3页 3 所述生成器进一步适于根据所述第一用户标识和第一请求IP生成的用户密钥； 所述第四接收器进一步适于接收所述第三方应用服务器发出的包括第二用户标识、第 二请求IP和所述服务接口地址的服务提供请求消息； 所述查询器进一步适于解析所述服务接口地址，获取所述用户密钥，然后根据所述用 户密钥获取所述第一用户标识和第一请求IP； 所述第一认证器进一步适于比较所述第一用户标识和第一请求IP与第二用户标识和 第二请求IP是否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定 暂不向第三方应用服务器提供服务。。
8、 5.根据权利要求3或4所述的用户认证系统，其中，所述宿主网站服务器还包括： 第五接收器，适于向所述第三方应用服务器请求获取第一用户标识对应的用户登录信 息； 第二认证器，适于根据所述用户登录信息生成认证信息，根据所述认证信息完成用户 认证后，向第三方应用服务器提供服务。 6.根据权利要求1至5任一项所述的用户认证系统，其中，所述宿主网站服务器还包 括： 第一验证器，适于在预设时间内接收到第三方应用服务器发出的超过预设次数的服务 提供请求消息的情况下，要求用户输入验证码信息并验证。 7.根据权利要求1至5任一项所述的用户认证系统，其中，所述宿主网站服务器还包 括： 第二验证器，适于在接收到第三。
9、方应用服务器发出超过预设金额的服务提供请求消 息，则要求用户输入验证码信息并验证。 8.一种用户认证方法，包括： 当用户登录用户代理并通过所述用户代理访问第三方应用服务器时，将所述用户的第 一用户标识传送给所述第三方应用服务器； 接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息，将所 述第一用户标识发送给宿主网站服务器； 获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥，将所述用户密钥附 加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器，以供所述第三方应 用服务器向所述宿主网站服务器发出包括第二用户标识和所述服务接口地址的服务提供 请求消息，所述宿主网站。
10、服务器解析所述服务接口地址，获取所述用户密钥，然后根据所述 用户密钥获取所述第一用户标识，根据所述第一用户标识与第二用户标识是否一致的比较 结果确定是否要向第三方应用服务器提供服务； 其中，所述宿主网站服务器根据所述第一用户标识与第二用户标识是否一致的比较结 果确定是否要向第三方应用服务器提供服务进一步包括： 所述宿主网站服务器比较所述第一用户标识与所述第二用户标识是否一致，若一致， 则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。 9.根据权利要求8所述的方法，将所述第一用户标识传送给第三方应用服务器的同 时，还将第一请求IP传送给第三方应用服务器；将所述第一用户。
11、标识发送给宿主网站服务 器的同时，还将第一请求IP发送给宿主网站服务器，所述第一请求IP是用户代理所对应客 权 利 要 求 书CN 102946397 A 3/3页 4 户端的IP； 所述获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥进一步为：获取 所述宿主网站服务器根据所述第一用户标识和第一请求IP生成的用户密钥。 10.根据权利要求9所述的方法，所述服务提供请求消息还包括第二请求IP； 所述宿主网站服务器根据所述用户密钥获取所述第一用户标识，根据所述第一用户标 识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服务进一步 包括： 所述宿主网站服务器根据所述用户密钥。
12、获得所述第一用户标识和第一请求IP； 所述宿主网站服务器比较所述第一用户标识和第一请求IP与第二用户标识和第二请 求IP是否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定暂不向 第三方应用服务器提供服务。 11.根据权利要求8或10所述的方法，在所述宿主网站服务器确定暂不向第三方应用 服务器提供服务之后还包括： 所述宿主网站服务器请求获取所述第一用户标识对应的用户登录信息，根据该用户登 录信息生成认证信息； 根据所述认证信息完成用户认证后，向第三方应用服务器提供服务。 12.根据权利要求8至11任一项所述的方法，还包括：如果所述宿主网站服务器在预 设时间内接收到第三方应用服务。
13、器发出的超过预设次数的服务提供请求消息，则要求用户 输入验证码信息并验证。 13.根据权利要求8至11任一项所述的方法，还包括：如果所述宿主网站服务器接收 到第三方应用服务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息 并验证。 权 利 要 求 书CN 102946397 A 1/9页 5 用户认证方法及系统 技术领域 0001 本发明涉及网络安全技术领域，具体涉及一种用户认证方法及系统。 背景技术 0002 cookie是互联网网站为了辨别用户身份而存储在用户使用的本地客户端上的数 据。当用户需要某网站提供的服务时，用户登录该网站，网站会在本地客户端上存储一个小 文本文件，用。
14、于记录用户ID（标识）、密码、网页地址和停留时间等cookie信息，接下来用户 在该网站进行类似业务预定、下单、购买或其它消费等各种服务时，网站通过cookie确认 用户身份，完成提供服务的流程。cookie识别方案是RFC（Request For Comments，一系列 以编号排定的文件）协议中的标准流程。cookie只能在宿主网站使用，第三方网站不能使 用其它网站生成的cookie。如果用户通过第三方网站（如网站A）需要使用宿主网站（如网 站B）提供的服务，则必须要求用户通过网站A中的链接到达网站B，进行二次登录（第一次 登录网站A，第二次登录网站B）。现有技术还提供了一种oauth协议。
15、，该协议为用户资源的 授权提供了一个安全、开放而又简易的标准。根据oauth协议的规定，第三方网站（如网站 A）为了使用宿主网站（如网站B）的一些需要用户身份的接口或服务，需要引导用户到达网 站B，在网站B完成登录和授权等相应流程，网站B会颁发一个在一定时间内（称为有效期） 唯一标识该用户的标记（Token）给网站A，网站A可以使用这个Token在有效期内多次获取 用户的信息，继而提供相应的服务。oauth协议为了取得宿主网站的用户的授权，从而获取 该用户的各种信息的服务，但其核心目的不是为了标识用户身份。为了使得第三方网站能 在较长时间内获取用户的信息，宿主网站颁发的Token的有效期一般都。
16、比较长，这样第三 方网站可能会利用该Token恶意长期使用宿主网站提供的服务，尤其是针对某些宿主网站 提供的扣费服务，假如被恶意使用，会给用户造成很大的损失。另外，oauth协议也需要用 户登录宿主网站，而且需要得到宿主网站的授权，操作起来十分复杂。 发明内容 0003 鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上 述问题的用户认证系统和相应的用户认证方法。 0004 根据本发明的一个方面，提供了一种用户认证系统，包括用户代理装置、宿主网站 服务器以及第三方应用服务器； 0005 所述用户代理装置包括：登录器，适于当用户登录时获取包括第一用户标识的用 户登录信息；第一。
17、发送器，适于当用户访问第三方应用服务器时，将所述第一用户标识传送 给所述第三方应用服务器；第一接收器，适于接收所述第三方应用服务器发出的包括第一 用户标识的服务接口地址请求消息；第二发送器，适于根据所述服务接口地址请求消息，将 所述第一用户标识发送给宿主网站服务器；第二接收器，适于获取所述宿主网站服务器根 据所述第一用户标识生成的用户密钥；附加器，适于将所述用户密钥附加在服务接口地址 中；所述第一发送器还适于将所述服务接口地址传送给第三方应用服务器； 说 明 书CN 102946397 A 2/9页 6 0006 所述宿主网站服务器，包括：第三接收器，适于接收用户代理装置发送的第一用户 标识，。
18、所述第一用户标识是所述用户代理装置在用户登录并访问第三方应用服务器时，将 所述用户的第一用户标识传送给所述第三方应用服务器之后，接收到所述第三方应用服务 器发出的包括第一用户标识的服务接口地址请求消息而发送的；生成器，适于根据所述第 一用户标识生成用户密钥；第三发送器，适于将所述用户密钥发送给所述用户代理装置，以 供所述用户代理装置将所述用户密钥附加在服务接口地址中，将所述服务接口地址传送给 第三方应用服务器；第四接收器，适于接收所述第三方应用服务器发出的包括第二用户标 识和所述服务接口地址的服务提供请求消息；查询器，适于解析所述服务接口地址，获取所 述用户密钥，然后根据所述用户密钥获取所述第。
19、一用户标识；第一认证器，适于根据所述第 一用户标识与第二用户标识是否一致的比较结果确定是否要向第三方应用服务器提供服 务。 0007 根据本发明的另一方面，提供了一种用户认证方法，包括： 0008 当用户登录用户代理并通过所述用户代理访问第三方应用服务器时，将所述用户 的第一用户标识传送给所述第三方应用服务器； 0009 接收所述第三方应用服务器发出的包括第一用户标识的服务接口地址请求消息， 将所述第一用户标识发送给宿主网站服务器； 0010 获取所述宿主网站服务器根据所述第一用户标识生成的用户密钥，将所述用户密 钥附加在服务接口地址中，将所述服务接口地址传送给第三方应用服务器，以供所述第三 。
20、方应用服务器向所述宿主网站服务器发出包括第二用户标识和所述服务接口地址的服务 提供请求消息，所述宿主网站服务器解析所述服务接口地址，获取所述用户密钥，然后根据 所述用户密钥获取所述第一用户标识，根据所述第一用户标识与第二用户标识是否一致的 比较结果确定是否要向第三方应用服务器提供服务； 0011 其中，所述宿主网站服务器根据所述第一用户标识与第二用户标识是否一致的比 较结果确定是否要向第三方应用服务器提供服务进一步包括： 0012 所述宿主网站服务器比较所述第一用户标识与所述第二用户标识是否一致，若一 致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应用服务器提供服务。 0013 。
21、通过本发明提供的技术方案，用户只需一次登录（即登录用户代理）即可通过访问 第三方应用服务器使用宿主网站服务器提供的服务。而且，本发明中用户代理从宿主网站 服务器处获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务 器来说，用户密钥是透明的，第三方应用服务器无法获知用户密钥，因此也无法获知用户密 钥及与其匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户 标识发起服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提 供服务，从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供 的服务，给其它用户造成损失。 0014 上述。
22、说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段， 而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够 更明显易懂，以下特举本发明的具体实施方式。 附图说明 说 明 书CN 102946397 A 3/9页 7 0015 通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通 技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明 的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中： 0016 图1示出了根据本发明一个实施例的用户认证方法的流程图； 0017 图2示出了根据本发明一个实施例的用户。
23、代理装置的结构框图； 0018 图3示出了根据本发明一个实施例的宿主网站服务器的结构框图； 0019 图4示出了根据本发明一个实施例的用户认证系统的结构框图。 具体实施方式 0020 下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开 的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例 所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围 完整的传达给本领域的技术人员。 0021 用户代理（user agent）是用户通过本地浏览器或本地客户端的工具（如360桌 面）等软件实现的基于Http（Hypertext Tra。
24、nsport Protocol，超文本传输协议）或Tcp （Transmission Control Protocol，传输控制协议）的互联互通的依托宿主环境。随着互联 网的飞速发展，大量用户代理均可以提供互联的业务，为了让这些软件可以正确识别用户 的身份、使用自身服务器端（或者某些需要用户身份的服务端）提供的各种需要较强的安全 性的服务，例如小额多次频繁扣费等服务，同时兼顾用户体验，遂提出了本发明的以下技术 方案。在本文中，宿主网站服务器是指与用户代理通信的、提供各种安全性服务的自身服务 器端设备，例如背景技术提到的网站B的服务器。第三方应用服务器是指用户通过用户代 理访问的、提供第三方应用。
25、的服务器，例如背景技术提到的网站A的服务器。 0022 图1示出了根据本发明一个实施例的用户认证方法100的流程图。如图1所示， 方法100始于步骤S101，当用户登录用户代理时，用户代理获取包括第一用户标识的用户 登录信息。其中第一用户标识是在用户代理上登录的用户的标识。 0023 随后，方法100进入步骤S102，其中当用户通过用户代理访问第三方应用服务器 时，用户代理将第一用户标识传送给第三方应用服务器。在用户登录用户代理后，用户可以 通过用户代理访问其链接的各种第三方应用，此时用户代理会将第一用户标识发送给第三 方应用服务器，第三方应用服务器获取到该第一用户标识后，在第三方应用的平台上。
26、显示 “欢迎您，张三”，“张三”的用户标识即为第一用户标识。 0024 随后，方法100进入步骤S103，其中用户代理接收第三方应用服务器发出的包括 第一用户标识的服务接口地址请求消息。用户在对第三方应用的访问过程中，进行了类似 业务预定、下单、购买或其它消费等服务请求时，第三方应用服务器向用户代理发送服务接 口地址请求消息，用于请求获取提供扣费服务的接口地址。该服务接口地址请求消息中包 括第一用户标识。 0025 方法100随后进入步骤S104，其中用户代理将第一用户标识发送给宿主网站服务 器。 0026 方法100随后进入步骤S105，其中用户代理获取宿主网站服务器根据第一用户标 识生成的。
27、用户密钥，将用户密钥附加在服务接口地址中，将服务接口地址传送给第三方应 说 明 书CN 102946397 A 4/9页 8 用服务器。宿主网站服务器在接收到第一用户标识后，根据第一用户标识生成用户密钥（如 Token），并记录下第一用户标识与其用户密钥的对应关系。作为一种实施方式，宿主网站服 务器获取提供扣费等服务的服务接口地址，将该服务接口地址和用户密钥一并返回给用户 代理，用户代理将用户密钥附加在服务接口地址中，接着将服务接口地址传送给第三方应 用服务器。作为另一种实施方式，用户代理自己获取提供扣费等服务的服务接口地址，在接 收到宿主网站服务器返回的用户密钥后，将用户密钥附加在服务接口地。
28、址中，接着将服务 接口地址传送给第三方应用服务器。本方法中，用户密钥是字符串的形式，服务接口地址本 身也是字符串的形式，将用户密钥附加在服务接口地址中后服务接口地址仍然是字符串的 形式，对于第三方应用服务器来说，它并不知道接收到的服务接口地址中附加了用户密钥， 也即用户密钥对第三方应用服务器是透明的。 0027 随后，方法100进入步骤S106，其中第三方应用服务器向宿主网站服务器发出包 括第二用户标识和服务接口地址的服务提供请求消息。在第三方应用服务器接收到服务 接口地址之后，第三方应用服务器知道可以向该服务接口地址发起扣费等服务提供请求消 息，该服务提供请求消息中需要携带用户标识，指明向哪。
29、个用户的账户发起扣费请求。在 正常情况下，该服务器提供请求消息中携带的用户标识应该与之前发出的服务接口地址 请求消息中携带的用户标识一致；但在非正常情况下，两者携带的用户标识会不一致。举 例来说，用户“张三”登录用户代理并通过用户代理访问第三方应用服务器，第三方应用服 务器根据“张三”的用户标识请求得到了服务接口地址（包含宿主服务器为“张三”分配的 Token），接着第三方应用服务器仍应该使用“张三”的用户标识发起对“张三”账户的扣费 请求消息，但是在非正常情况下，第三方应用服务器有可能恶意使用宿主网站服务器为“张 三”分配的Token，使用“李四”的用户标识发起对“李四”账户的扣费请求消息，。
30、从而造成 “李四”账户的损失。 0028 随后，方法100进入步骤S107，其中宿主网站服务器解析服务接口地址，获取用户 密钥，根据用户密钥获取第一用户标识。宿主网站服务器解析服务接口地址获取用户密钥， 根据之前记录的第一用户标识与用户密钥的对应关系，得到第一用户标识。 0029 随后，方法100进入步骤S108，其中宿主网站服务器根据第一用户标识与第二用 户标识是否一致的比较结果确定是否要向第三方应用提供服务。具体地，宿主网站服务器 比较第一用户标识与第二用户标识是否一致，若一致，则确定向第三方应用服务器提供服 务。在上述例子中，宿主网站服务器根据用户密钥得到的第一用户标识为“张三”的用户标。
31、 识，如果宿主网站服务器从接收到的服务提供请求消息中提取出的第二用户标识也是“张 三”的用户标识，通过对比发现两者一致，那么则确定向第三方应用服务器提供扣费等服 务；如果宿主网站服务器从接收到的服务提供请求消息中提取出的第二用户标识是“李四” 的用户标识，那么确定暂时不向第三方应用服务器提供服务。 0030 通过本实施例提供的方法，用户只需一次登录（即登录用户代理）即可通过访问第 三方应用服务器使用宿主网站服务器提供的服务。而且，本方法中用户代理从宿主网站服 务器处获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务器 来说，用户密钥是透明的，第三方应用服务器无法获知用户密钥。
32、，因此也无法获知用户密钥 及与其匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户标 识发起服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提供 说 明 书CN 102946397 A 5/9页 9 服务，从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供的 服务，给其它用户造成损失。进一步的，宿主网站服务器提供的用户密钥可以是一次性的， 第三方应用服务器只可以发起一次针对该用户密钥的服务提供请求消息。 0031 可选地，在上述实施例的基础上，在步骤S102中用户代理将第一用户标识发送给 第三方应用服务器的同时，还将第一请求IP发送给。
33、第三方应用服务器。该第一请求IP是 用户代理所对应客户端的IP地址，用户代理所对应的客户端是指用户登录用户代理时所 使用的客户端。在步骤S104中用户代理将第一用户标识发送给宿主网站服务器的同时，还 将第一请求IP发送给宿主网站服务器。在步骤S105中宿主网站服务器根据第一用户标识 和第一请求IP生成用户密钥，并记录下第一用户标识和第一请求IP与其用户密钥的对应 关系，用户代理获取该用户密钥。在步骤S106中，第三方应用服务器向宿主网站服务器发 出包括第二用户标识、第二请求IP和服务接口地址的服务提供请求消息。在步骤S107中， 宿主网站服务器解析服务接口地址，获取用户密钥，根据用户密钥获取第。
34、一用户标识和第 一请求IP。在步骤S108中，宿主网站服务器比较第一用户标识和第一请求IP与第二用户 标识和第二请求IP是否分别一致，若一致，则确定要向第三方应用服务器提供服务；否则， 确定暂不3第三方应用服务器提供服务。该方案中通过对用户标识和请求IP同时进行认 证，进一步保证了安全性。 0032 为了本方法的兼容性，在宿主网站服务器确定暂不向第三方应用服务器提供服务 之后，本方法还包括：宿主网站服务器请求获取第一用户标识对应的用户登录信息，也即宿 主网站服务器要求用户重新登录宿主网站，接着宿主网站服务器根据用户登录信息生成认 证信息；宿主网站服务器根据认证信息完成用户认证后，向第三方应用服。
35、务器提供服务。 0033 从上述实施例提供的方法来看，如果第三方应用服务器按照正常的流程，模拟用 户发起扣费请求，尽管用户密钥可以是一次性的，但第三方应用服务器可以多次获取用户 密钥来对确实已经登录的用户的账户进行扣费操作，为了避免出现这种问题，提供如下解 决方案： 0034 对于隐私类接口，在上述步骤S106中，如果宿主网站服务器在预设时间内接收到 第三方应用服务器发出的超过预设次数的服务提供请求消息，则要求用户输入验证码信息 并验证。这样可以限制第三方应用服务器的调用次数，保证用户账户的安全性。 0035 对于扣费类接口，在上述步骤S106中，如果宿主网站服务器接收到第三方应用服 务器发出。
36、超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。这样可 以限制第三方应用服务器调用金额，保证用户账户的安全性。 0036 图2示出了根据本发明一个实施例的用户代理装置200的结构框图。该用户代理 装置200就是上述方法实施例中所描述的用户代理。如图2所示，该用户代理装置200包 括：登录器210、第一发送器220、第一接收器230、第二发送器240、第二接收器250和附加 器260。 0037 登录器210适于当用户登录时获取包括第一用户标识的用户登录信息。当用户登 录用户代理装置时，登录器210获取包括第一用户标识的用户登录信息。其中第一用户标 识是在用户代理装置上登录的用户。
37、的标识。 0038 第一发送器220适于当用户访问第三方应用服务器时，将第一用户标识传送给第 三方应用服务器。在用户登录用户代理装置后，用户可以通过用户代理装置访问其链接的 说 明 书CN 102946397 A 6/9页 10 各种第三方应用，此时第一发送器220会将第一用户标识发送给第三方应用服务器。 0039 第一接收器230适于接收第三方应用服务器发出的包括第一用户标识的服务接 口地址请求消息。用户在对第三方应用的访问过程中，进行了类似业务预定、下单、购买或 其它消费等服务请求，第三方应用服务器向用户代理发送服务接口地址请求消息，用于请 求获取提供扣费服务的接口地址。第一接收器230接。
38、收包括第一用户标识的服务接口地址 请求消息。 0040 第二发送器240适于根据服务接口地址请求消息，将第一用户标识发送给宿主网 站服务器。 0041 第二接收器250适于获取宿主网站服务器根据第一用户标识生成的用户密钥。宿 主网站服务器在接收到第一用户标识后，根据第一用户标识生成用户密钥（如Token），并记 录下第一用户标识与其用户密钥的对应关系，然后将用户密钥发送给用户代理装置，第二 接收器250接收该用户密钥。 0042 附加器260适于将用户密钥附加在服务接口地址中。 0043 第一发送器220还适于将服务接口地址传送给第三方应用服务器。用户密钥是字 符串的形式，服务接口地址本身也是。
39、字符串的形式，将用户密钥附加在服务接口地址中后 服务接口地址仍然是字符串的形式，对于第三方应用服务器来说，它并不知道接收到的服 务接口地址中附加了用户密钥，也即用户密钥对第三方应用服务器是透明的。 0044 可选地，第一发送器220具体适于当用户访问第三方应用服务器时，将第一用户 标识和第一请求IP传送给第三方应用服务器，第一请求IP是用户代理装置所在客户端的 IP。第二发送器240具体适于根据服务接口地址请求消息，将第一用户标识和第一请求IP 发送给宿主网站服务器。第二接收器250具体适于获取宿主网站服务器根据第一用户标识 和第一请求IP生成的用户密钥。 0045 图3示出了根据本发明一个实。
40、施例的宿主网站服务器300的结构框图。如图3所 示，该宿主网站服务器300包括：第三接收器310、生成器320、第三发送器330、第四接收器 340、查询器350和第一认证器360。 0046 第三接收器310适于接收用户代理装置发送的第一用户标识，该第一用户标识是 用户代理装置在用户登录并访问第三方应用服务器时，将用户的第一用户标识传送给第三 方应用服务器之后，接收到第三方应用服务器发出的包括第一用户标识的服务接口地址请 求消息而发送的。 0047 生成器320适于根据第一用户标识生成用户密钥。宿主网站服务器300还记录下 第一用户标识与其用户密钥的对应关系。 0048 第三发送器330适于。
41、将用户密钥发送给用户代理装置，以供用户代理装置将用户 密钥附加在服务接口地址中，将服务接口地址传送给第三方应用服务器。用户密钥是字符 串的形式，服务接口地址本身也是字符串的形式，将用户密钥附加在服务接口地址中后服 务接口地址仍然是字符串的形式，对于第三方应用服务器来说，它并不知道接收到的服务 接口地址中附加了用户密钥，也即用户密钥对第三方应用服务器是透明的。 0049 第四接收器340适于接收第三方应用服务器发出的包括第二用户标识和服务接 口地址的服务提供请求消息。 0050 查询器350适于解析服务接口地址，获取用户密钥，然后根据用户密钥获取第一 说 明 书CN 102946397 A 10。
42、 7/9页 11 用户标识。 0051 第一认证器360适于根据第一用户标识与第二用户标识是否一致的比较结果确 定是否要向第三方应用服务器提供服务。具体地，第一认证器360比较第一用户标识与第 二用户标识是否一致，若一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第 三方应用服务器提供服务。 0052 可选地，第三接收器310进一步适于接收用户代理装置发送的第一请求IP；该第 一请求IP是用户代理装置对应的客户端的IP。生成器320具体适于根据第一用户标识和 第一请求IP生成的用户密钥。第四接收器340具体适于接收第三方应用服务器发出的包 括第二用户标识、第二请求IP和服务接口地址的服。
43、务提供请求消息。查询器350具体适于 解析服务接口地址，获取用户密钥，然后根据用户密钥获取第一用户标识和第一请求IP。第 一认证器360具体适于比较第一用户标识和第一请求IP与第二用户标识和第二请求IP是 否分别一致，若都一致，则确定要向第三方应用服务器提供服务；否则确定暂不向第三方应 用服务器提供服务。 0053 为了本装置的兼容性，宿主网站服务器300还包括：第五接收器370和第二认证器 380。其中，第五接收器370适于向第三方应用服务器请求获取第一用户标识对应的用户登 录信息；第二认证器380适于根据用户登录信息生成认证信息，根据认证信息完成用户认 证后，向第三方应用服务器提供服务。 。
44、0054 为了避免出现第三方应用服务器多次获取用户密钥对确实已经登录的用户的账 户进行扣费操作，宿主网站服务器还可以包括：第一验证器或第二验证器390。其中，第一 验证器适于在预设时间内接收到第三方应用服务器发出的超过预设次数的服务提供请求 消息的情况下，要求用户输入验证码信息并验证。第二验证器适于在接收到第三方应用服 务器发出超过预设金额的服务提供请求消息，则要求用户输入验证码信息并验证。 0055 图4示出了根据本发明一个实施例的用户认证系统400的结构框图。如图4所 示，该用户认证系统400包括用户代理装置410、宿主网站服务器420和第三方应用服务器 430。其中用户代理装置410可以。
45、为图2所示的用户代理装置，宿主网站服务器420可以为 图3所示的宿主网站服务器。用户代理装置410、宿主网站服务器420以及第三方应用服务 器430之间可以通过各种有线或无线网络方式进行连接。 0056 通过本发明提供的上述装置，用户只需一次登录（即登录用户代理）即可通过访问 第三方应用服务器使用宿主网站服务器提供的服务。而且，用户代理从宿主网站服务器处 获取用户密钥后，将用户密钥附加在服务接口地址中，这样对于第三方应用服务器来说，用 户密钥是透明的，第三方应用服务器无法获知用户密钥，因此也无法获知用户密钥及与其 匹配的用户标识的对应关系。当第三方应用服务器使用与用户密钥不匹配的用户标识发起 。
46、服务提供请求消息时，宿主网站服务器通过比较处理不会向第三方应用服务器提供服务， 从而避免了第三方应用服务器利用用户密钥长期恶意地使用宿主网站服务器提供的服务， 给其它用户造成损失。进一步的，宿主网站服务器提供的用户密钥可以是一次性的，第三方 应用服务器只可以发起一次针对该用户密钥的服务提供请求消息。 0057 根据本发明提供的用户认证方法及系统、用户代理装置、宿主网站服务器，用户在 用户代理的引导下进行一次登录，即可享受多方网站或多方接口提供的优质服务，给用户 提供了良好的体验。与此同时，通过将用户密钥附加在服务接口地址中，第三方应用服务器 说 明 书CN 102946397 A 11 8/9。
47、页 12 无法获知该用户密钥，从而控制第三方应用服务器的非法操作，保证用户账户的安全性。总 而言之，本发明提供了兼顾便利性和安全性的用户认证方案。 0058 在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。 各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求 的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种 编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发 明的最佳实施方式。 0059 在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施 例可以在没有这些具体细节。
48、的情况下实践。在一些实例中，并未详细示出公知的方法、结构 和技术，以便不模糊对本说明书的理解。 0060 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在 上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施 例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保 护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面 的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此， 遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身 都作为本发明的单。
49、独实施例。 0061 本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地 改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单 元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或 子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任 何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的 任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的 权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来 代替。 0062 此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例 中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的 范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任 意之一都可以以任意的组合方式来使用。 0063 本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运。