CN103220261A - 一种开放鉴权应用程序接口代理的方法、装置及系统 - Google Patents

Abstract

本发明提供一种开放鉴权应用程序接口OAuth代理的方法、装置及系统，通过代理OAuth提供商提供的资源，应用开发者可以重用已有的各种OAuth客户端库，而且应用只需要通过OAuth代理即可访问后面多种被代理的OAuth提供商提供的服务，而不需要在每个OAuth提供商上注册，简化了第三方应用的开发，同时本方案通过两次重定向的机制解决了在客户端授权阶段被授权应用(即OAuth代理)与客户端实际使用的应用(即第三方应用)不一致导致客户端困惑的问题，提高了客户端的体验。

Description

一种开放鉴权应用程序接口代理的方法、装置及系统

技术领域

本发明涉及计算机通信技术领域，特别涉及一种开放鉴权应用程序接口代理的方法、装置及系统。

背景技术

开放鉴权应用程序接口(OAuth，An open protocol to allow secure APIauthorization in a simple and standard method from desktop and web applications)标准作为目前业界最为流行的第三方应用程序接口(API)鉴权授权访问协议已在互联网上广泛使用，该OAuth标准能够让客户端在不暴露客户端密钥的情况下将客户端在某个服务提供商保存的隐私信息暴露给第三方应用，例如新浪sina微博，豆瓣，google等均基于OAuth标准发布了各种应用程序接口API，极大的丰富了互联网的开放环境，基于OAuth的代理需求也随之显现出来。

现有技术中，OAuth消费者(OAuth consumer)先在OAuth服务提供商(OAuth provider)上注册自己的应用信息，被授权后，可以直接与OAuth服务提供商进行交互，获取需要客户端授权的隐私信息。但是，在实际应用中，很可能OAuth consumer无法直接和OAuth provider进行交互，需要代理才能访问OAuth provider上保存的资源，例如互联网上众多的短信批发商和彩信批发商，作为短信API的代理接收第三方应用的请求，并将请求转发给运营商的短信网关。

在对现有技术的研究和实践过程中，本发明的发明人发现，现有的实现方式中，客户端在访问多种服务提供商提供的服务时，需要在每个OAuthprovider上注册自己的应用信息，实现比较复杂；同时，客户端授权时，被授权的第三方应用和授权页面上展示的应用名称可能不一致，从而导致客户端混淆的问题。

发明内容

本发明实施例提供一种开放鉴权应用程序接口代理的方法、装置及系统，以简化客户端访问服务提供商提供的服务，以及被授权的第三方应用和授权页面上展示的应用名称可能不一致的技术问题。

为解决上述技术问题，本发明实施例提供一种开放鉴权应用程序接口OAuth代理的方法，包括：

接收第三方应用发送的获取请求令牌的请求消息；

根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；

向所述第三方应用发送包括请求令牌的响应消息；

接收所述第三方应用发送的获取访问令牌的请求消息；

根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；

向所述第三方应用发送包括访问令牌的响应消息；

接收第三方应用发送的客户端资源访问请求；

根据所述访问令牌对所述客户端资源访问请求进行签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；

接收所述OAuth提供商发送的客户端资源访问响应；

将所述客户端资源访问响应发送给第三方应用。

相应的，本发明实施例提供一种开放鉴权应用程序接口OAuth代理装置，包括：

第一接收单元，用于接收第三方应用发送的获取请求令牌的请求消息；

第一查询单元，用于根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的消费者密钥对及其请求令牌统一资源定位符；

第一获取单元，用于利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；

第一发送单元，用于向所述第三方应用发送包括请求令牌的响应消息；

第二接收单元，用于接收所述第三方应用发送的获取访问令牌的请求消息；

第二查询单元，用于根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的安全密钥钥对及其请求令牌统一资源定位符；

第二获取单元，用于利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；

第二发送单元，用于向所述第三方应用发送包括访问令牌的响应消息；

第三接收单元，用于接收第三方应用发送的客户端资源访问请求；

资源请求单元，用于根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；

资源接收单元，用于接收所述OAuth提供商的发送的客户端资源访问响应；

第三发送单元，用于向第三方应用发送所述客户端资源访问响应。

本发明实施例还提供一种开放鉴权应用程序接口OAuth代理系统，包括：第三方应用、OAuth代理装置和OAuth提供商，其中，

所述第三方应用，用于将接收到客户端发送的获取请求令牌的请求消息转发给所述OAuth代理装置；接收所述OAuth代理装置发送的包括请求令牌的响应消息；以及将接收到客户端发送的获取访问令牌的请求消息转发给OAuth代理装置；接收所述OAuth代理装置发送的包括访问令牌的响应消息；以及，向所述OAuth代理装置发送客户端资源访问请求；接收所述OAuth代理装置发送的客户端资源访问响应；

所述OAuth代理装置，用于接收客户端通过第三方应用发送的获取请求令牌的请求消息；根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；向所述第三方应用发送包括请求令牌的响应消息；接收所述第三方应用发送的获取访问令牌的请求消息；根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；向所述第三方应用发送包括访问令牌的响应消息；接收第三方应用发送的客户端资源访问请求；根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；接收所述OAuth提供商的发送的客户端资源访问响应，并将所述客户端资源访问响应发送给第三方应用。

由上述技术方案可知，本发明实施例中，通过代理OAuth provider提供的资源，由于代理暴露的接口也遵循OAuth1.0a标准，应用开发者可以重用已有的各种OAuth客户端库，而且应用只需要通过OAuth代理即可访问后面多种被代理的OAuth provider提供的服务，而不需要在每个OAuth provider上注册，简化了第三方应用的开发，同时本方案通过两次重定向的机制解决了在客户端授权阶段被授权应用(OAuth代理)与客户端实际使用应用(第三方应用)不一致导致客户端困惑的问题，提高了客户端的体验。

