CN117240608A

CN117240608A - 登录授权方法、装置、计算机设备和存储介质

Info

Publication number: CN117240608A
Application number: CN202311494109.0A
Authority: CN
Inventors: 黄长富; 陈晓波; 罗程; 李斌
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-11-10
Filing date: 2023-11-10
Publication date: 2023-12-15
Anticipated expiration: 2043-11-10
Also published as: CN117240608B

Abstract

本申请涉及一种登录授权方法、装置，方法包括：响应于由第一应用触发的授权认证请求，生成授权凭证；若授权认证请求中包括回调地址，则关联授权凭证和回调地址；将授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示私有服务器关联私有客户端的登录态和授权凭证，将授权凭证传输至所述第一应用；在接收到携带授权凭证的消费请求的情况下，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态；将登录态反馈至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。采用本方法能够实现第一应用与第二应用的私有客户端以及相应的私有服务器之间的数据互通，提升人机交互体验。

Description

登录授权方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及登录授权一种方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

背景技术

随着计算机技术的发展，对于支持SaaS（Software as a Service，软件及服务）版部署以及本地版（或称私有化）部署的应用程序而言，在SaaS版中，应用程序向外部应用开放了分享和登录功能，外部应用可以通过集成SaaS版所提供的登录或分享的软件开发工具包（Software Development Kit，SDK），使用应用程序的登录态进行登录或者分享信息到SaaS版应用程序中。

然而，对于数据敏感的客户，为了保证数据的安全性，通常采用本地版部署应用程序，由于SaaS版的应用程序与私有化部署版的应用程序往往以两个独立的应用进行发布，因此，私有化部署的后台服务与SaaS版的后台服务之间的数据无法互通，从而导致SaaS版所提供的登录或分享SDK无法直接支持私有化部署的应用。但是随着接入SaaS版所提供的登录或分享SDK的外部应用增多，针对能够使用本地版部署的应用程序进行登录以及分享的需求也逐渐增多，因此亟需一种能够实现外部应用接入本地版部署的应用程序的方案。

发明内容

基于此，有必要针对上述技术问题，提供一种能够实现第一应用与第二应用的私有客户端以及相应的私有服务器之间的数据高效互通的登录授权方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。

一方面，本申请提供了一种登录授权方法，包括：

响应于由第一应用触发的授权认证请求，生成授权凭证；

若所述授权认证请求中包括回调地址，则关联所述授权凭证和回调地址；

将所述授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示所述私有服务器关联所述私有客户端的登录态和所述授权凭证，将所述授权凭证传输至所述第一应用；

在接收到携带所述授权凭证的消费请求的情况下，基于与所述授权凭证相关联的回调地址，从所述私有服务器处获取与所述授权凭证相关联的登录态；

将所述登录态反馈至所述第一应用，以指示所述第一应用根据所述登录态以所述私有客户端的用户账号进行登录操作。

另一方面，本申请还提供了一种登录授权装置，包括：

第一生成模块，用于响应于由第一应用触发的授权认证请求，生成授权凭证；

第一关联模块，用于若所述授权认证请求中包括回调地址，则关联所述授权凭证和回调地址；

第一发送模块，用于将所述授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示所述私有服务器关联所述私有客户端的登录态和所述授权凭证，将所述授权凭证传输至所述第一应用；

回调模块，用于在接收到携带所述授权凭证的消费请求的情况下，基于与所述授权凭证相关联的回调地址，从所述私有服务器处获取与所述授权凭证相关联的登录态；

反馈模块，用于将所述登录态反馈至所述第一应用，以指示所述第一应用根据所述登录态以所述私有客户端的用户账号进行登录操作。

另一方面，本申请还提供了一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现本申请实施例提供的登录授权方法。

另一方面，本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本申请实施例提供的登录授权方法。

另一方面，本申请还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现本申请实施例提供的登录授权方法。

上述登录授权方法、装置、计算机设备、存储介质和计算机程序产品，首先，通过响应于由第一应用触发的授权认证请求，生成授权凭证；若授权认证请求中包括回调地址，则关联授权凭证和回调地址；将授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示私有服务器关联私有客户端的登录态和授权凭证，将授权凭证传输至第一应用，如此，在第一应用客户端与第二应用客户端之间仅传输授权凭证，有效保证数据的安全性；在接收到携带授权凭证的消费请求的情况下，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态；将登录态反馈至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。如此，通过私有服务器向外提供的回调地址的中转，能够实现第二应用的通用服务器与私有服务器之间数据的互通，同时基于第一应用与第二应用的通用服务器之间的互通性，进而能够实现第一应用与第二应用的私有服务器之间的数据互通。

另一方面，本申请提供了一种登录授权方法，包括：

响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，以指示所述通用服务器生成与所述授权认证请求适配的授权凭证，并关联所述回调地址与所述授权凭证；

接收所述通用服务器反馈的授权凭证，关联所述授权凭证与所述第二应用的私有客户端的登录态，并将所述授权凭证传输至所述第一应用；

接收所述通用服务器基于所述回调地址发起的信息获取请求，将与所述授权凭证关联的所述私有客户端的登录态传输至所述通用服务器；传输的所述私有客户端的登录态用于转发至所述第一应用，以指示所述第一应用根据所述登录态以所述私有客户端的用户账号进行登录操作。

另一方面，本申请提供了一种登录授权装置，包括：

响应模块，用于响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，以指示所述通用服务器生成与所述授权认证请求适配的授权凭证，并关联所述回调地址与所述授权凭证；

第二关联模块，用于接收所述通用服务器反馈的授权凭证，关联所述授权凭证与所述第二应用的私有客户端的登录态，并将所述授权凭证传输至所述第一应用；

传输模块，用于接收所述通用服务器基于所述回调地址发起的信息获取请求，将与所述授权凭证关联的所述私有客户端的登录态传输至所述通用服务器；传输的所述私有客户端的登录态用于转发至所述第一应用，以指示所述第一应用根据所述登录态以所述私有客户端的用户账号进行登录操作。

上述登录授权方法、装置、计算机设备、存储介质和计算机程序产品，私有服务器接收到授权认证请求后，将回调地址发送至通用服务器，以指示通用服务器绑定生成的授权凭证与回调地址，并在接收到通用服务器发送的信息获取请求时，基于该回调地址将私有服务器中与授权凭证所绑定的私有客户端的登录态反馈至通用服务器，并通过通用服务器将私有客户端的登录态传输至第一应用，如此，能够通过回调地址的中转实现第二应用的私有服务器与通用服务器之间的数据互通，由于第一应用与通用服务器本身具有的互通性，进而也能够实现第二应用的服务器与第一应用之间的数据互通。

另一方面，本申请提供了一种登录授权方法，包括：

响应于与第二应用关联的登录入口的触发操作，生成授权认证请求；

确定第二应用的客户端类型，并通过与所述客户端类型匹配的目标客户端，将所述授权认证请求发送至第二应用的通用服务器，以指示所述通用服务器生成授权凭证；

通过所述目标客户端，接收所述通用服务器生成的授权凭证；

