CN102761537A

CN102761537A - 一种基于客户端插件的授权认证方法及系统

Info

Publication number: CN102761537A
Application number: CN2012100884412A
Authority: CN
Inventors: 东玮; 韩三普
Original assignee: Beijing Qihoo Technology Co Ltd; Qizhi Software Beijing Co Ltd
Current assignee: Beijing Qihoo Technology Co Ltd
Priority date: 2012-03-29
Filing date: 2012-03-29
Publication date: 2012-10-31
Anticipated expiration: 2032-03-29
Also published as: CN102761537B; CN104994064A; CN104994064B

Abstract

一种基于客户端插件的授权认证方法及系统，包括：通过平台A的客户端的插件，将平台B的标识信息提交给平台A的客户端，要求授权B使用A的服务；A的客户端授权后，将B的标识信息以及用户的身份标识信息提交给后端服务器，该后端服务器返回鉴权码给A的客户端；A的客户端通过客户端的插件将鉴权码传递给B，B获得当前用户身份，将鉴权码转换为访问令牌，返回生成的访问令牌给A的客户端的插件；通过客户端的插件，使用访问令牌调用B的接口。本发明解决了都提供同一OAuth协议认证授权的两平台，如何协作且对外提供服务的问题。

Description

一种基于客户端插件的授权认证方法及系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种基于客户端插件的授权认证方法及系统。

背景技术

在互联网时代，某些平台会将自身的服务封装为接口，供第三方开发者使用。这些平台我们一般称为开放平台。第三方开发者通过调用开放平台提供的接口，可以很方便的导入用户信息、提供充值等服务，为第三方开发者节约了大量的开发与运营成本。

对开放平台来说，因为要将用户信息提供给第三方开发者，这就涉及到用户的认证与授权。由此，OAuth认证授权协议应运而生。一个典型的OAuth应用通常包括三种角色，分别是：Consumer：消费方、Service Provider：服务提供者和User：用户。举例如下：一个SNS具有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的消费方就是SNS，而服务提供者则是Google，用户为SNS使用者。

到目前为止，OAuth协议有两个版本被大家广泛使用，分别为OAuth1.0a与OAuth2.0。在OAuth1.0a中，应用方需要预先申请一个Request Token(请求令牌)，在用户授权后，应用可以获得一个授权过的Request Token，在后端将此Request Token更换为Access Token(访问令牌)，此后均使用这个AccessToken调用开放平台的服务接口；在OAuth2.0中，应用方直接要求用户授权，在用户授权后，应用可以获得一个授权过的Auth Code(鉴权码)，在后端将此Auth Code更换为Access Token，此后均使用这个Access Token调用开放平台的服务接口。同时，由于OAuth2.0借助https协议，而OAuth1.0a没有使用https需要在每次信息传输时计算签名，使OAuth2.0协议实现远比OAuth1.0a容易，所以OAuth2.0目前使用非常广泛，基本上每个开放平台都提供了OAuth2.0的支持。

其中，OAuth1.0定义了三种角色：User、Service Provider、Consumer，如图1所示，下面介绍Oauth1.0a的流程：

1：消费方请求Request Token；

2：服务提供者授权Request Token；

3：消费方定向用户到服务提供者；

4：获得用户授权后，服务提供者定向用户到消费方；

5：消费方请求Access Token；

6：服务提供者授权Access Token；

7：消费方访问受保护的资源。

OAuth2.0则定义了四种角色：Resource Owner(资源所有者)：User、Resource Server(资源服务器)：Service Provider(服务提供者)、Client(客户端)：Consumer(消费方)、Authorization Server(鉴权服务器)：Service Provider。

OAuth2.0服务支持以下3种获取Access Token的方式：

A.Authorization Code：Web Server Flow(服务端流程)，适用于所有有Server端配合的应用；(方案A的具体流程如图2所示)

B.Implicit Grant(隐式授权)：User-Agent Flow(客户端流程)，适用于所有无Server端配合的应用；

C.Refresh Token(刷新令牌)：令牌刷新方式，适用于所有有Server端配合的应用。

目前，对于应用方只是单方面使用开放平台的服务，OAuth已经能够很好的解决这个问题了。但是，随着开放平台这一概念的普及，现在很多公司都会将自己的服务封装为接口，以开放平台的身份对外提供服务。这样就涉及到两个开放平台如何互相协作，对用户提供服务。

由此可见，目前标准的OAuth协议只能处理一个平台对一个应用的情况，对于应用方来说只是纯粹的使用开放平台提供的服务；不能支持两个开放平台共同协作、共同服务用户的情况。随着开放平台思想的普及，越来越多的公司会将自己的业务以开放平台的形式对外提供服务。此时应用方将不再单单使用开放平台提供的服务，应用自身也会是一个开放平台，也会对外提供服务。当用户需要同时使用两个开放平台提供的服务时，两个开放平台如何协作，是当前需要解决的问题。