附图说明

图1为本发明实施例提供的一种开放鉴权应用程序接口代理的方法的流程图；

图2为本发明实施例提供的一种开放鉴权应用程序接口代理装置的结构示意图；

图3为本发明实施例提供的一种开放鉴权应用程序接口代理装置的另一结构示意图；

图4为本发明实施例提供的一种开放鉴权应用程序接口代理系统的结构示意图；

图5为本发明实施例提供的第一实施例的流程图；

图6为本发明实施例提供的第二实施例的流程图。

具体实施方式

本发明实施例主要提供一种开放的鉴权应用程序接口(OAuth，An openprotocol to allow secure API authorization in a simple and standard method fromdesktop and web applications)代理的方法、装置以及OAuth代理，在这种代理机制下，只需通过OAuth代理提供的安全密钥对(消费密者钥键consumer key，消费者密钥consumer secret)，对于第三方应用即可访问OAuth代理后的各种OAuth提供商(OAuth provider)提供的资源，而不需要在每个OAuth provider上注册自己的应用信息，简化了第三方应用的开发的技术问题。同时，本发明实施例提供的代理机制暴露出去的接口仍然是满足OAuth标准规范的，从而保证了已有的各种OAuth客户端数据库可以被重用，也提供了开发者友好性。

进一步，本发明实施例还解决了在OAuth代理模式下，对于OAuthprovider，OAuth代理才是OAuth的消费者(OAuth consumer)，客户端授权时，被授权的第三方应用和授权页面上展示的应用名称不一致导致客户端混淆的情况，提高了客户端的体验度。

为了使本技术领域的人员更好地理解本发明实施例的方案，下面结合附图和实施方式对本发明实施例作进一步的详细说明。

请参阅图1，为本发明实施例提供的一种开放鉴权应用程序接口代理的方法的流程图。在该实施例中，代理OAuth provider的多种应用，并对外提供OAuth1.oa标准的服务。在该实例中，客户端需要先在OAuth代理注册，也就是说，该客户端为OAuth代理的注册客户端。所述方法包括：

步骤101：接收客户端通过第三方应用发送的获取请求令牌的请求消息；

客户端访问第三方应用，并触发应用需要访问客户端在某个OAuth提供商上存储的客户端隐私数据，第三方应用向OAuth代理(OAuth proxy)发送获取请求令牌的请求消息。

步骤102：根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

步骤103：利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；

也就是说，OAuth代理根据所述OAuth提供商发布的安全密钥(比如消费者密钥键、消费者密钥)对所述获取请求令牌的请求消息进行重新签名；将重新签名后的获取请求令牌的请求消息发送给OAuth提供商；接收所述OAuth提供商发送的包括请求令牌的响应消息；存储所述请求令牌与所述第三方应用和OAuth提供商的映射关系。

其中，一种重新签名方式是：OAuth代理可以根据所述OAuth提供商发布的安全密钥(消费者密钥键consumer key，消费者密钥consumer secret)对所述请求消息进行重新签名，之后，将重新签名的后请求消息发送给OAuth提供商，以请求获取请求令牌；以及OAuth代理接收到OAuth提供商反馈的包括请求令牌的响应消息。

之后，OAuth代理存储接收到的所述请求令牌，与第三方应用和OAuth提供商之间的映射关系，所述请求令牌包括：密钥键和密钥，但并不限于此

步骤104：向所述第三方应用发送包括请求令牌的响应消息；

该步骤以便于所述第三方应用根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面或OAuth提供商提供的客户端统一资源定位符上；

在该实施例中，第三方应用在接收到包括请求令牌的响应消息后，可以根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面上；或者将客户端重定向到OAuth提供商提供的客户端统一资源定位符上。本实施例以重定向OAuth提供商提供的客户端统一资源定位符为例进行说明。

也就是说，OAuth代理将获取到的所述请求令牌发送给第三方应用，第三方应用在接收到所述请求令牌后，将客户端重定向OAuth代理提供的指示页面上，或者将客户端直接重定向到OAuth提供商提供的客户端授权页面上。

步骤105：接收所述第三方应用发送的获取访问令牌的请求消息；

其中，所述请求消息可以包括：消费者密钥键和请求令牌键；但并不限于此。

步骤106：根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

也就是说，OAuth代理根据所述获取访问令牌的请求消息中的消费者密钥键和请求令牌键查找到对应的OAuth提供商和访问令牌统一资源定位符。

步骤107：利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；

一种具体的实施方式为：OAuth代理根据所述OAuth提供商为Oauth代理布发布的安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名；将重新签名后的获取访问令牌的请求消息发送给所述OAuth提供商；接收所述OAuth提供商发送的包括访问令牌的响应消息；存储所述访问令牌与所述第三方应用和OAuth提供商的映射关系。

步骤108：向所述第三方应用发送包括访问令牌的响应消息；

步骤109：接收第三方应用发送的客户端资源访问请求；

步骤110：根据所述访问令牌对所述客户端资源访问请求进行签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；

在接收第三方应用发送的客户端资源访问请求后，OAuth代理根据所述OAuth提供商提供的安全密钥(比如消费者密钥键、消费者密钥)和访问令牌对所述客户端资源访问请求进行重新签名后，向所述OAuth提供商的应用程序接口终端发起客户端资源访问请求。

步骤111：接收所述OAuth提供商发送的客户端资源访问响应；