向所述通用服务器发送携带所述授权凭证的消费请求，并从所述通用服务器处接收与所述授权凭证关联的目标客户端的登录态；

根据所述登录态以所述目标客户端的用户账号进行登录操作。

另一方面，本申请提供了一种登录授权装置，包括：

第二生成模块，用于响应于与第二应用关联的登录入口的触发操作，生成授权认证请求；

第二发送模块，用于确定第二应用的客户端类型，并通过与所述客户端类型匹配的目标客户端，将所述授权认证请求发送至第二应用的通用服务器，以指示所述通用服务器生成授权凭证；

第一接收模块，用于通过所述目标客户端，接收所述通用服务器生成的授权凭证；

第二接收模块，用于向所述通用服务器发送携带所述授权凭证的消费请求，并从所述通用服务器处接收与所述授权凭证关联的目标客户端的登录态；

登录模块，用于根据所述登录态以所述目标客户端的用户账号进行登录操作。

上述登录授权方法、装置、计算机设备、存储介质和计算机程序产品，通过第一应用的客户端向外提供的与第二应用相关的登录入口生成授权认证请求之后，首先，基于客户端类型，确定传输该授权认证请求的第二应用的目标客户端，如此，不仅能够保证与第一应用进行交互的第二应用客户端的准确性，还能够简化第一应用接入不同客户端类型的第二应用的客户端的接入流程；然后，通过目标客户端转发授权认证请求之后接收通用服务器生成的授权凭证，并基于授权凭证，通过目标客户端从通用服务器处获取目标客户端的登录态，如此，能够实现第一应用与不同客户端类型的第二应用的客户端之间的数据互通。

附图说明

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

图1为一个实施例中登录授权方法的应用环境图；

图2为一个实施例中登录授权方法的流程示意图；

图3为一个实施例中私有服务器实现登录授权方法的流程示意图；

图4为一个实施例中第一应用的客户端实现登录授权方法的流程示意图；

图5A为一个实施例中第一应用的登录授权操作的可视化流程界面图；

图5B为一个实施例中第一应用的信息共享操作的可视化流程界面图；

图6为一个实施例中基于SaaS版第二应用实现登录授权方法的交互图；

图7为一个实施例中基于不同版本的第二应用的实现登录分享的流程图；

图8为一个实施例中本地版部署的第二应用的登录授权流程示意图；

图9为一个实施例中针对授权凭证的消费处理流程示意图；

图10为一个实施例中第一应用的目标图文信息的分享操作流程示意图；

图11为一个实施例中基于多版本的第二应用的实现登录分享的整体流程图；

图12为一个实施例中通用服务器实现登录授权方法的装置的结构框图；

图13为一个实施例中私有服务器实现登录授权方法的装置的结构框图；

图14为一个实施例中第一应用实现登录授权方法的装置的结构框图；

图15为一个实施例中服务器对应的计算机设备的内部结构图；

图16为一个实施例中终端对应的计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释：

1）软件即服务（Software as a Service，SaaS），SaaS是一种基于云计算的软件交付模式，用户可以通过互联网按需使用软件应用。在SaaS模式下，软件提供商负责软件的安装、配置、维护以及数据的安全性，而用户只需要通过web浏览器或移动应用程序来访问和使用软件。

2）应用程序的SaaS版部署：通过云端提供软件服务的模式，用户数据保存在云端，客户无需维护服务器设备。

应用程序的私有化部署，又称应用程序的本地化部署或应用程序的本地版部署，是指应用程序的服务器端、客户端、管理后台，打包成一套解决方案交付给企业客户使用。也即客户通过自建服务器，将应用程序部署在客户自己的服务器上，相对于SaaS版部署，本地部署版的数据隔离性更高。

3）Oauth是Open Authority的简写，是使用令牌的方式来代替用户密码访问应用。Oauth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是Oauth的授权不会使第三方触及到用户的账号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此Oauth是安全的。

3）Scheme是一种用于标识和定位资源的命名约定。客户端中，可以通过定义特殊的标识，唤起对应的应用程序。

4）AES128加密：（Advanced Encryption Standard）一种对称加密算法，其中的数字128表示密钥长度为128位。AES是当前广泛使用的加密算法之一，被用于保护敏感数据的机密性。

5）Protobuf（Protocol Buffers）是一种语言无关的序列化结构化数据格式。Protobuf对象序列化为字符串，Protobuf本身是二进制进行存储，为了方便阅读、传输，可以将其转化为字符串格式。这个过程是可逆的，后续可以将字符串转化为Protobuf对象。

基于上述对本申请实施例中涉及的名词和术语的解释，对本申请实施例提供的登录授权方法进行说明，本申请实施例提供的登录授权方法可以应用于如图1所示的应用环境中。其中，终端102中部署有第一应用的客户端以及第二应用的客户端，第一应用的客户端中显示有与第二应用关联的登录入口。第二应用的客户端具有不同的客户端类型，客户端类型与第二应用的部署方式有关。通过云端提供软件服务的模式实现的部署方式称为第二应用SaaS版部署，该部署方式下，资源保存在云端，客户无需维护服务器设备，第二应用的客户端类型为通用客户端，相应的服务器称为通用服务器。对于数据敏感（数据安全性要求高）的客户通过自建服务器将第二应用的所提供的服务功能部署在客户私有（或本地）的服务器上的部署方式称为第二应用本地版部署或第二应用私有化部署，该部署方式下，第二应用的客户端类型为私有客户端，相应的本地服务器称为私有服务器。需要说明的是，第一应用中内置有第二应用的通用服务器向外提供的登录SDK和分享SDK。第一应用的客户端接入登录SDK后，能够与第二应用的私有客户端以及相应的私有服务器之间进行基于授权凭证的数据互通。其中，通过通信网络103与第二应用的通用服务器104、第二应用的私有服务器105、以及第一应用的服务器106进行通信。数据存储系统可以存储第二应用的通用服务器104、第二应用的私有服务器105以及第一应用的服务器106需要处理的数据。数据存储系统可以集成在第二应用的通用服务器104、第二应用的私有服务器105以及第一应用的服务器106上，也可以放在云上或其他网络服务器上。

基于图1，在一些实施例中，第二应用的通用服务器接收到基于第一应用的客户端触发的授权认证请求，生成授权凭证；检测授权认证请求中所携带的信息，若授权认证请求中包括回调地址，则关联授权凭证和第二应用的私有服务器所提供的回调地址；将授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示该私有服务器关联私有客户端的登录态和授权凭证，将授权凭证传输至第一应用的客户端；在接收到携带该授权凭证的消费请求的情况下，基于与该授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态；将登录态反馈至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

其中，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备，物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。第二应用的通用服务器104、第二应用的私有服务器105或第一应用的服务器106可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一些实施例中，如图2所示，提供了一种登录授权方法，以该方法应用于图1中的第二应用的通用服务器为例进行说明，包括以下步骤202至步骤210。其中：

步骤202，响应于由第一应用触发的授权认证请求，生成授权凭证。