发明内容

本发明所要解决的技术问题是提供一种基于客户端插件的授权认证方法及系统，解决了都提供同一OAuth协议认证授权的两个开放平台，如何协作且对外提供服务的问题。

为了解决上述问题，本发明提供了一种基于客户端插件的授权认证方法，其中开放平台A和开放平台B都支持同一OAuth协议，包括：

通过开放平台A的客户端的插件，将开放平台B的标识信息提交给开放平台A的客户端，要求用户授权开放平台B使用开放平台A上提供的服务；

开放平台A的客户端获得授权后，将开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器，该后端服务器返回鉴权码Auth Code给开放平台A的客户端；

开放平台A的客户端通过客户端的插件将Auth Code传递给开放平台B，开放平台B通过调用开放平台A接口获得当前用户身份，将Auth Code转换为访问令牌Access Token，开放平台B返回生成的Access Token给开放平台A的客户端的插件；

通过客户端的插件，使用Access Token调用开放平台B的相关接口。

进一步地，上述方法还可包括：所述开放平台A的客户端和客户端的插件是通过超文本传输安全协议https方式与开放平台A的后端服务器进行交互。

进一步地，上述方法还可包括：所述开放平台A的客户端将开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器后，还包括：所述开放平台A的客户端展示授权页的步骤。

进一步地，上述方法还可包括：所述开放平台B返回生成的Access Token给开放平台A的客户端的插件的步骤，还包括：

所述开放平台B通过调用开放平台A接口获得当前用户身份，查询当前用户身份与当前账号的绑定关系，如果两者未绑定，则在本地生成当前用户身份的本地账号，并记录绑定关系；开放平台B根据获得的本地账号直接生成Access Token，并返回给开放平台A的客户端的插件。

进一步地，上述方法还可包括：所述开放平台B通过调用开放平台A接口获得当前用户身份后，还包括：所述开放平台B展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的Access Token。

进一步地，上述方法还可包括：所述开放平台A的后端服务器存储所述用户的应用的应用密钥App Secret。

本发明还提供了一种基于客户端插件的授权认证系统，包括：开放平台A的客户端、开放平台A的客户端的插件、开放平台A的后端服务器和开放平台B，其中开放平台A和开放平台B都支持同一OAuth协议，

所述开放平台A的客户端的插件，用于将开放平台B的标识信息提交给开放平台A的客户端，要求用户授权开放平台B使用开放平台A上提供的服务；接收所述开放平台A的客户端发送的鉴权码Auth Code并传递给开放平台B；使用所述开放平台B返回的访问令牌Access Token调用开放平台B的相关接口；

所述开放平台A的客户端，用于将所述开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器；接收所述开放平台A的后端服务器返回的Auth Code，并传递给客户端的插件；

所述开放平台A的后端服务器，用于获得授权后，返回Auth Code给开放平台A的客户端；

所述开放平台B，用于通过调用开放平台A接口获得当前用户身份，将Auth Code转换为Access Token，返回生成的Access Token给开放平台A的客户端的插件。

进一步地，上述系统还可包括：开放平台A的客户端和客户端的插件是通过超文本传输安全协议https方式与开放平台A的后端服务器进行交互。

进一步地，上述系统还可包括：所述开放平台A的客户端，还用于将开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器后，展示授权页。

进一步地，上述系统还可包括：所述开放平台B，还用于通过调用开放平台A接口获得当前用户身份后，查询当前用户身份与当前账号的绑定关系，如果两者未绑定，则在本地生成当前用户身份的本地账号，并记录绑定关系，根据获得的本地账号直接生成Access Token。

进一步地，上述系统还可包括：所述开放平台B，进一步用于通过调用开放平台A接口获得当前用户身份后，展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的Access Token。

进一步地，上述系统还可包括：所述开放平台A的后端服务器还用于，存储用户的应用的应用密钥App Secret。

与现有技术相比，应用本发明，解决了在客户端程序上支持同一OAuth协议的两个开放平台如何协作的问题。通过本发明，两个开放平台可以通过客户端插件传递OAuth认证信息，传递过程没有信息的泄漏，用户体验良好，让用户能够在一个开放平台提供的客户端程序中平滑的使用另一个开放平台提供的服务，具有现实意义。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是当前一认证授权的流程示意图；

图2是当前另一认证授权的流程示意图；

图3是本发明的基于客户端插件的授权认证方法的流程示意图；

图4是本发明的基于客户端插件的授权认证系统的结构示意图；