步骤112：将所述客户端资源访问响应发送给第三方应用。

在上述实施例中，所述方法还可以包括：

所述第三方应用在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth提供商提供的客户端统一资源定位符上进行鉴权和授权操作；

在客户端授权成功后，所述OAuth提供商将所述客户端重定向到第三方应用的页面上，所述第三方应用向OAuth代理发起获取访问令牌的请求消息。

优选的，在上述实施例中，所述方法还可以包括：

所述第三方应用在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面上进行指示操作；

所述OAuth代理根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息；

所述OAuth代理向客户端展示所述第三方应用需要通过该OAuth代理向OAuth提供商访问的客户端隐私数据，并提示客户端是否允许访问所述客户端隐私数据；

所述OAuth代理在接收到客户端允许访问所述客户端隐私数据的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作；之后执行步骤接收所述第三方应用发送的获取访问令牌的请求消息。

也就是说，OAuth代理向所述第三方应用发送获取请求令牌的响应消息，以使所述第三方应用根据所述请求令牌将客户端重定向到OAuth代理或OAuth提供商提供的客户端统一资源定位符上。

OAuth代理将获取到的所述请求令牌发送给第三方应用，第三方应用在接收到所述请求令牌后，将客户端重定向OAuth代理提供的客户端授权页面上，或者将客户端直接重定向到OAuth提供商提供的客户端授权页面上。

在该实施例中，如果第三方应用直接将客户端重定向到OAuth提供商提供的客户端授权页面上，客户端就可以通过客户端名、密码等对中方式进行鉴权，登陆到OAuth提供商的客户端授权页面上，登陆成功后进行授权操作。

如果第三方应用将客户端重定向OAuth代理提供的指示页面上，OAuth代理接收客户端发送的客户端授权请求，所述客户端授权请求包括请求令牌；根据所述请求令牌查询到对应的第三方应用信息和被访问的OAuth提供商信息；OAuth代理向客户端展示所述第三方应用需要通过OAuth代理向OAuth提供商访问的客户端隐私数据，并提示客户端是否允许访问所述客户端隐私数据；以及在接收到客户端允许访问所述客户端隐私数据的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作。

本发明实施例提供的一种OAuth代理的方法，通过代理OAuth provider提供的资源，由于代理暴露的接口也遵循OAuth1.0a标准，应用开发者可以重用已有的各种OAuth客户端库，而且应用只需要通过OAuth代理即可访问后面多种被代理的OAuth provider提供的服务，而不需要在每个OAuth provider上注册，简化了第三方应用的开发，同时本方案通过两次重定向的机制解决了在客户端授权阶段被授权应用(OAuth代理)与客户端实际使用应用(第三方应用)不一致导致客户端困惑的问题，提高了客户端的体验。

相应的，本发明实施例还提供一种开放鉴权应用程序接口OAuth代理装置，其结构示意图如图2所示，所述OAuth代理装置包括：第一接收单元21，第一查询单元22，第一获取单元23，第一发送单元24，第二接收单元25，第二查询单元26，第二获取单元27，第二发送单元28，第三接收单元29，资源请求单元30，资源接收单元31，第三发送单元32，其中，

所述第一接收单元21，用于接收客户端通过第三方应用发送的获取请求令牌的请求消息；第一查询单元22，用于根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的消费者密钥对及其请求令牌统一资源定位符，所述第一获取单元23，用于利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从与所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；所述第一发送单元24，用于向所述第三方应用发送包括请求令牌的响应消息；所述第二接收单元25，用于接收所述第三方应用发送的获取访问令牌的请求消息；第二查询单元26，用于根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的安全密钥钥对及其请求令牌统一资源定位符；所述第二获取单元27，用于利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从与所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；所述第二发送单元28，用于向所述第三方应用发送包括访问令牌的响应消息；所述第三接收单元29，用于接收第三方应用发送的客户端资源访问请求；所述资源请求单元30，用于根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向与所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；所述资源接收单元31，用于接收所述OAuth提供商的发送的客户端资源访问响应；所述第三发送单元32，用于向第三方应用发送所述客户端资源访问响应。

在上述实施例中，所述第一获取单元可以包括：第一重签名单元，请求令牌发送单元，请求令牌接收单元和第一存储单元，其中，

所述第一重签名单元，用于利用所述OAuth提供商为Oauth代理发布的安全密钥对所述获取请求令牌的请求消息进行重新签名；所述请求令牌发送单元，用于将重新签名后的获取请求令牌的请求消息发送给OAuth提供商；所述请求令牌接收单元，用于接收所述OAuth提供商发送的包括请求令牌的响应消息；所述第一存储单元，用于存储所述请求令牌与所述第三方应用和OAuth提供商的映射关系。

在上述实施例中，所述第二获取单元可以包括：第二重新签名单元，第二重新签名单元，访问令牌发送单元，访问令牌接收单元和第二存储单元，其中，

所述第二重新签名单元，用于根据所述OAuth提供商发布的安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名；所述访问令牌发送单元，用于将重新签名后的获取访问令牌的请求消息发送给所述OAuth提供商；所述访问令牌接收单元，用于接收所述OAuth提供商发送的包括访问令牌的响应消息；所述第二存储单元，用于存储所述访问令牌与所述第三方应用和OAuth提供商的映射关系。

在上述实施例中，所述资源请求单元包括：第三重新签名单元和第四发送单元，其中，所述第三重新签名单元，具体用于根据所述OAuth提供商提供的安全密钥和访问令牌对所述客户端资源访问请求进行重新签名；所述第四发送单元，用于将第三重新签名单元重新签名后的客户端资源访问请求发送给对应的所述OAuth提供商。