在实际实施时，第一应用是终端中部署的不同于第二应用的应用程序，比如可以是社交应用、邮件应用、支付应用或者游戏应用等。社交应用，包括即时通信应用、SNS（Social Network Service）应用或者直播应用等。通用服务器向第一应用等外部应用开放了登录功能和分享功能，第一应用可以通过集成第二应用的登录或分享SDK，在第一应用中根据用户的触发操作通过内置的第二应用登录SDK拉起第二应用，以实现基于第二应用的登录功能。由于第一应用中集成有第二应用用于实现登录功能的相关开放的登录的应用程序接口，因此，第二应用的通用服务器能够接收到由第一应用所触发的授权认证请求，并生成与该授权认证请求对应的授权凭证。

授权认证请求是基于第一应用中提供的与第二应用关联的登录入口的触发操作所产生的。授权认证请求用于从第二应用的通用服务器中获取使用第二应用的用户的身份标识进行登录的授权凭证，授权认证请求最终会被传输至第二应用的通用服务器。需要说明的是，由于第二应用的客户端类型不同，通用服务器接收授权认证请求的传输路径也不同，而第二应用的客户端类型与第二应用的部署方式相关。若第二应用的部署方式为SaaS版部署，则第二应用的客户端类型为通用客户端，此时，授权认证请求是经由第二应用的通用客户端直接传输至通用服务器。若第二应用的部署方式为本地版部署，则第二应用的客户端类型为私有客户端，此时，授权认证请求是经过“第二应用的私有客户端——>私有客户端对应的私有服务器——>通用服务器”的传输路径最终传输至通用服务器。通用服务器基于该授权认证请求，生成与之对应的授权凭证。

针对授权凭证进行说明，授权凭证（code）是一种有效期很短（比如5分钟更换一次）的登录凭证，第二应用的通用服务器可在接收到第一应用触发的授权认证请求后，生成相应的授权凭证，并反馈给第一应用，第一应用向通用服务发送携带该授权凭证的消费请求，第一应用根据消费请求中携带的授权凭证通过第二应用的通用服务器换取登录态。可见，经过授权凭证的中转，第一应用可通过第二应用的通用服务器直接或间接的获取登录态，保证跨应用数据传输的安全性。

针对通用服务器接收授权认证请求的传输路径进行说明，在一些实施例中，在第一应用触发授权认证请求，并确定待调用的第二应用的客户端为私有客户端的情况下，授权认证请求是被传输至第二应用的私有客户端对应的私有服务器，并通过私有服务器添加了回调地址后再传输至通用服务器的。

在实际实施时，若确定待调用的第二应用的客户端为私有客户端的情况下，通用服务器不能直接获取第二应用的对象的身份标识，为了能够读取到第二应用的私有服务器中的资源或数据，授权认证请求途径第二应用的私有服务器时，会被私有服务器添加一个回调地址后再传输至通用服务器，即通用服务器接收到的授权认证请求中携带有回调地址。回调地址是第二应用的私有服务器所提供的用于获取第二应用的私有客户端的登录态的应用程序接口。通用服务器通过回调地址能够从私有服务器中读取登录态，从而实现私有服务器与通用服务器之间的数据互通。

步骤204，若授权认证请求中包括回调地址，则关联授权凭证和回调地址。

在实际实施时，基于安全因素考虑，第一应用的客户端与第二应用的客户端之间的传输，仅传输授权凭证（code信息），第二应用的登录态不通过客户端之间进行传输。在授权认证请求中包括回调地址的情况下，说明第二应用的部署方式为私有化部署，第二应用相关的登录态存储于第二应用的私有服务器中，通用服务器不具备直接访问第二应用的登录态的权限，因此，通用服务器从私有服务器中接收回调地址，并将授权凭证code与回调地址进行绑定，后续通用服务器接收到针对授权凭证code的消费请求，通过调用回调地址从第二应用的私有服务器中换取登录态。需要说明的是，若授权认证请求中不包括回调地址，说明第二应用的部署方式为SaaS版部署，由于通用服务器可以直接获取第二应用的登录态，因此，可以直接将授权凭证与登录态绑定。

步骤206，将授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示私有服务器关联私有客户端的登录态和授权凭证，将授权凭证传输至第一应用。

在实际实施时，由于授权凭证具有有效期，为了第二应用的私有服务器中得到与当前授权凭证对应的登录态信息，通用服务器通过回调地址将授权凭证发送至私有服务器，以指示私有服务器绑定该授权凭证以及当前私有客户端的登录态。即授权凭证与登录态的绑定操作由私有服务器完成，同时还将授权凭证反馈至第二应用的私有客户端，最后反馈至第一应用，以通知第一应用已经得到使用第二应用的私有客户端的登录态进行登录操作的授权认证。后续便于第一应用继续触发针对该授权凭证的消费请求，最终实现以第二应用的登录态登录第一应用的操作。

步骤208，在接收到携带授权凭证的消费请求的情况下，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态。

在实际实施时，将授权凭证反馈至第一应用之后，通用服务器接收到由第一应用触发的携带该授权凭证的消费请求，首先检查授权凭证有效性，然后判断授权凭证是否绑定了SaaS登录态，若有则返回登录态，若没有，则访问授权凭证所绑定的回调地址，从私有服务器中换取私有客户端的登录态，并且通用服务器将登录态返回第一应用的客户端。

对登录态进行说明，登录态是以用户标识成功登录第二应用后第二应用的服务器生成的用于标识当前用户的登录状态的字符串。由于第二应用的服务器中所存储的用户标识UserId属于敏感信息，为了数据安全性，通常将UserId映射称为通用用户标识openUserid供第一应用使用，映射的方式大致是通过用户标识UserId以及应用程序标识符appid生成openUserid。另外，登录态中除了包括通用用户标识openUserid外，还可以包括秘钥sessionKey，由于第二应用的服务器返回至第一应用的数据是基于sessionKey进行加密的数据，在第一应用中需要sessionKey对加密的数据进行解密。

在一些实施例中，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态，包括：通过与授权凭证相关联的回调地址，向私有服务器发送信息获取请求；接收私有服务器基于信息获取请求返回的与授权凭证相关联的登录态。

在实际实施时，在授权凭证关联回调地址的情况下，通用服务器通过该回调地址向私有服务器发送信息获取请求，并接收由私有服务器反馈的当前私有客户端的登录态。如此，能够通过私有服务器所提供的回调地址，实现通用服务器与私有服务器之间的登录态互通。

步骤210，将登录态反馈至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

在实际实施时，通用服务器最终将与授权凭证相适配的登录态反馈至第一应用，以指示第一应用根据登录态所对应的第二应用的私有客户端的用户账号进行登录操作。

上述实施例中，通用服务器能够实现针对第二应用的多个不同版本的授权凭证的颁发，同时，在接收到携带授权凭证的消费请求后，还能实现多个不同版本的第二应用的客户端的登录态的下发，如此，将不同版本的第二应用关联的授权凭证的颁发和不同版本的第二应用的客户端的登录态的下发，集中到通用服务器，既保证了本地部署版的第二应用的数据安全又简化了接入流程，降低外部应用接入成本。

在一些实施例中，若授权认证请求中不包括回调地址，则检查第二应用的通用客户端的安装状态；若第二应用的通用客户端的安装状态为已安装，则关联通用客户端的登录态以及授权凭证。

