对第三方应用进行鉴权的方法及系统的制作方法
【技术领域】
[0001]本申请涉及开放平台的第三方鉴权技术领域，特别是涉及对第三方应用进行鉴权的方法及系统。
【背景技术】
[0002]平台型互联网应用(例如，电子商务、应用交易平台等)为了给用户(例如，电子商务、应用交易平台中的卖方用户)提供更细分的服务，一般需要引入第三方开发者来完成。例如，对于电子商务交易平台而言，第三方开发者可以对点击量、跨店铺点击、订单流转量甚至相关即时通信工具中的聊天记录等信息进行收集和分析，最终提供给卖方用户直观的建议。也就是说，对于某互联网应用的用户而言，在该互联网应用的网页中浏览到的一些数据分析结果等信息，可以是由第三方App (应用程序)提供的。为了支持第三方应用实现上述功能中，电子商务交易平台一般需要提供一个开放平台，通过开放平台开放一些API(Applicat1n Programming Interface,应用程序编程接口)给第三方应用开发者,第三方App通过调用开放平台的API来获取一些数据，进而提供相应的分析等服务。
[0003]开放平台提供给第三方App的数据可能会涉及特定用户的私密数据，一般情况下，需要用户的授权才能获取到。但是，开放平台一般不允许第三方App拥有自己的登陆鉴权体系，必须使用开放平台的账号体系。现有的开放平台的授权体系一般使用使用0auth2.0协议。Oauth是业界的一个开放标准,用来允许用户通过第三方App,操作该用户在某一个网站上存储的私密的数据，而不需要第三方App获取该用户的用户名和密码。
[0004]随着业务的不断丰富和全面，对授权体系的安全性和严谨性也提出了不一样的要求。因为，可能有大量的用户几乎完全在第三方App上工作，他们要求能够在第三方App上更方便的完成几乎所有的操作。
[0005]但是，现有的授权体系中，开放平台仅在用户授权的时候对用户的身份进行校验，一旦登陆授权，用户浏览器跳转到第三方App页面，此时用户就已经离开开放平台，他的任何操作都是和第三方App打交道，而开放平台只接收第三方App的API请求。但是，开放平台只能识别第三方App的API请求，无法区分是否是用户自己在使用第三方App。而这一点，也是基于Oauth授权的开放平台安全性最薄弱的一环，即用户授权第三方App读写该用户在开放平台的数据，而当第三方App来读写该用户的数据的时候，开放平台不能区分是不是用户本人在使用，进而就无法开放安全需求更高的业务。例如:假设开放平台将同意退款业务开放成API,直接涉及到金钱的流动,如果使用现有的Oauth协议,会导致第三方App有机会恶意去帮助用户执行同意退款操作，而开放平台无法区分，这将会出现用户已经关闭了第三方App的页面的情况下，却发现有一笔交易的退款被同意了，这当然是不允许的。
[0006]因此，迫切需要本领域技术人员解决的技术问题就在于:如何完善开放平台的授权体系，使得开放平台能够区分第三方App的API请求是否为用户本人使用第三方App的情况下发出的，进而确定是否向第三方App开放敏感的数据，以保证用户数据的安全性。
【发明内容】
[0007]本申请提供了对第三方应用进行鉴权的方法及系统，可以提高用户数据的安全性。
[0008]本申请提供了如下方案:
[0009]一种对第三方应用进行鉴权的方法，所述第三方应用基于浏览器/服务器架构实现，所述第三方应用的页面中嵌入有预置的软件开发工具包SDK所述方法包括:
[0010]在对第三方应用进行授权、创建会话并向第三方应用颁发访问令牌之后，将所述访问令牌置为在线状态，并配置在线状态的有效时间；
[0011]在所述有效时间内监听该第三方应用所在浏览器发送的心跳包，如果监听到所述心跳包，则根据所述心跳包中携带的cookie信息对该心跳包的合法性进行判断，如果所述心跳包合法，则将所述在线状态的有效时间进行一次延长，其中，所述心跳包为在所述第三方应用获得用户授权，且第三方应用的页面被打开的状态下，由所述SDK驱动浏览器每隔预置时间发送的，所述心跳包中携带有预置域名下的cookie信息；
[0012]接收到第三方应用发送的携带有访问令牌的应用程序编程接口 API调用请求时，通过判断所述访问令牌当前是否处于在线状态，确定用户是否正在使用所述第三方应用，并根据判断结果响应所述API调用请求。
[0013]一种对第三方应用进行鉴权的方法，所述第三方应用基于客户端/服务器架构实现，所述第三方应用的客户端中嵌入有预置的SDK，所述方法包括:
[0014]在对第三方应用进行授权、创建会话并向第三方应用颁发访问令牌之后，将所述访问令牌置为在线状态，并配置在线状态的有效时间；
[0015]在所述有效时间内监听该第三方应用客户端发送的心跳包，如果监听到所述心跳包，则根据所述心跳包中携带的身份信息对该心跳包的合法性进行判断，如果所述心跳包合法，则将所述在线状态的有效时间进行一次延长；其中，所述心跳包为，在所述第三方应用获得用户授权，且第三方应用的客户端被打开的状态下，所述SDK驱动客户端每隔预置时间发送的，所述心跳包中携带有用户在所述开放平台中的身份信息；
[0016]接收到第三方应用的服务器端发送的携带有访问令牌的API调用请求时，通过判断所述访问令牌当前是否处于在线状态，确定用户是否正在使用所述第三方应用，并根据判断结果响应所述API调用请求。
[0017]一种对第三方应用进行鉴权的系统，所述第三方应用基于浏览器/服务器架构实现，所述第三方应用的页面中嵌入有预置的软件开发工具包SDK，所述系统包括:
[0018]第一令牌颁发单元，用于在对第三方应用进行授权、创建会话并向第三方应用颁发访问令牌之后，将所述访问令牌置为在线状态，并配置在线状态的有效时间；
[0019]第一令牌状态更新单元，用于在所述有效时间内监听该第三方应用所在浏览器发送的心跳包，如果监听到所述心跳包，则根据所述心跳包中携带的cookie信息对该心跳包的合法性进行判断，如果所述心跳包合法，则将所述在线状态的有效时间进行一次延长，其中所述心跳包为，在所述第三方应用获得用户授权，且第三方应用的页面被打开的状态下，所述SDK驱动浏览器每隔预置时间发送的，所述心跳包中携带有预置域名下的cookie信息；
[0020]第一调用请求响应单元，用于接收到第三方应用发送的携带有访问令牌的应用程序编程接口 API调用请求时，通过判断所述访问令牌当前是否处于在线状态，确定用户是否正在使用所述第三方应用，并根据判断结果响应所述API调用请求。
[0021]一种对第三方应用进行鉴权的系统，所述第三方应用基于客户端/服务器架构实现，所述第三方应用的客户端中嵌入有预置的SDK，所述系统包括:
[0022]第二令牌颁发单元，用于在对第三方应用进行授权、创建会话并向第三方应用颁发访问令牌之后，将所述访问令牌置为在线状态，并配置在线状态的有效时间；
[0023]第二令牌状态更新单元，用于在所述有效时间内监听该第三方应用客户端发送的心跳包，如果监听到所述心跳包，则根据所述心跳包中携带的身份信息对该心跳包的合法性进行判断，如果所述心跳包合法，则将所述在线状态的有效时间进行一次延长，其中，所述心跳包为，在所述第三方应用获得用户授权，且第三方应用的客户端被打开的状态下，所述SDK驱动客户端每隔预置时间发送一次心跳包，所述心跳包中携带有用户的身份信息；
[0024]第二调用请求响应单元，用于接收到第三方应用的服务器端发送的携带有访问令牌的API调用请求时，通过判断所述访问令牌当前是否处于在线状态，确定用户是否正在使用所述第三方应用，并根据判断结果响应所述API调用请求。
[0025]根据本申请提供的具体实施例，本申请公开了以下技术效果:
[0026]通过本申请实施例，通过在第三方App的页面中嵌入有开放平台提供的SDK，可以使得只要在第三方App的页面打开的状态下，SDK就驱动浏览器每隔预置时间向开放平台侧发送一次心跳包，并在心跳包中携带开放平台网站所属域名下的cookie信息；开放平台每次收到心跳包之后，可以对合法性进行验证，如果验证，则可以将对应会话的token有效期进行一次延长，并将token置为在线状态，以示第三方App的页面当前正处于打开的状态。这样，在收到第三方App的服务器发送的API调用请求时，就可以首先从中提取token，并判断是否处于在线状态，如果是，则可以允许该第三方App调用只有在在线状态下才能调用的API，返回相应的用户数据。否则，如果第三方App发送的API调用请求中携带的token已经处于离线状态，则可以拒绝此次调用请求。可见，通过这种方式使得开放平台可以通过判断第三方App的页面是否处于打开状态，来判定当前用户是否正在使用该第三方App,只有在确定出用户正在使用该第三方App的情况下,才会向第三方App提供用户的敏感数据，因此，可以提高用户数据的安全性。
[0027]当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
【附图说明】
[0028]为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0029]图1是本申请实施例提供的方法的流程图；
[0030]图