优选的，如果第三方应用在接收到包括请求令牌的响应消息时，将客户端重定向到所述OAuth代理装置提供的指示页面上，所述装置还包括：第三查询单元，展示单元，提示单元，确认信息接收单元和重定向单元，其中，

所述第三查询单元，与第一发送单元连接，用于根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息；所述展示单元，用于向客户端展示所述第三方应用需要通过该OAuth代理向OAuth提供商访问的客户端隐私数据；所述提示单元，用于在所述展示单元展示客户端隐私数据后，提示客户端是否允许访问所述客户端隐私数据；所述确认信息接收单元，用于在接收到客户端允许访问所述客户端隐私数据的确认信息；所述重定向单元，与第二接收单元连接，用于在确认信息接收单元接收到客户端的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作。

优选的，所述OAuth代理装置可以集成在业务路由器中，也可以独立部署，本实施例不作限制。

相应的，本发明实施例还提供一种开放鉴权应用程序接口OAuth代理装置，及其结构示意图如图3所示，所述OAuth代理包括：请求令牌获取端点(Get RequestToken Endpoint)311，客户端授权端点(User AuthorizationEndpoint)321，访问令牌端点(GetAccessToken Endpoint)331和应用程序接口代理(OAuth API proxy)341，其中，

所述请求令牌获取端点311，用于接收第三方应用发送的获取请求令牌的请求消息，根据所述获取请求令牌的请求消息选择对应的OAuth提供商，并根据OAuth代理在所述OAuth提供商上所拥有的消费者密钥键和消费者密钥对所述获取请求令牌的请求消息进行重新签名后，向OAuth提供商发起重新签名后的获取请求令牌的请求消息，并在接收到所述OAuth提供商发送的获取请求令牌的响应消息后，存储所述请求令牌、第三方应用及OAuth提供商之间的映射关系，以及向所述第三方应用发送获取请求令牌响应消息；

也就是说，所述请求令牌获取端点311：用于满足第三方应用RequestToken请求，对接收到请求令牌的请求进行验证，并在验证成功后选择合适的OAuth提供商，并根据OAuth proxy在此OAuth provider上所拥有的consumerkey和consumer secret对请求消息进行重新签名后，向OAuth provider发起Get RequestToken请求，将收到包括请求令牌Request Token的响应消息后，存储请求令牌。第三方应用及OAuth提供商之间的映射关系，并将包括请求令牌的响应消息返回给第三方应用。

所述客户端授权端点321，用于在将接收到客户端的鉴权和授权请求消息时，根据所述请求消息中的请求令牌查询到对应的第三方应用信息和被访问的OAuth提供商信息，并告知客户端，所述第三方应用需要通过本OAuth代理装置去访问OAuth提供商上的客户端隐私数据，并为客户端提供确认按钮，以及在客户端确认后，将客户端重定向到OAuth提供商提供的客户端授权页面上；

也就是说，客户端授权端点321用于满足客户端的鉴权和授权请求，该客户端授权端点直接和客户端交互，主要为了防止客户端在OAuth provider上进行真实的登陆授权时引起混淆和误解，该客户端授权端点根据请求消息中的request token查询到对应的第三方应用信息和被访问的OAuth provider信息，根据这些信息展示给客户端告知客户端第三方应用需要通过本OAuthproxy平台去访问OAuth provider上的客户端信息，并最终返回重定向响应，将客户端重定向到OAuth provider提供的User Authorization页面上。其中，在该过程中，可选的是的，，客户端授权端点321可以提供确认按钮，让客户端确认，如果客户端同意，再将客户端重定向到OAuth provider提供的UserAuthorization页面上。

所述访问令牌端点331，用于在接收到第三方应用的获取访问令牌的请求消息，根据所述获取访问令牌的请求消息中的请求令牌找到对应的OAuth提供商，并根据本身在OAuth提供商上拥有的消费者密钥键和消费者密钥对所述获取访问令牌的请求消息进行重新签名后，向发起OAuth提供商发起重新签名后的获取访问令牌的请求消息，接收所述OAuth提供商反馈的获取访问令牌的响应消息，并存储获取的访问令牌、第三方应用及OAuth提供商的映射关系，以及并将获取的访问令牌返回给所述第三方应用；

也就是说，访问令牌端点331满足第三方应用的GetAccessToken请求，接收请求并且验证成功后，会根据请求消息中的RequestToken信息找到合适的OAuth provider，并根据本身在OAuth provider上拥有的consumer key和consumer secret等信息对消息进行重新签名后发起Get AccessToken请求，并再接收到OAuth provider反馈的包括access token的响应后，保存响应消息中的access token、第三方应用及OAuth provider之间的映射关系，并将包括access token的响应返回给请求者，即第三方应用。

所述应用程序接口代理341，用于接收所述第三方应用发送的包括访问令牌的资源访问请求，根据其在所述OAuth提供商上所拥有的消费者密钥键、消费者密钥和访问令牌对所述客户端资源访问请求进行重新签名后，向所述OAuth提供商的应用程序接口终端发起重新签名后的客户端资源访问请求，并在接收OAuth提供商的应用程序接口终端发送的客户端资源访问响应后，向所述第三方应用发送所述客户端资源访问响应。

也就是说，应用程序接口代理341接收第三方应用发送的资源访问请求，并对所述资源访问请求进行合适处理后，对OAuth provider发起真实的资源访问请求并将响应路由给请求者，即第三方应用。

优选的，所述OAuth代理装置可以集成在业务路由器中，也可独立部署，本实施例不作限制。