图5是本发明实例中基于客户端插件的授权认证的流程中，各部件之间的交互连接示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的主要构思在于：在客户端程序上不保存应用的App Secret(应用密钥)，只在后端服务器存储App Secret，以防止客户端程序被破解造成AppSecret外泄；客户端、客户端插件调用后端服务器接口全部通过https，以防止请求被监听，造成关键信息泄漏；在开放平台间通过客户端的插件传递Auth Code而不是Access Token，一方面由于App Sercret没有保存在客户端，用户Auth Code换Access Token需要App Sercret；另一方面，由于这个AuthCode只能用一次，即使泄漏(如：客户端未校验https证书，可能会造成信息泄漏)，也不会产生安全性问题。在开放平台间不会直接传递用户信息，以防用户信息被恶意篡改，出现刷帐号的漏洞。

本解决方案为提高用户体验，支持为深度合作方提供跳过OAuth授权页的特殊流程。

如图3所示，本发明的一种基于客户端插件的授权认证方法，其中开放平台A和开放平台B都支持同一OAuth协议，包括以下步骤：

步骤310、通过开放平台A的客户端的插件，将开放平台B的标识信息提交给开放平台A的客户端，要求用户授权开放平台B使用开放平台A上提供的服务；

步骤320、得到授权后，开放平台A的客户端将开放平台B的标识信息，以及用户的身份标识信息提交给开放平台A的后端服务器，该后端服务器返回Auth Code给开放平台A的客户端；

所述开放平台A的客户端和客户端的插件是通过https(超文本传输安全协议)方式与开放平台A的后端服务器进行交互。

所述开放平台A的客户端将开放平台B的标识信息，以及用户的身份标识信息提交给开放平台A的后端服务器后，还可包括：所述开放平台A的客户端展示授权页的步骤。(当然该步骤为可选步骤，为提高用户体验，支持为深度合作方提供跳过OAuth授权页的特殊流程)

授权界面可以由开放平台A的客户端提供、也可由开放平台A的后端服务器提供(A的客户端包裹页面)；若由开放平台A的后端服务器提供，需要开放平台A的客户端将标识开放平台B的信息，以及标识用户身份的信息提交给开放平台A的后端服务器，以展示授权页。

步骤330、开放平台A的客户端通过客户端的插件将Auth Code传递给开放平台B，开放平台B通过调用开放平台A接口获得当前用户身份，将Auth Code转换为Access Token，开放平台B返回生成的Access Token给开放平台A的客户端的插件；

所述开放平台B返回生成的Access Token给开放平台A的客户端的插件的步骤，还包括：

所述开放平台B通过调用开放平台A接口获得当前用户身份后，还可包括：所述开放平台B展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的AccessToken。(当然该步骤为可选步骤，为提高用户体验，支持为深度合作方提供跳过OAuth授权页的特殊流程)

步骤340、通过客户端的插件，使用Access Token调用开放平台B的相关接口。

其中，所述开放平台A的客户端不保存用户的应用的App Secret，所述开放平台A的后端服务器存储用户的应用的App Secret，防止所述开放平台A的客户端被破解造成App Secret外泄。

如图4所示，一种基于客户端插件的授权认证系统，包括：开放平台A的客户端、开放平台A的客户端的插件、开放平台A的后端服务器和开放平台B，其中开放平台A和开放平台B都支持同一OAuth协议，

所述开放平台A的客户端的插件，用于将开放平台B的标识信息提交给开放平台A的客户端，要求用户授权开放平台B使用开放平台A上提供的服务；接收所述开放平台A的客户端发送的Auth Code并传递给开放平台B；使用所述开放平台B返回的Access Token调用开放平台B的相关接口；

所述开放平台A的客户端，用于将所述开放平台B的标识信息，以及用户的身份标识信息提交给开放平台A的后端服务器；接收所述开放平台A的后端服务器返回的Auth Code，并传递给客户端的插件；

所述开放平台A的客户端和客户端的插件是通过https方式与开放平台A的后端服务器进行交互。

所述开放平台A的客户端，还用于将开放平台B的标识信息，以及用户的身份标识信息提交给开放平台A的后端服务器后，展示授权页。

所述开放平台B，还用于通过调用开放平台A接口获得当前用户身份后后，查询当前用户身份与当前账号的绑定关系，如果两者未绑定，则在本地生成当前用户身份的本地账号，并记录绑定关系，根据获得的本地账号直接生成Access Token。

所述开放平台B，进一步用于通过调用开放平台A接口获得当前用户身份后，展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的Access Token。

所述开放平台A的后端服务器还用于，存储用户的应用的App Secret，防止所述开放平台A的客户端被破解造成App Secret外泄。

下面结合具体实例对本发明作进一步说明，如图5所示，基于客户端插件的授权认证的流程中，各部件之间的交互连接示意图，包括：