在实际实施时，通用服务器检测到授权认证请求中不包括回调地址时，说明授权认证请求是基于第二应用的通用客户端发送的，也就是说，部署第一应用的终端同时部署的是SaaS版的第二应用的通用客户端，此时，通用服务器能够直接绑定授权凭证以及相应的第二应用的通用客户端的登录态。在进行绑定操作之前，通用服务器通常先对第二应用的通用客户端的安装状态进行检查，只有在成功安装了第二应用的通用客户端后，才能进行后续操作，若第二应用的通用客户端的安装状态为未安装，则向第一应用反馈第二应用的客户端未安装的提示信息。

上述实施例中，在授权认证请求中不包括回调地址的情况下，由通用服务器在关联通用客户端的登录态以及授权凭证之前，先对通用客户端的安装状态进行检查，保证只有在成功安装了通用客户端的情况下才可执行针对第二应用的登录态的拉取操作，如此，能够保证登录授权流程的顺利进行，提升人机交互体验。

在一些实施例中，在接收到携带授权凭证的消费请求的情况下，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态，包括：在接收到携带授权凭证的消费请求的情况下，确定与授权凭证相关联的关联信息；若关联信息为回调地址，则基于回调地址从私有服务器处获取与授权凭证相关联的登录态。

在实际实施时，通用服务器生成授权凭证并下发至第一应用后，将会接收到第一应用触发的携带授权凭证的消费请求，该消费请求通常是用于从通用服务器处获取之前与授权凭证所绑定的关联信息，并基于关联信息进行后续的业务处理。通用服务器解析消费请求，得到携带的授权凭证，并查询该授权凭证的关联信息，若关联信息为回调地址，则通用服务器通过回调地址，从私有服务器处获取与该授权凭证所绑定的登录态。

上述实施例中，通过私有服务器所提供的回调地址，实现私有服务器与通用服务器之间的信息互通。

在一些实施例中，在接收到携带授权凭证的消费请求的情况下，确定与授权凭证相关联的关联信息；若关联信息为第二应用的通用客户端的登录态，则将登录态反馈至第一应用，以指示第一应用根据登录态以通用客户端的用户账号进行登录操作。

在实际实施时，通用服务器检测到与授权凭证相关联的关联信息直接为通用客户端的登录态时，说明终端安装的第二应用的部署方式为SaaS版部署，直接可以将登录态返回至第一应用。

在一些实施例中，在接收到携带授权凭证的消费请求之后，方法还包括：对消费请求中携带的授权凭证的状态进行验证，得到验证结果；若验证结果表征授权凭证的状态为有效状态，则执行基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态的步骤；将授权凭证的状态由有效状态调整为无效状态。

在实际实施时，第二应用的通用服务器所生成的授权凭证具有有效期，因此，通用服务器接收到携带的授权凭证的消费请求后，会先对消费请求中的授权凭证进行有效性验证，只有在验证结果表征该授权凭证的状态为有效状态之后，在继续执行后续从私有服务器处获取与授权凭证相关联的登录态的步骤。同时，授权凭证使用过一次后，就需要调整为无效状态，以避免针对授权凭证的重复使用，提高数据传输的安全性。

上述实施例中，通过对授权凭证的有效性验证以及授权平台的状态的调整，能够保证授权凭证的一次性，避免因授权凭证的重复使用所引起的数据泄露。

在一些实施例中，如图3所示，提供了一种登录授权方法，以该方法应用于图1中的第二应用的私有服务器为例进行说明，包括以下步骤302至步骤306。其中：

步骤302，响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，以指示通用服务器生成与授权认证请求适配的授权凭证，并关联回调地址与授权凭证。

在实际实施时，由于数据安全性的要求，本地版部署的第二应用从客户端到服务器都是一套独立的服务。授权认证请求传输至第二应用的私有服务器后，为了能够让通用服务器读取自身所存储的第二应用客户端的登录态，第二应用的私有服务器通常先将回调地址添加至授权认证请求，然后再将添加了回调地址的授权认证请求发送至通用服务器，以指示通用服务器绑定回调地址和授权凭证。回调地址是私有服务器向通用服务器开放的能够获取第二应用的私有客户端的登录态的访问地址。

步骤304，接收通用服务器反馈的授权凭证，关联授权凭证与第二应用的私有客户端的登录态，并将授权凭证传输至第一应用。

在实际实施时，私有服务器在接收到通用服务器通过调用回调地址所反馈的授权凭证，在本地建立授权凭证与私有客户端的登录态之间的绑定关系。同时将授权凭证反馈至第一应用。

步骤306，接收通用服务器基于回调地址发起的信息获取请求，将与授权凭证关联的私有客户端的登录态传输至通用服务器；传输的私有客户端的登录态用于转发至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

在针对授权凭证的消费处理阶段，私有服务器会接收到由通用服务器通过访问回调地址所发起的信息获取请求，信息获取请求用于从私有服务器获取与授权凭证关联的登录态。私有服务器接收到信息获取请求后，会先验证信息获取请求中携带的授权凭证是否处于有效状态，在授权凭证处于有效状态的情况下，验证信息请求中携带的授权凭证与本地存储的授权凭证是否一致，若一致，则将与该授权凭证关联的私有客户端的登录态传输至通用服务器，传输的私有客户端的登录态用于转发至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

上述实施例中，私有服务器通过在授权认证请求中添加回调地址，实现私有服务器与通用服务器之间基于授权认证以及回调地址的数据传递，同时通过针对授权凭证的有效性验证，保证私有客户端的登录态的一致性和信息传递过程中的安全性。

在一些实施例中，响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，包括：响应于由第一应用触发的授权认证请求，检查第二应用的私有客户端的安装状态；若第二应用的私有客户端的安装状态为已安装，将回调地址发送至第二应用的通用服务器。

在实际实施时，第二应用的私有服务器响应于由第一应用触发的授权认证请求之后，将回调地址添加至授权认证请求之前，首先检测与自身关联的第二应用的私有客户端的安装情况，只有在第二应用的私有客户端成功安装的情况下才将回调地址添加至授权认证请求，以进行后续操作。若第二应用的私有客户端并未安装或安装不成功，则向第一应用反馈用于指示第二应用的私有客户端未安装的提示信息。

上述实施例中，第二应用的私有服务器通过验证第二应用的私有客户端是否成功安装的方式，保证授权认证请求的顺利转发以及后续操作的顺利执行，提升执行效率。

在一些实施例中，私有客户端的登录态包括秘钥，第二应用的私有服务器关联授权凭证与私有客户端的登录态之后，还会将秘钥反馈至第二应用的私有客户端，反馈至私有客户端的秘钥用于私有客户端对后续接收到的待显示的图文消息进行解密。

在实际实施时，由于第二应用的服务器返回的数据是通过秘钥进行加密后的数据，因此，需要将秘钥添加至登录态中返回至第一应用，登录态中的秘钥用于在第一应用中对第二应用的服务器返回的加密的数据进行解密，对第一应用向第二应用的客户端所分享的图文信息进行加密，并在第二应用的客户端中对接收到的加密的图像信息进行解密。