相应的，本发明还提供一种开放鉴权应用程序接口OAuth代理系统，其结构如图4所示，所述OAuth系统包括：第三方应用41、OAuth代理装置42和OAuth提供商43。其中，

所述第三方应用41，用于将接收到客户端发送的获取请求令牌的请求消息转发给所述OAuth代理装置；接收所述OAuth代理装置发送的包括请求令牌的响应消息；以及将接收到客户端发送的获取访问令牌的请求消息转发给OAuth代理装置；接收所述OAuth代理装置发送的包括访问令牌的响应消息；以及，向所述OAuth代理装置发送客户端资源访问请求；接收所述OAuth代理装置发送的客户端资源访问响应；

所述OAuth代理装置42，用于接收客户端通过第三方应用发送的获取请求令牌的请求消息；根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；向所述第三方应用发送包括请求令牌的响应消息；接收所述第三方应用发送的获取访问令牌的请求消息；根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从与所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；向所述第三方应用发送包括访问令牌的响应消息；接收第三方应用发送的客户端资源访问请求；根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向与所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；接收所述OAuth提供商的发送的客户端资源访问响应，并将所述客户端资源访问响应发送给第三方应用。

在该实施例中，所述OAuth代理装置中包括的各个单元的详见上述对应实施例中的描述，在此不再赘述。

优选的，所述第三方应用，还用于在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth提供商提供的客户端统一资源定位符上进行鉴权和授权操作；在客户端授权成功后，所述OAuth提供商将所述客户端重定向到第三方应用的页面上，所述第三方应用向OAuth代理发起获取访问令牌的请求消息。

优选的，所述第三方应用，还用于在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面上进行指示操作；

所述OAuth代理，还用于根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息，并向客户端展示所述第三方应用需要通过该OAuth代理向OAuth提供商访问的客户端隐私数据，并提示客户端是否允许访问所述客户端隐私数据；以及在接收到客户端允许访问所述客户端隐私数据的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作；并接收所述第三方应用发送的获取访问令牌的请求消息。

本发明实施例提供的一种OAuth代理的方法，通过代理OAuth provider提供的资源，由于代理暴露的接口也遵循OAuth1.0a标准，应用开发者可以重用已有的各种OAuth客户端库，而且应用只需要通过OAuth代理即可访问后面多种被代理的OAuth provider提供的服务，而不需要在每个OAuth provider上注册，简化了第三方应用的开发，同时本方案通过两次重定向的机制解决了在客户端授权阶段被授权应用(OAuth代理)与客户端实际使用应用(第三方应用)不一致导致客户端困惑的问题，提高了客户端的体验。

为了便于本领域技术人员的理解，下面依据图的实例来说明。

请参阅图5，为本发明提供的第一实施例的流程图。在该实施例中，主要说明OAuth proxy为OAuth消息代理的具体流程，包括的实体为：客户端(Useragent)、第三方应用(3th APP)、OAuth代理(OAuth proxy)、proxy提供商(OAuth provider)，其具体过程包括：

步骤501：客户端访问第三方应用(Access app)，并且触发应用需要访问客户端在某个OAuth提供商(OAuth provider)上存储的客户端隐私数据；

步骤502：第三方应用向OAuth代理(OAuth proxy)发送获取请求令牌的请求消息(Send request token request)；

步骤503：OAuth proxy向OAuth provider发起获取RequestToken请求，其中，所述获取RequestToken请求为利用OAuth提供商发布的安全密钥进行重新签名后的所述请求；

在该步骤中，OAuth proxy对该请求消息进行签名验证后，并根据请求消息的Oauth provider字段查询到合适的OAuth provider，以及根据所述OAuthprovider发布的安全密钥对所述请求消息进行重新签名后向OAuth provider发起获取RequestToken请求；

步骤504：OAuth proxy接收OAuth provider返回的包括RequestToken的响应消息；

步骤505：OAuth proxy保存RequestToken，以及及RequestToken与OAuthprovider，OAuth consumer之间的映射关系；

步骤506：OAuth proxy将Request Token返回给第三方应用；

步骤507：第三方应用将客户端(User Agent)重定向到OAuth proxy提供的指示页面上，或者将客户端(User Agent)直接重定向到OAuth provider提供的客户端授权(User Authorization)页面上，如果第三方应用将客户端重定向到OAuth provider提供的User Authorization页面，则跳转到步骤510；如果第三方应用将客户端重定向到OAuth proxy提供的指示页面上，执行步骤508；

步骤508：OAuth proxy根据请求消息中request token查询到对应的第三方应用和要被访问的OAuth provider等信息，展示相应的信息，该信息中至少包括第三方应用需要通过OAuth proxy去访问某个OAuth provider上的客户端隐私信息；进一步，在该步骤中，还可以为客户端提供确认按钮，以便于客户端进行确认，下述步骤可以是接收到客户端确认信息后执行的步骤，也可以直接执行该步骤。

步骤509：OAuth proxy将客户端(User Agent)重定向到OAuth provider上的客户端授权User Authorization页面上；

步骤510：客户端通过客户端名，密码或浏览器中的信息(cookie)等多种方式鉴权、登录OAuth provider的User Authorization页面，并在登录成功后进行授权操作；

步骤511：授权成功后，OAuth provider将客户端(User Agent)重定向到第三方应用的页面上；

步骤512：客户端被重定向到第三方应用的页面上，并携带有满足OAuth标准的OAuth验证客户端(OAuth_verifier)和OAuth_token等信息；

步骤513：第三方应用向OAuth proxy发起获取访问令牌(AccessToken)的请求；

