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

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

【技术实现步骤摘要】

本专利技术涉及计算机
，尤其涉及一种基于客户端插件的授权认证方法及系统。
技术介绍
在互联网时代，某些平台会将自身的服务封装为接口，供第三方开发者使用。这些平台我们一般称为开放平台。第三方开发者通过调用开放平台提供的接口，可以很方便的导入用户信息、提供充值等服务，为第三方开发者节约了大量的开发与运营成本。对开放平台来说，因为要将用户信息提供给第三方开发者，这就涉及到用户的认证与授权。由此，OAuth认证授权协议应运而生。一个典型的OAuth应用通常包括三种角色，分别是:Consumer:消费方、Service Provider:服务提供者和User:用户。举例如下:一个SNS具有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的消费方就是SNS，而服务提供者则是Google，用户为SNS使用者。到目前为止，OAuth协议有两个版本被大家广泛使用，分别为OAuthl.0a与0Auth2.0。在OAuthl.0a中，应用方需要预先申请一个Request Token(请求令牌)，在用户授权后，应用可以获得一个授权过的Request Token，在后端将此Request Token更换为Access Token (访问令牌)，此后均使用这个Access Token调用开放平台的服务接口；在0Auth2.0中，应用方直接要求用户授权，在用户授权后，应用可以获得一个授权过的AuthCode (鉴权码)，在后端将此Auth Code更换为Access Token,此后均使用这个AccessToken调用开放平台的服务接口。同时，由于0Auth2.0借助https协议，而OAuthl.0a没有使用https需要在每次信息传输时计算签名，使0Auth2.0协议实现远比OAuthl.0a容易，所以0Auth2.0目前使用非常广泛，基本上每个开放平台都提供了 0Auth2.0的支持。其中，OAuthl.0 定义了三种角色:User、Service Provider、Consumer，如图1 所示，下面介绍Oauthl.0a的流程:1:消费方请求 Request Token ；2:服务提供者授权Request Token ；3:消费方定向用户到服务提供者；4:获得用户授权后，服务提供者定向用户到消费方；5:消费方请求 Access Token ；6:服务提供者授权Access Token ；7:消费方访问受保护的资源。0Auth2.0 则定义了四种角色:Resource Owner (资源所有者):User、ResourceServer (资源服务器)-Service Provider (服务提供者)、Client (客户端):Consumer (消费方)、Authorizat1n Server (鉴权服务器)-Service Provider。0Auth2.0服务支持以下3种获取Access Token的方式:A.Authorizat1n Code:ffeb Server Flow (服务端流程)，适用于所有有 Server端配合的应用；(方案A的具体流程如图2所示)B.1mplicit 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转换为访问令牌AccessToken，开放平台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的客户端，用于将所述当前第1本文档来自技高网...

【技术保护点】
一种基于客户端插件的授权认证方法，其中开放平台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的相关接口。

【技术特征摘要】

【专利技术属性】
技术研发人员：东玮，韩三普，
申请(专利权)人：北京奇虎科技有限公司，奇智软件北京有限公司，
类型：发明
国别省市：北京;11