上述实施例中，在基于第二应用的登录态成功登录第一应用之后，第一应用与第二应用之间实现了信息互通，通过秘钥对待分享的图文信息进行加密和解密操作，提高了数据在分享过程中的安全性。

在一些实施例中，如图4所示，提供了一种登录授权方法，以该方法应用于图1中的第一应用的客户端所在的终端为例进行说明，包括以下步骤402至步骤410。其中：

步骤402，响应于与第二应用关联的登录入口的触发操作，生成授权认证请求。

在实际实施时，部署第一应用以及第二应用的终端，响应于第一应用的显示界面中显示的与第二应用关联的登录入口的触发操作，生成授权认证请求，并传输至第二应用的客户端。传输的授权认证请求用于从通用服务器获取授权凭证。基于该授权认证能够在第一应用中使用第二应用的客户端的用户的登录态进行登录，从而建立第一应用与第二应用之间的数据共享通道。其中，登录入口的具体形式可以是登录按钮、或登录链接地址等。

步骤404，确定第二应用的客户端类型，并通过与客户端类型匹配的目标客户端，将授权认证请求发送至第二应用的通用服务器，以指示通用服务器生成授权凭证。

在实际实施时，由于第二应用的客户端类型包括第二应用的私有客户端以及第二应用的通用客户端。第二应用的不同客户端在终端安装时，会在终端系统中注册不同的资源标记符，资源标记符用于表示客户端类型。终端在接收到针对登录入口的触发操作，可以读取资源标记符，从而唤起与资源标记符对应的第二应用的客户端。

示例性地，以第二应用为办公管理应用为例，针对第二应用的通用客户端设置资源标记符“Scheme:A”，针对第二应用的私有客户端设置资源标记符“Scheme:Alocal”，第一应用接收到与第二应用关联的登录入口的触发操作之后，先读取资源标记符，若资源标记符为“Scheme:A”则表明终端安装的第二应用的客户端为通用客户端，若资源标记符为“Scheme:Alocal”则表明终端安装的第二应用的客户端为私有客户端。

步骤406，通过目标客户端，接收通用服务器生成的授权凭证。

在实际实施时，终端在确定了第二应用的目标客户端之后，可以通过该目标客户端以及相应的服务器，传输授权认证请求，并通过与授权认证请求相同的传输路径，接收到通用服务器所生成的授权凭证。其中，目标客户端为通用客户端时，授权凭证通过“通用服务器——>通用客户端——>第一应用的客户端”的传输路径传输至第一应用的客户端；目标客户端为私有客户端时，授权凭证通过“通用服务器——>私有服务器——>私有客户端——>第一应用的客户端”的传输路径传输至第一应用的客户端。

步骤408，向通用服务器发送携带授权凭证的消费请求，并从通用服务器处接收与授权凭证关联的目标客户端的登录态。

在实际实施时，第一应用的终端接收到与授权认证请求对应的授权凭证之后，会继续向通用服务器发送携带该授权凭证的消费请求，并从通用服务器处接收与授权凭证关联的目标客户端的登录态。其中，从通用服务器处接收登录态的方式与目标客户端的客户端类型有关。若客户端类型为通用客户端，则可以直接从通用服务器获取与授权凭证绑定的通用客户端的登录态，若客户端类型为私有客户端，则需要通用服务器根据授权凭证绑定的回调地址从私有服务器中获取私有客户端的登录态。

步骤410，根据登录态以目标客户端的用户账号进行登录操作。

在实际实施时，第一应用从通用服务器得到与携带授权凭证的消费请求相适配的登录态之后，就可以以目标客户端的用户账号进行登录操作。

上述实施中，第一应用的客户端向外提供多种形式的与第二应用相关的登录入口，提升交互方式的多样性，并基于针对登录入口的触发操作，识别第二应用的客户端在终端中的资源标识，根据资源标识确定第二应用的客户端类型，确定与第一应用进行交互的第二应用的目标客户端，如此，能够保证唤起客户端的准确性，接着，通过目标客户端转发授权认证请求，同时接收授权凭证，能够保证数据传输的一致性，最后，能够通过目标客户端从通用服务器处直接或间接获取相应的登录态，如此，第一应用不仅可以使用SaaS版的第二应用进行登录和分享还能使用本地部署版的第二应用进行登录和分享，解除了本地版部署的数据互通限制，在保证本地版部署的第二应用的数据安全性的前提下简化了接入第二应用各种版本的流程，同时降低了接入第二应用的接入成本。

在一些实施例中，通过与客户端类型匹配的目标客户端，将授权认证请求发送至第二应用的通用服务器，包括：若目标客户端为第二应用的私有客户端，则通过私有客户端，将授权认证请求发送至私有客户端关联的私有服务器，以指示私有服务器将回调地址以及授权认证请求传输至第二应用的通用服务器；回调地址用于指示通用服务器在接收到消费请求后，依据授权凭证从私有客户端对应的私有服务器处获取私有客户端的登录态；若目标客户端为第二应用的通用客户端，通过通用客户端，直接将授权认证请求发送至通用客户端关联的通用服务器。

在实际实施时，由于第二应用的客户端类型不同，授权认证请求的传输路径也不同，客户端类型为私有客户端时，授权认证请求通过“私有客户端——>私有服务器——>通用服务器”的传输路径传输至通用服务器，其中，经过私有服务器时，私有服务器会将回调地址添加至授权认证请求，再传输至通用服务器。私有服务器提供的回调地址，用于指示通用服务器在接收到携带授权凭证的消费请求后，依据授权凭证从私有客户端对应的私有服务器处获取私有客户端的登录态。客户端类型为通用客户端时，授权认证请求直接通过通用客户端传输至通用服务器。

上述实施例中，根据第二应用的客户端类型设置与授权认证请求相适配的传输路径，保证通用服务器接收到与客户端类型匹配的授权认证请求，同时客户端类型为私有客户端时，通过将私有服务器向外提供的回调地址添加至授权认证请求的方式，保证可以读取到私有服务器中的信息，如此，使得第一应用接入第二应用时，只需要客户端类型的识别正确性，就可读取到通用服务器或私有服务器中的数据，简化第一应用接入第二应用的流程。

在一些实施例中，登录态包括用于对信息进行加密的秘钥，该方法还包括信息分享的步骤，具体包括：响应于针对待分享信息的分享操作，基于秘钥，对待分享信息进行加密，得到加密结果；将加密结果发送至第二应用的目标客户端，以指示目标客户端通过秘钥，对加密结果进行解密得到待分享信息，并发送待分享信息。

在实际实施时，第一应用还包括内置的第二应用分享SDK，在第一应用中，根据登录态以第二应用的目标客户端的用户账号完成登录操作之后，终端响应于用户在第一应用中触发的针对待分享信息的分享操作，终端通过内置的第二应用分享SDK拉起第二应用的目标客户端，使用登录态的秘钥sessionKey对待分享信息进行加密，将加密的待分享信息分享至第二应用的目标客户端，以指示第二应用的目标客户端使用登录态中的秘钥sessionKey进行解密，得到待分享信息，最后调用第二应用分享SDK中所提供的消息发送接口发送待分享信息，接收待分享信息的可以是第二应用的目标客户端中的目标会话窗口等。其中，待分享信息可以是第一应用中存在的能够被当前用户分享的信息，信息的形式可以是文本信息、图文信息、文件、音视频信息、或者链接地址等。