步骤514：OAuth proxy验证请求并查询到合适的OAuth provider，并通过consumer key和consumer secret及request token对请求消息进行重新签名，并向OAuth provider发起获取AccessToken请求；

步骤515：OAuth proxy接收获取AccessToken响应消息；

步骤516：OAuth proxy保存该AccessToken及其与OAuth provider和第三方应用的映射关系；

步骤517：OAuth proxy将access token返回给第三方应用；

步骤518：OAuth proxy接收第三方应用发起的客户端资源访问请求；

步骤519：OAuth proxy根据其在OAuth provider上的consumer key和consumer secret及access token等信息对信息进行重新签名后，向OAuth provider发起客户端资源访问请求；

步骤520：OAuth proxy接收OAuth provider的应用程序接口终端发送的客户端资源访问响应；

步骤521：OAuth proxy将所述响应发送给第三方应用。

还请参阅图6，为本发明实施例提供第二应用实例的流程图，在本实施例中，Oauth代理包括业务目录和业务路由器，但并不限于此，并且，所述业务目录和业务路由器共享数据库；

其中，业务目录，用于为客户端提供注册，展示各种API信息，所述API信息为基于Oauth协议开放的API信息，业务目录保存Oauth Provider的相关信息，其中，Oauth Provider的相关信息包括Oauth1.0标准中的获取请求令牌统一资源标识符(Get RequestToken URL)，客户端授权统一资源标识符(UserAuthorization URL)和获取访问统一资源标识符(Get AccessToken URL)及Oauth provider为业务目录和业务路由器发布的consumer key和consumersecret，客户端签名并验证业务路由器发送的请求，第三方应用在业务目录上注册并获取业务目录发布的consumer key和consumer secret，同时第三方应用在业务目录上发现并订阅了某个Oauth provider提供的基于Oauth协议开放的API。

所述业务路由器，用于完成具体的API proxy功能，提供Oauth标准中定义的三个URL(Get RequestToken URL，User Authorization URL和GetAccessToken URL)endpoint，并对发送过来的请求消息进行实际的路由功能。

本实施例中，业务目录&业务路由器已在第三方Oauth provider上注册并且拥有其发布的consumer token(consumerkey 4sina，consumer secret 4sina)；

业务目录&业务路由器已存储Oauth provider所提供的三个Oauth URL地址(Get RequestToken URL，User Authorization URL和Get AccessToken URL)

第三方应用已在业务目录上注册，并获得业务目录&业务路由器发布的consumer token(consumerkey，consumersecret)。

在满足上述条件下，本实施例的具体流程包括：

步骤601：客户端访问第三方应用，并且触发应用需要访问客户端在某个oauth provider上存储的客户端隐私数据；

步骤602：第三方应用向业务路由器发起获取RequestToken请求；

其中，请求的格式为：其中，oauth_consumer_key为业务目录&业务路由器为应用发布的consumer key，sina为Oauth provider在业务目录上注册的域名标示符，oauth_callback为应用提供的回调地址，oauth_signature为通过consumerkey和consumer secret对请求消息进行签名后的签名值：

步骤603：业务路由器向Oauth provider发起Get RequestToken请求；

在该步骤中，业务路由器对请求消息进行验证成功后，根据请求消息中的Oauth provider字段，例如”sina”找到合适的Oauth provider，并利用Oauthprovider发布的consumer key(consumerkey4sina)和consumer secret对消息进行重新签名，然后向Oauth provider发起Get RequestToken请求，消息格式如下，Oauth provider字段不仅仅限定来源于path部分，也可能会来至http url的query字段，http head或http body体：

步骤604：业务路由器接收Oauth provider发送过来的响应消息；其中，消息格式如下：

oauth_token＝token1&oauth_token_secret＝secret1&oauth_callback_confirmed＝true//token1即为oauth provider返回的请求token值，secret1即为token1对应的密钥

步骤605：业务路由器记录下request token(token1，secret1)及其与第三方应用和oauth provider的映射关系；

步骤606：业务路由器将步骤604中接收到的响应消息返回给第三方应用；

步骤607：第三方应用将客户端(user agent)重定向到业务路由器的指示页面上；比如，

https://www.servicerouter.com/accounts/OAuthAuthorizeToken？oauth_token＝token1，或者

将客户端(User Agent)直接重定向到Oauth provider提供的UserAuthorization页面，比如，http://api.t.sina.com.cn/oauth/authorize？oauth_token＝token1上；

如果重定向到Oauth provider提供的User Authorization页面，则跳转到步骤610；如果重定向到业务路由器的指示页面，字则执行步骤608；

步骤608：业务路由器根据请求消息中oauth_token字段查询到对应的第三方应用和要被访问的Oauth provider等信息，展示相应的信息，即包括第三方应用需要通过业务路由器去访问某个oauth provider上的客户端隐私信息；进一步，还可以提供确认按钮让客户端进行确认；

步骤609：业务路由器将客户端(user agent)重定向到oauth provider的客户端授权页面上，比如：

http请求URL为http://api.t.sina.com.cn/oauth/authorize？oauth_token＝token1

步骤610：客户端通过客户端名，密码或cookie等多种方式鉴权、登录Oauthprovider的User Authorization页面，登录成功后进行授权操作；

步骤611：授权成功后，Oauth provider将客户端(User Agent)重定向到第三方应用的页面上，比如，http url地址为http://printer.example.com/ready？oauth_verifier＝hfdp7dh39dks988&oauth_token＝token1；

步骤612：客户端被重定向到第三方应用的页面上，并携带有满足oauth标准的oauth_verifier和oauth_token等信息；

步骤613：第三方应用向业务路由器发起获取AccessToken请求；