步骤1、打开开放平台A的客户端程序；

说明：客户端程序后端为开放平台A，用户在开放平台A上通过OAuth2.0协议登录授权操作都需要通过该客户端程序完成，下面的流程会详述如何完成登录授权操作。

步骤2、通过打开客户端的插件程序，以使用开放平台B提供的服务；

说明：该插件一般都是为让用户能够使用开放平台B上的服务而开发。当开放平台B也提供OAuth2.0认证授权时，即为本发明适用的应用场景。

步骤3、客户端插件将开放平台B的标识信息提交给客户端程序，要求用户授权开放平台B使用开放平台A上提供的服务；

说明：根据OAuth协议，开放平台A会给开放平台B分配一个身份标识，一般称为Client Id或App Key。当用户想要通过插件使用开放平台B的服务时，首先需要让开放平台B从放平台A上获得用户的身份。此时就需要将Client Id或App Key提交给客户端程序，要求用户授权开放平台B使用A上提供的服务(读取当前用户的信息)。

步骤4、客户端程序将开放平台B的标识信息，以及用户的身份标识信息提交给自身的后端服务器，展示授权页，用户同意授权后，同样将上一步的信息提交给后端，后端返回Auth Code给客户端程序；

说明：此步骤中，展示授权页为可选步骤。两个平台为深度合作或用户已经授权过平台B使用平台A的服务(读取当前用户的信息)，为提高用户体验，可以不展示授权页，直接返回Auth Code。

步骤5、客户端程序将Auth Code返回客户端插件；

步骤6、客户端插件将Auth Code传递给开放平台B；

说明：开放平台B上需要有专门接收平台A的Auth Code的接口

步骤7、开放平台B将Auth Code换为Access Token，通过调用开放平台A接口获得当前用户身份；

说明：本步骤提到的接口，均为OAuth2.0标准流程提到的接口

步骤8、开放平台B查询当前账号的绑定关系，如果未绑定，可以在本地生成账号，记录绑定关系；

步骤9、开放平台B直接返回Access Token给客户端插件；也可以展示授权页，在用户同意授权插件使用开放平台B的服务后返回Access Token给客户端插件；

说明：开放平台根据上一步获得的本地账号直接生成Access Token。

步骤10、使用客户端插件，客户端插件使用Access Token调用开放平台B的相关接口。

本说明书中的各个实施例一般采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块或单元。一般地，程序模块或单元可以包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。一般来说，程序模块或单元可以由软件、硬件或两者的结合来实现。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块或单元可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其主要思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种基于客户端插件的授权认证方法，其中开放平台A和开放平台B都支持同一OAuth协议，其特征在于，包括：

2.如权利要求1所述的方法，其特征在于，

所述开放平台A的客户端和客户端的插件是通过超文本传输安全协议https方式与开放平台A的后端服务器进行交互。

3.如权利要求1所述的方法，其特征在于，

所述开放平台A的客户端将开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器后，还包括：所述开放平台A的客户端展示授权页的步骤。

4.如权利要求1所述的方法，其特征在于，

5.如权利要求2所述的方法，其特征在于，

所述开放平台B通过调用开放平台A接口获得当前用户身份后，还包括：所述开放平台B展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的AccessToken。

6.如权利要求1所述的方法，其特征在于，

还包括：所述开放平台A的后端服务器存储所述用户的应用的应用密钥App Secret。

7.一种基于客户端插件的授权认证系统，其特征在于，包括：开放平台A的客户端、开放平台A的客户端的插件、开放平台A的后端服务器和开放平台B，其中开放平台A和开放平台B都支持同一OAuth协议，

8.如权利要求7所述的系统，其特征在于，所述开放平台A的客户端和客户端的插件是通过超文本传输安全协议https方式与开放平台A的后端服务器进行交互。

9.如权利要求7所述的系统，其特征在于，所述开放平台A的客户端，还用于将开放平台B的标识信息以及用户的身份标识信息提交给开放平台A的后端服务器后，展示授权页。

10.如权利要求7所述的系统，其特征在于，所述开放平台B，还用于通过调用开放平台A接口获得当前用户身份后，查询当前用户身份与当前账号的绑定关系，如果两者未绑定，则在本地生成当前用户身份的本地账号，并记录绑定关系，根据获得的本地账号直接生成Access Token。

11.如权利要求7所述的系统，其特征在于，所述开放平台B，进一步用于通过调用开放平台A接口获得当前用户身份后，展示授权页，用户同意授权开放平台A的客户端的插件使用开放平台B的服务后，向开放平台A的客户端的插件返回生成的Access Token。

12.如权利要求7所述的系统，其特征在于，所述开放平台A的后端服务器还用于，存储用户的应用的应用密钥App Secret。