上述实施例中，在第一应用使用第二应用的私有客户端的登录态实现登录操作的前提下，第一应用还可以通过内置的第二应用的分享SDK，实现与不同客户端类型相匹配的第二应用的客户端之间的信息分享操作，并在信息分享过程中，通过登录态的秘钥对待分享信息执行加密和解密处理，以保证信息分享过程中的安全性。

为详细说明本方案中的登录授权方法，下面以一个实际应用场景中的实施例进行说明，在该实施例中，第一应用（不同于第二应用的其他外部应用）为一种音视频会议应用，第二应用是一种组织通讯与办公工具等，第二应用对应有开放服务平台，该平台整合了第二应用的所有功能模块，并向外部应用提供应用程序接口，以供外部应用与第二应用进行数据互通。第一应用在该开放服务平台中进行注册，第二应用的部署方式可以包括SaaS版部署以及本地版部署。为了方便维护，SaaS版部署的第二应用的客户端（即前文中的通用客户端）与本地版部署的第二应用的客户端（即前文中的私有客户端）通常以两个独立的应用进行发布。由于第一应用中集成有第二应用的登录SDK以及分享SDK，因此，在第一应用中，能够使用第二应用进行OAuth登录或者分享图文信息到第二应用的目标会话中。

接下来，针对第一应用基于SaaS版部署的第二应用进行登录和分享操作的实现过程进行说明。

首先，从产品侧说明第一应用基于SaaS版部署的第二应用进行登录和分享操作的可视化流程。如图5A示出的登录操作的可视化流程，用户可以通过点击第一应用也就是外部应用的客户端中编号1显示的“登录”按钮（即前文中的登录入口），唤起第二应用“会议应用M”进行登录、分享，图中示出的“会议应用M”为已注册的组织通信应用，通过编号1的“登录”按钮，实现基于“会议应用M”的登录操作、通过图中示出的分享类按钮（如分享文本、分享图片）实现分享操作，如图5B示出的分享操作的界面示意图。在实现基于第二应用“会议应用M”的Oauth登录流程时，由于第二应用“会议应用M”的用户数据（如用户id即UserId）属于敏感信息，不能直接提供给外部应用方，为了保证数据的安全性，通常会将第二应用“会议应用M”的用户id映射称为openUserid（即前文中的通用用户标识）供外部应用使用。

其次，如图6，图6是第一应用基于SaaS版部署的第二应用进行登录和分享操作的交互图，SaaS版部署的第二应用的客户端即为前文中的第二应用的通用客户端，SaaS版部署的第二应用的后台即为前文中的第二应用的通用服务器，整个过程由第一应用的客户端、第二应用的客户端以及第二应用的服务器协同执行，具体过程如下：

用户在外部应用的客户端点击登录按钮后，会生成随机state，这个state存在与本次Oauth登录的整个流程中，最后state被返回给外部应用客户端，state用来校验回包是否为本次唤起登录对应的请求（即前文中的授权认证请求）。第一应用的客户端通过OauthReq接口向第二应用的客户端发送授权认证请求后，唤起第二应用的通用客户端，首先检查第二应用的客户端是否安装，若没有安装，则执行第二应用的安装流程；若已经安装，则第二应用的服务器所提供的相关服务，请求颁发授权码code（即前文中的授权凭证）。同时生成基于userid和appId生成登录态（包括通用用户标识openUserid和秘钥sessionKey），并绑定code与登录态，openUserid用来给外部应用进行身份判断，sessionKey在外部应用与第二应用的客户端之间进行数据加密和解密。之后，第二应用的客户端将sessionKey保存在本地，同时第二应用的客户端通过OauthResp将code以及state反馈至第一应用的客户端，第一应用的客户端检查state是否对应，若否，直接退出不进行后续操作，若是，则访问第二应用的后台提供的通过code换取登录态的接口LoginReq（即前文中的携带授权凭证的消费请求），第二应用的后台接收到该请求后，首先检测code的有效性，若code处于有效状态，则将该code所绑定的登录态通过LoginResp接口反馈至第一应用的客户端，第一应用的客户端获取到登录态后，将登录态中的秘钥sessionKey缓存在本地，并将openUserid作为身份信息登录第一应用的后台。第一应用的客户端接收到针对待分享的图文信息的分享操作，待分享的图文信息为protobuf格式，将其序列化为字符串后使用秘钥sessionKey进行AES128加密，第二应用的客户端接收到加密后的图文信息，使用之前保存的sessionKey进行解密，并调用消息发送接口将图文信息发送到第二应用的通用客户端的目标会话，完成登录、分享流程。

需要说明的是，基于安全因素考虑，外部应用客户端与第二应用客户端之间的传输，仅传输code信息，登录态不通过客户端之间进行传输。因此需要将code与登录态进行绑定，后续外部应用通过code访问第二应用的后台可以换取登录态。为了保证安全性，code在换取一次登录态后即失效。

接下来，针对第一应用基于本地版部署的第二应用进行登录和分享操作的实现过程进行说明。需要说明的是，第一应用基于本地版部署的第二应用进行登录和分享操作的可视化流程与SaaS版完全一致，对于外部应用开发者或者使用用户体验上没有区别，如此，能够减少开发者接入成本与用户使用学习成本。

其次，从技术实现方面说明第一应用基于本地版部署的第二应用进行登录和分享操作的实现过程。在实际应用中，由于数据安全性的要求，本地部署版的第二应用从第二应用的私有客户端到后台（私有服务器）都是一套独立的服务。在外部应用需要通过本地部署版的第二应用实现登录、分享等操作的情况下，在外部应用的客户端得到code之后进行code消费时，对于本地部署版的第二应用的服务器颁发的code，外部应用客户端通常先识别这个code是由哪个本地部署版的第二应用的后台颁发的，然后再调用对应后台的code消费地址换取登录态。但是由于每个企业的后台服务都是单独部署，可能会有无数个后台地址，导致对于外部应用接入第二应用的成本非常高。基于此，本实施例提出并实现了如图7所示的基于不同版本的第二应用的实现登录以及分享过程，SaaS版部署的第二应用的客户端在终端中部署时注册Scheme：A。本地部署版的第二应用的客户可以部署不同的服务器地址，但是本地版部署的第二应用的客户端使用的是同一个，本地部署版的第二应用的客户端在终端中注册Scheme：Alocal。外部应用的用户点击了登录按钮后，外部应用的客户端生成随机state并且检查是否响应Alocal这个Scheme，若不响应则执行图6中的SaaS版登录流程。若能成功响应，则执行本地版登录流程，即进入本地部署版的第二应用的登录授权流程，具体流程如图8所示：