请求消息格式如下，其中oauth_signature为通过consumerkey和requesttoken进行共同签名后的值：

步骤614：业务路由器对请求消息进行重新签名后向该URL发起获取AccessToken请求；

在该步骤中，业务路由器通过签名对请求消息进行验证，验证成功后，根据token1及consumerkey查询到目的oauth provider的Get AccessToken URL及consumer key等信息，通过对请求消息进行重新签名后向该URL发起获取AccessToken请求，请求格式如下，其中consumerkey4sina为oauth provider为业务目录&业务路由器发布的consumer key，token1为步骤604中业务路由器接收到的request token：

步骤615：Oauth provider返回access token pair的响应消息；

其中，access token pair包括：accesstoken1，secrettoken1)，响应消息如oauth_token＝accesstoken1&oauth_token_secret＝secrettoken1；//accesstoken1即为访问令牌的值，secrettoken1为该访问令牌对应的密钥；

步骤616：业务路由器记录下该access token及其映射关系

步骤617：业务路由器将该access token返回给第三方应用

步骤618：业务路由器接收第三方应用发送的访问资源请求；消息格式如下，其中oauth_consumer_key为业务目录&业务路由器为第三方应用发布的consumer key，oauth_token为步骤615步中业务路由器接收到的oauth_token：

步骤619：业务路由器根据签名验证请求后，查询到业务目录&业务路由器在Oauth provider上的consumer key和consumer secret，并结合access token对消息进行重新签名后将消息发送给oauth provider的API endpoint；详细格式如下，其中oauth_consumer_key为oauth provider为业务目录&业务路由器发布的consumer key，：

步骤620：业务路由器接收所述OAuth提供商发送的客户端资源访问响应；

步骤621：业务路由器将所述客户端资源访问响应发送给第三方应用。

本发明实施例提供一种开放鉴权应用程序接口OAuth代理的方法、装置及系统，通过本方案能够通过代理Oauth provider提供的资源，由于代理暴露的接口也遵循Oauth1.0a标准，应用开发者可以重用已有的各种oauth客户端库，而且应用只需要通过oauth代理即可访问后面多种被代理的oauth provider提供的服务，而不需要在每个oauth provider上注册，简化了第三方应用的开发，同时本方案通过两次重定向的机制解决了在客户端授权阶段被授权应用(oauth代理)与客户端实际使用应用(第三方应用)不一致导致客户端困惑的问题，提高了客户端的体验。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (16)

1.一种开放鉴权应用程序接口OAuth代理的方法，其特征在于，包括：

接收第三方应用发送的获取请求令牌的请求消息；

根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；

向所述第三方应用发送包括请求令牌的响应消息；

接收所述第三方应用发送的获取访问令牌的请求消息；

根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；

利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；

向所述第三方应用发送包括访问令牌的响应消息；

接收第三方应用发送的客户端资源访问请求；

根据所述访问令牌对所述客户端资源访问请求进行签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；

接收所述OAuth提供商发送的客户端资源访问响应；

将所述客户端资源访问响应发送给第三方应用。

2.根据权利要求1所述的方法，其特征在于，所述利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌，具体包括：

根据所述OAuth提供商为Oauth代理发布的发布的安全密钥对所述获取请求令牌的请求消息进行重新签名；

将重新签名后的获取请求令牌的请求消息发送给OAuth提供商；

接收所述OAuth提供商发送的包括请求令牌的响应消息； 

存储所述请求令牌与所述第三方应用和OAuth提供商的映射关系。

3.根据权利要求2所述的方法，其特征在于，所述利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌，具体包括：

根据所述OAuth提供商为Oauth代理发布的安全密钥发布的安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名；

将重新签名后的获取访问令牌的请求消息发送给所述OAuth提供商；

接收所述OAuth提供商发送的包括访问令牌的响应消息；

存储所述访问令牌与所述第三方应用和OAuth提供商的映射关系。

4.根据权利要求3所述的方法，其特征在于，所述根据所述访问令牌对所述客户端资源访问请求进行重新签名的方式为：

根据所述OAuth提供商提供的安全密钥和访问令牌对所述客户端资源访问请求进行重新签名。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

所述第三方应用在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth提供商提供的客户端统一资源定位符上进行鉴权和授权操作；

在客户端授权成功后，所述OAuth提供商将所述客户端重定向到第三方应用的页面上，所述第三方应用向OAuth代理发起获取访问令牌的请求消息。

6.根据权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

所述第三方应用在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面上进行指示操作；

所述OAuth代理根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息；

所述OAuth代理向客户端展示所述第三方应用需要通过该OAuth代理向 OAuth提供商访问的客户端隐私数据，并提示客户端是否允许访问所述客户端隐私数据；

所述OAuth代理在接收到客户端允许访问所述客户端隐私数据的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作；之后执行步骤接收所述第三方应用发送的获取访问令牌的请求消息。

7.根据权利要求1至4任一项所述的方法，其特征在于，所述请求令牌包括：密钥键和密钥；所述安全密钥包括：消费者密钥键和消费者密钥。

8.一种开放鉴权应用程序接口OAuth代理装置，其特征在于，包括：

第一接收单元，用于接收第三方应用发送的获取请求令牌的请求消息；

第一查询单元，用于根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的消费者密钥对及其请求令牌统一资源定位符；

第一获取单元，用于利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；

第一发送单元，用于向所述第三方应用发送包括请求令牌的响应消息；

第二接收单元，用于接收所述第三方应用发送的获取访问令牌的请求消息；

第二查询单元，用于根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为oauth代理发布的安全密钥钥对及其请求令牌统一资源定位符；