第一应用的客户端拉起本地部署版的第二应用即发送前述授权认证请求，本地部署版的第二应用的客户端访问本地部署版的第二应用的后台服务，检查第二应用的客户端的安装状态，并向SaaS版的第二应用的后台传输授权认证请求，以请求颁发code，同时提交一个回调地址，用于后面消费code的时候从本地部署版的第二应用的后台换取登录态。SaaS版的第二应用的后台服务颁发code后将绑定上述回调地址，不再绑定登录态。本地部署版的第二应用的后台绑定code与登录态，并且返回本地部署版的第二应用的客户端，最后返回外部应用客户端。

外部应用的客户端继续完成code处理流程如图9所示：访问SaaS版的第二应用的后台的code消费接口，SaaS后台服务收到请求后会先检查code有效性，然后判断code是否绑定了SaaS登录态，若有则返回登录态，若否，则SaaS后台服务通过访问回调地址，从本地部署版的第二应用的后台换取本地部署版登录态，并且SaaS后台服务将登录态返回外部应用客户端。外部应用使用第二应用的通用用户标识openUserid进行登录。

针对第一应用的目标图文信息的分享操作进行说明，如图10所示，响应于第一应用的目标图文消息的分享操作，外部应用的客户端首先使用登录态中的秘钥sessionKey进行加密，然后判断是否响应Alocal这个Scheme，若不响应则唤起SaaS版的第二应用的客户端，若响应则唤起本地部署版的第二应用的客户端。由于唤起第二应用的客户端版本的稳定性，颁发code的客户端版本中存储了对应的sessionKey。因此唤起的对应版本的第二应用的客户端中存有有效的sessionKey，分享操作可以顺利完成。基于上述图7-图10可以确定本实例中第一应用基于不同版本的第二应用的实现登录、分享操作的整体流程如图11所示。

需要说明的是，唤起第二应用的部署版本采用的是Scheme的方式，由于同一个Scheme唤起不同的应用可能存在随机性，因此，通过差异化定义Scheme的方式，为不同版本的Scheme设置相应的优先级，针对同时安装SaaS版和本地部署版应用场景，基于Scheme的优先级唤起第二应用的相应版本的客户端，即优先级高的第二应用的客户端先被唤起。如此，能够保证第二应用的客户端的唤起顺序是固定的，避免随机唤起的问题。

下面对上述实现Oauth登录的应用程序接口进行说明：