第二获取单元，用于利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；

第二发送单元，用于向所述第三方应用发送包括访问令牌的响应消息；

第三接收单元，用于接收第三方应用发送的客户端资源访问请求； 

资源请求单元，用于根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；

资源接收单元，用于接收所述OAuth提供商的发送的客户端资源访问响应；

第三发送单元，用于向第三方应用发送所述客户端资源访问响应。

9.根据权利要求8所述的装置，其特征在于，所述第一获取单元包括：

第一重签名单元，用于利用所述OAuth提供商为Oauth代理发布的安全密钥对所述获取请求令牌的请求消息进行重新签名；

请求令牌发送单元，用于将重新签名后的获取请求令牌的请求消息发送给OAuth提供商；

请求令牌接收单元，用于接收所述OAuth提供商发送的包括请求令牌的响应消息；

第一存储单元，用于存储所述请求令牌与所述第三方应用和OAuth提供商的映射关系。

10.根据权利要求9所述的装置，其特征在于，所述第二获取单元包括：

第二重新签名单元，用于根据所述OAuth提供商为Oauth代理发布的安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名；

访问令牌发送单元，用于将重新签名后的获取访问令牌的请求消息发送给所述OAuth提供商；

访问令牌接收单元，用于接收所述OAuth提供商发送的包括访问令牌的响应消息；

第二存储单元，用于存储所述访问令牌与所述第三方应用和OAuth提供商的映射关系。

11.根据权利要求10所述的装置，其特征在于，所述资源请求单元包括：

第三重新签名单元，具体用于根据所述OAuth提供商提供的安全密钥和访问令牌对所述客户端资源访问请求进行重新签名； 

第四发送单元，用于将第三重新签名单元重新签名后的客户端资源访问请求发送给对应的所述OAuth提供商。

12.根据权利要求8至11任一项所述的装置，其特征在于，如果第三方应用在接收到包括请求令牌的响应消息时，将客户端重定向到所述OAuth代理装置提供的指示页面上，所述装置还包括：

第三查询单元，与第一发送单元连接，用于根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息；

展示单元，用于向客户端展示所述第三方应用需要通过该OAuth代理向OAuth提供商访问的客户端隐私数据；

提示单元，用于在所述展示单元展示客户端隐私数据后，提示客户端是否允许访问所述客户端隐私数据；

确认信息接收单元，用于在接收到客户端允许访问所述客户端隐私数据的确认信息；

重定向单元，与第二接收单元连接，用于在确认信息接收单元接收到客户端的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作。

13.根据权利要求8至11任一项所述的装置，其特征在于，所述OAuth代理装置集成在业务路由器中，或独立部署。

14.一种开放鉴权应用程序接口OAuth代理系统，其特征在于，包括：第三方应用、OAuth代理装置和OAuth提供商，其中，

所述第三方应用，用于将接收到客户端发送的获取请求令牌的请求消息转发给所述OAuth代理装置；接收所述OAuth代理装置发送的包括请求令牌的响应消息；以及将接收到客户端发送的获取访问令牌的请求消息转发给OAuth代理装置；接收所述OAuth代理装置发送的包括访问令牌的响应消息；以及，向所述OAuth代理装置发送客户端资源访问请求；接收所述OAuth代理装置发送的客户端资源访问响应； 

所述OAuth代理装置，用于接收客户端通过第三方应用发送的获取请求令牌的请求消息；根据所述请求令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥对所述获取请求令牌的请求消息进行签名后，从所述获取请求令牌的请求消息对应的请求令牌统一资源定位符上获取请求令牌；向所述第三方应用发送包括请求令牌的响应消息；接收所述第三方应用发送的获取访问令牌的请求消息；根据所述访问令牌的请求消息中的Oauth提供商字段查询到Oauth提供商为Oauth代理发布的安全密钥对及其请求令牌统一资源定位符；利用所述安全密钥和请求令牌对所述获取访问令牌的请求消息进行重新签名后，从所述获取访问令牌的请求消息对应的访问令牌统一资源定位符上获取访问令牌；向所述第三方应用发送包括访问令牌的响应消息；接收第三方应用发送的客户端资源访问请求；根据所述访问令牌对所述客户端资源访问请求进行重新签名后，向所述客户端资源访问请求对应的OAuth提供商发起客户端资源访问请求；接收所述OAuth提供商的发送的客户端资源访问响应，并将所述客户端资源访问响应发送给第三方应用。

15.根据权利要求14所述的系统，其特征在于，

所述第三方应用，还用于在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth提供商提供的客户端统一资源定位符上进行鉴权和授权操作；

在客户端授权成功后，所述OAuth提供商将所述客户端重定向到第三方应用的页面上，所述第三方应用向OAuth代理发起获取访问令牌的请求消息。

16.根据权利要求15所述的系统，其特征在于，

所述第三方应用，还用于在接收到包括请求令牌的响应消息时，根据所述请求令牌将客户端重定向到OAuth代理提供的指示页面上进行指示操作；

所述OAuth代理，还用于根据所述请求令牌查询对应的第三方应用信息和被访问的OAuth提供商信息，并向客户端展示所述第三方应用需要通过该OAuth代理向OAuth提供商访问的客户端隐私数据，并提示客户端是否允许 访问所述客户端隐私数据；以及在接收到客户端允许访问所述客户端隐私数据的确认信息后，将客户端重定向到OAuth提供商提供的统一资源定位符上，以便于客户端在所述OAuth提供商提供的客户端授权统一资源定位符上进行鉴权和授权操作；并接收所述第三方应用发送的获取访问令牌的请求消息。 

Images