1）OauthReq{string state；//校验是否为本次请求的汇报}

2）OauthResp{

string state；//校验是否为本次请求的汇报

string code；//授权凭证}

针对携带code的消费请求涉及的接口进行说明，

3）LoginReq{string code；//授权凭证}，授权凭证请求的相应接口，返回字符串string类型的授权凭证。

4）LoginResp{

string sessionKey；//秘钥

string openUserid；//通用用户标识

}，用于返回第二应用的登录态的接口。

针对本地部署版后台向SaaS后台申请code涉及的应用程序接口进行说明：

5）QueryCodeReq{string callback_url；}

其中，callback_url为本地部署版提供的回调地址，用于获取用户在本地部署版中的openUserid。

6）QueryCodeResp{string code；/SaaS版颁发的code}

针对SaaS后台向本地部署版后台消费Code过程涉及的应用程序接口进行说明：

7）QueryLoginReq{string code；}

8）QueryLoginResp{

string sessionKey；//秘钥

string openUserid；//通用用户标识}

上述实施例中，通过将多个版本（本地版和SaaS版）的code颁发与code鉴权统一到了SaaS版的第二应用的服务后台，实现外部应用可以使用本地部署版的第二应用实现登录与分享功能，如此，能够保证接入了SaaS版本的第二应用的SDK的外部应用可以在本地版部署的第二应用上无缝使用，提高了跳转稳定性，丰富第三方生态。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的登录授权方法的登录授权装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个登录授权装置实施例中的具体限定可以参见上文中对于登录授权方法的限定，在此不再赘述。

在一些实施例中，如图12所示，提供了一种登录授权装置1200，包括：第一生成模块1210、第一关联模块1220、第一发送模块1230、回调模块1240和反馈模块1250，其中：

第一生成模块，用于响应于由第一应用触发的授权认证请求，生成授权凭证。

第一关联模块，用于若授权认证请求中包括回调地址，则关联授权凭证和回调地址。

第一发送模块，用于将授权凭证发送至与第二应用的私有客户端对应的私有服务器，以指示私有服务器关联私有客户端的登录态和授权凭证，将授权凭证传输至第一应用。

回调模块，用于在接收到携带授权凭证的消费请求的情况下，基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态。

反馈模块，用于将登录态反馈至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

在一些实施例中，登录授权装置与第二应用的通用服务器对应，在所述第一应用触发授权认证请求，并确定待调用的第二应用的客户端为私有客户端的情况下，授权认证请求是被传输至第二应用的私有客户端对应的私有服务器，并通过私有服务器添加了回调地址后再传输至通用服务器的。

在一些实施例中，回调模块，还用于对消费请求中携带的授权凭证的状态进行验证，得到验证结果；若验证结果表征授权凭证的状态为有效状态，则执行基于与授权凭证相关联的回调地址，从私有服务器处获取与授权凭证相关联的登录态的步骤；将授权凭证的状态由有效状态调整为无效状态。

在一些实施例中，回调模块，还用于通过与授权凭证相关联的回调地址，向私有服务器发送信息获取请求；接收私有服务器基于信息获取请求返回的与授权凭证相关联的登录态。

在一些实施例中，第一关联模块，还用于若授权认证请求中不包括回调地址，则检查第二应用的通用客户端的安装状态；若第二应用的通用客户端的安装状态为已安装，则关联通用客户端的登录态以及授权凭证。

在一些实施例中，回调模块，还用于在接收到携带授权凭证的消费请求的情况下，确定与授权凭证相关联的关联信息；若关联信息为回调地址，则基于回调地址从私有服务器处获取与授权凭证相关联的登录态。

在一些实施例中，回调模块，还用于若关联信息为第二应用的通用客户端的登录态，则将登录态反馈至第一应用，以指示第一应用根据登录态以通用客户端的用户账号进行登录操作。

在一些实施例中，如图13所示，提供了一种登录授权装置1300，包括：响应模块1310、第二关联模块1320和传输模块1330，其中：

响应模块，用于响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，以指示通用服务器生成与授权认证请求适配的授权凭证，并关联回调地址与授权凭证。

第二关联模块，用于接收通用服务器反馈的授权凭证，关联授权凭证与第二应用的私有客户端的登录态，并将授权凭证传输至第一应用。

传输模块，用于接收通用服务器基于回调地址发起的信息获取请求，将与授权凭证关联的私有客户端的登录态传输至通用服务器；传输的私有客户端的登录态用于转发至第一应用，以指示第一应用根据登录态以私有客户端的用户账号进行登录操作。

在一些实施例中，响应模块，还用于响应于由第一应用触发的授权认证请求，检查第二应用的私有客户端的安装状态；若第二应用的私有客户端的安装状态为已安装，将回调地址发送至第二应用的通用服务器；在关联授权凭证与私有客户端的登录态之后，将登录态中的秘钥反馈至第二应用的私有客户端。

在一些实施例中，如图14所示，提供了一种登录授权装置1400，包括：第二生成模块1410、第二发送模块1420、第一接收模块1430、第二接收模块1440和登录模块1450，其中：

第二生成模块，用于响应于与第二应用关联的登录入口的触发操作，生成授权认证请求。

第二发送模块，用于确定第二应用的客户端类型，并通过与客户端类型匹配的目标客户端，将授权认证请求发送至第二应用的通用服务器，以指示通用服务器生成授权凭证。

第一接收模块，用于通过目标客户端，接收通用服务器生成的授权凭证。

第二接收模块，用于向通用服务器发送携带授权凭证的消费请求，并从通用服务器处接收与授权凭证关联的目标客户端的登录态。

登录模块，用于根据登录态以目标客户端的用户账号进行登录操作。

在一些实施例中，第二发送模块，用于若目标客户端为第二应用的私有客户端，则通过私有客户端，将授权认证请求发送至私有客户端关联的私有服务器，以指示私有服务器将回调地址以及授权认证请求传输至第二应用的通用服务器；若目标客户端为第二应用的通用客户端，通过通用客户端，直接将授权认证请求发送至通用客户端关联的通用服务器。

在一些实施例中，登录态包括用于对信息进行加密的秘钥，装置还包括分享模块，分享模块，用于响应于针对待分享信息的分享操作，基于秘钥，对待分享信息进行加密，得到加密结果；将加密结果发送至第二应用的目标客户端，以指示目标客户端通过秘钥对加密结果进行解密得到待分享信息，并发送待分享信息。

上述每个登录授权装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个示例性的实施例中，提供了一种计算机设备，该计算机设备可以是图1中的第二应用的通用服务器或第二应用的私有服务器，其内部结构图可以如图15所示。该计算机设备包括处理器、存储器、输入/输出接口（Input/Output，简称I/O）和通信接口。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储登录授权功能所需的数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种登录授权方法。

在一个示例性的实施例中，提供了一种计算机设备，该计算机设备可以是图1中的终端，其内部结构图可以如图16所示。该计算机设备包括处理器、存储器、输入/输出接口、通信接口、显示单元和输入装置。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口、显示单元和输入装置通过输入/输出接口连接到系统总线。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、NFC（近场通信）或其他技术实现。该计算机程序被处理器执行时以实现一种登录授权方法。该计算机设备的显示单元用于形成视觉可见的画面，可以是显示屏、投影装置或虚拟现实成像装置。显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图15或图16中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要符合相关规定。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-OnlyMemory，ROM）、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器（ReRAM）、磁变存储器（Magnetoresistive Random Access Memory，MRAM）、铁电存储器（Ferroelectric Random Access Memory，FRAM）、相变存储器（Phase Change Memory，PCM）、石墨烯存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random AccessMemory，SRAM）或动态随机存取存储器（Dynamic RandomAccess Memory，DRAM）等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims

1.一种登录授权方法，其特征在于，所述方法包括：

响应于由第一应用触发的授权认证请求，生成授权凭证；

2.根据权利要求1所述的方法，其特征在于，所述方法由第二应用的通用服务器执行，在所述第一应用触发授权认证请求，并确定待调用的第二应用的客户端为私有客户端的情况下，所述授权认证请求是被传输至所述第二应用的私有客户端对应的私有服务器，并通过所述私有服务器添加了回调地址后再传输至所述通用服务器的。

3.根据权利要求1所述的方法，其特征在于，在所述接收携带所述授权凭证的消费请求之后，所述方法还包括：

对消费请求中携带的授权凭证的状态进行验证，得到验证结果；

若验证结果表征所述授权凭证的状态为有效状态，则执行所述基于与所述授权凭证相关联的回调地址，从所述私有服务器处获取与所述授权凭证相关联的登录态的步骤；

将所述授权凭证的状态由有效状态调整为无效状态。

4.根据权利要求1所述的方法，其特征在于，所述基于与所述授权凭证相关联的回调地址，从所述私有服务器处获取与所述授权凭证相关联的登录态，包括：

通过与所述授权凭证相关联的回调地址，向所述私有服务器发送信息获取请求；

接收所述私有服务器基于所述信息获取请求返回的与所述授权凭证相关联的登录态。

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

若所述授权认证请求中不包括回调地址，则检查所述第二应用的通用客户端的安装状态；

若所述第二应用的通用客户端的安装状态为已安装，则关联所述通用客户端的登录态以及所述授权凭证。

6.根据权利要求5所述的方法，其特征在于，所述在接收到携带所述授权凭证的消费请求的情况下，基于与所述授权凭证相关联的回调地址，从所述私有服务器处获取与所述授权凭证相关联的登录态，包括：

在接收到携带所述授权凭证的消费请求的情况下，确定与所述授权凭证相关联的关联信息；

若所述关联信息为回调地址，则基于所述回调地址从所述私有服务器处获取与所述授权凭证相关联的登录态。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

若所述关联信息为所述第二应用的通用客户端的登录态，则将所述登录态反馈至所述第一应用，以指示所述第一应用根据所述登录态以所述通用客户端的用户账号进行登录操作。

8.一种登录授权方法，其特征在于，所述方法包括：

9.根据权利要求8所述的方法，其特征在于，所述响应于由第一应用触发的授权认证请求，将回调地址发送至第二应用的通用服务器，包括：

响应于由第一应用触发的授权认证请求，检查第二应用的私有客户端的安装状态；

若所述第二应用的私有客户端的安装状态为已安装，将回调地址发送至所述第二应用的通用服务器。

10.一种登录授权方法，其特征在于，所述方法包括：

11.根据权利要求10所述的方法，其特征在于，所述通过与所述客户端类型匹配的目标客户端，将所述授权认证请求发送至第二应用的通用服务器，包括：

若所述目标客户端为第二应用的私有客户端，则通过所述私有客户端，将所述授权认证请求发送至所述私有客户端关联的私有服务器，以指示所述私有服务器将回调地址以及所述授权认证请求传输至第二应用的通用服务器；所述回调地址用于指示所述通用服务器在接收到消费请求后，依据授权凭证从所述私有客户端对应的私有服务器处获取私有客户端的登录态；

若所述目标客户端为第二应用的通用客户端，通过所述通用客户端，直接将所述授权认证请求发送至所述通用客户端关联的通用服务器。

12.根据权利要求10至11任意一项所述的方法，其特征在于，所述登录态包括用于对信息进行加密的秘钥，所述方法还包括：

响应于针对待分享信息的分享操作，基于所述秘钥，对所述待分享信息进行加密，得到加密结果；

将所述加密结果发送至所述第二应用的目标客户端，以指示所述目标客户端通过所述秘钥对所述加密结果进行解密得到待分享信息，并发送所述待分享信息。

13.一种登录授权装置，其特征在于，所述装置包括：

14.一种登录授权装置，其特征在于，所述装置包括：

15.一种登录授权装置，其特征在于，所述装置包括：

16.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至12中任一项所述的方法的步骤。

17.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至12中任一项所述的方法的步骤。