获取账号授权信息的方法及装置与流程

本申请涉及账号授权技术领域，特别是涉及获取账号授权信息的方法及装置。

背景技术：

随着电子商务系统的快速发展，已经有越来越多的商家入驻到电子商务销售平台，根据经营类型及范围的不同，商家在电子商务销售平台中开设的店铺类型通常也会有多种。例如，可以包括旗舰店、专卖店、专营店等等。例如，旗舰店是指商家以自有品牌(商标为r或tm等状态)入驻某平台并开设的店铺，这种店铺的管理权为官方品牌商，通常，同一平台内只会有一家旗舰店。专卖店是指商家获得某品牌的授权后在某平台中开设的店铺，专卖店中只销售一个固定品牌的商品。专营店则是指销售同一招商大类下一个及以上品牌商品的店铺。也就是说，专营店可以卖多个品牌的商品，但是需要获得相应的品牌授权。可见，在同一平台内，可能会有多个店铺(例如，可能包括一个旗舰店、多个专卖店、专营店)同时售卖某个品牌的商品，每个店铺拥有自己的账号，店铺管理者可以通过自己的账号登录到平台，进行相关的数据的查看等操作。另外，对于某品牌商而言，可能会需要了解售卖其品牌的各个店铺中的相关情况，此时，还可以在平台中注册一集团账号，通过该集团账号查看相关的各个店铺的销售情况、会员数据、流量数据等统计数据。

在现有技术中，商家在注册各类店铺的账号或者集团账号时，平台都需要对申请者进行严格的资质审核。例如，如果需要注册旗舰店账号，至少需要提供以下证明材料：企业营业执照材料、纳税证明材料、法人代表身份证明材料、申请人身份证明材料、由相关管理部门颁发的商标注册证明材料，等等。如果需要注册专卖店账号或者专营店账号，除了上述证明材料，还需要提供正规的品牌授权证明材料。另外，如果需要注册集团账号，想证明在平台内有多个相关的店铺(包括旗舰店、专营店、专卖店)，并查看这些店铺的相关数据，也需 要提交很多的材料来分别证明自己拥有这些店铺。同时，平台方还需要经过层层的审核，才能最终确定是否允许开设对应的账号。另外，如果店铺需要做转移，还可能会产生纠纷或需要再次提交很多材料来证明店铺转移。总之，在现有技术的实现方案中，店铺之间的商务关系不方便管理，不够灵活。

技术实现要素：

本申请提供了获取账号授权信息的方法及装置，能够降低服务器侧审核工作的工作量，并保障审核结果的准确性。

本申请提供了如下方案：

一种获取账号授权信息的方法，包括：

服务器接收第一账号关联的第一客户端发送的获取第二账号授权信息的第一请求；

将所述第一请求转发至所述第二账号关联的第二客户端；

接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

一种获取账号授权信息的方法，包括：

第一客户端提供用于发起获取第二账号授权信息的操作界面；其中，所述第一客户端与第一账号关联；

通过所述操作界面接收第一用户的操作，并确定目标第二账号；

向服务器发送获取第二账号授权信息的第一请求，以便所述服务器将所述第一请求转发至所述第二账号关联的第二客户端，并在接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

一种账号授权方法，包括：

第二客户端接收服务器发送的第一请求，所述第一请求为第一客户端发起的获取第二账号授权信息的请求，所述第一客户端与第一账号关联；

对所述第一请求进行审核后，向服务器返回第一响应信息，以便所述服务器记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

一种获取账号授权信息的装置，应用于服务器，包括：

第一请求接收单元，用于接收第一账号关联的第一客户端发送的获取第二账号授权信息的第一请求；

转发单元，用于将所述第一请求转发至所述第二账号关联的第二客户端；

记录单元，用于接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

一种获取账号授权信息的装置，应用于第一客户端，包括：

操作界面提供单元，用于提供用于发起获取第二账号授权信息的操作界面；其中，所述第一客户端与第一账号关联；

第二账号确定单元，用于通过所述操作界面接收第一用户的操作，并确定目标第二账号；

第一请求发送单元，用于向服务器发送获取第二账号授权信息的第一请求，以便所述服务器将所述第一请求转发至所述第二账号关联的第二客户端，并在接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

一种账号授权装置，应用于第二客户端，包括：

第一请求接收单元，用于接收服务器发送的第一请求，所述第一请求为第一客户端发起的获取第二账号授权信息的请求，所述第一客户端与第一账号关联；

响应单元，用于对所述第一请求进行审核后，向服务器返回第一响应信息，以便所述服务器记录所述第一响应消息中携带的授权信息与所述第一账号之 间的对应关系。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，如果第一账号想要获得关于第二账号在某方面的权限，则可以直接通过服务器向第二账号所在的客户端发送授权请求，第二账号客户都在接收到请求后，可以对第一账号进行相应的审核等相关操作，审核通过后，就可以向服务器返回相应的授权结果，由服务器进行记录。也就是说，在本申请实施例中，提供了一种“信用账号授权体系”，在该体系中，将原本由服务器执行的审核操作转移到第二账号侧进行，换言之，由第二账号相应的管理人员代为执行相关的审核工作。这样，一方面可以降低服务器侧审核工作的工作量，提高效率，另一方面，由第二账号进行审核这种方式也更为合理，可以保障审核结果的准确性。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

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

图1是本申请实施例提供的第一方法的流程图；

图2是本申请实施例提供的第二方法的流程图；

图3是本申请实施例提供的第三方法的流程图；

图4是本申请实施例提供的第一装置的示意图；

图5是本申请实施例提供的第二装置的示意图；

图6是本申请实施例提供的第三装置的示意图。

具体实施方式

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

在本申请实施例中，如果第一账号想要获得关于第二账号在某方面的权限，则可以直接通过服务器向第二账号所在的客户端发送授权请求，第二账号客户都在接收到请求后，可以对第一账号进行相应的审核等相关操作，审核通过后，就可以向服务器返回相应的授权结果，由服务器进行记录。也就是说，在本申请实施例中，提供了一种“信用账号授权体系”，在该体系中，将原本由服务器执行的审核操作转移到第二账号侧进行，换言之，由第二账号相应的管理人员代为执行相关的审核工作。这样，一方面可以降低服务器侧审核工作的工作量，提高效率，另一方面，由第二账号进行审核这种方式也更为合理，可以保障审核结果的准确性。

例如，一个集团想开设一个集团的账号体系，则在本申请实施例中，只需要注册一个第一账号id，接下来，该第一账号id的集团权限是由他们的第二账号(也即各类店铺账号，包括旗舰店、专营店、专卖店)授权给他的。通过店铺账号的信用授权，来识别出集团账号的权限。之后，如果店铺账号转移给其他管理者后，店铺账号的管理员还可以把这个授信取消。由此可以解决大量的人工审核的问题，也解决了企业关系经常变化的问题。

又如，某商家想要开设一家专卖店，销售某个品牌的商品，按照现有技术的方案，他需要向服务器提供非常多的证明，才可以证明其为这个品牌的代理人，有合格的资质。但如果使用本申请实施例中的信用账号授权体系，则只需要注册一个专卖店类型的第一账号，然后由该品牌的官方旗舰店对应的第二账号对其审核后，这家专卖店就可以快速开设起来了。

下面对具体的实现方案进行详细介绍。

实施例一

首先，该实施例一从服务器的角度对本申请实施例进行介绍。参见图1， 该实施例一提供了一种获取账号授权信息的方法，该方法可以包括以下步骤：

s101：服务器接收第一账号关联的第一客户端发送的获取第二账号授权信息的第一请求；

具体实现时，可以通过客户端为第一用户(例如商家用户等)提供用户账号注册的操作界面，在该操作界面中，第一用户可以选择待注册的账号类型，例如，是集团账号，还是店铺账号，如果是店铺账号，还可以选择注册旗舰店账号、专卖店账号或者专营店账号，等等。在注册了一第一账号后，如果需要获得与已有的第二账号相关的授权信息，则客户端还可以提供用于发起获取第二账号授权信息的操作界面，在该操作界面中，可以包括已有的第二账号信息供第一用户进行选择，或者，还可以提供用于搜索获取输入第二账号信息的操作选项，等等，总之，通过该操作界面，可以确定出目标第二账号。

需要说明的是，在具体实现时，在具体向第二账号获取授权信息时，获取的授权类型可以有多种，例如，其中一种授权类型可以是请求获取对第二账号关联的数据的操作权限，具体可以是对第二账号关联的部分获取全部数据进行查看等操作的权限，或者，另一种授权类型可以是获取第二账号关联品牌的品牌授权。其中，第一种情况通常下，第一账号通常为集团账号，第二账号通常为同一品牌关联的旗舰店账号、专卖店账号、专营店账号等等。而第二种情况下，第一账号通常为专卖店账号或者专营店账号，而第二账号通常为某品牌的旗舰店账号。

为此，在向第一账号关联的客户端提供操作界面时，可以根据第一账号类型的不同，提供不同的操作界面。具体的，如果第一账号是集团账号，则在操作界面中，可以提供用于输入、查询、选择品牌名称的操作选项，然后在接收到目标品牌名称后，返回与该品牌名称相关的已注册的各个店铺关联的第二账号供选择。当然，如果在注册第一账号时已经选择了具体的品牌信息，则可以直接在第一界面中列举出该品牌关联的各个店铺的第二账号。此时，第一用户可以选择其中的一个或者多个第二账号，然后向这个或者这些第二账号发起请求。

另外，在上述这种情况下，还可以通过上述操作界面对第一账号请求的权限范围进行确定，例如，还可以提供可选的数据类型、操作类型等。其中，数据类型可以包括通讯数据、用户数据(例如某第二账号有哪些会员用户等等)、流量数据(主要是指第二账号的流量渠道信息，例如包括来自外部网站的流量、来自自有网站的流量、来自搜索的流量、来自商品详情页的流量等等)、经营数据(包括销量、好评率等等)。操作类型可以包括查看、删除等，当然，在实际应用中，上述各种类型的数据通常是由服务器统计出来的，为了保证数据的准确性及有效性，允许第一账号获取的操作权限主要是指查询权限。总之，在第一账号为集团账号的情况下，通过操作界面可以确定出一个或多个目标第二账号，以及目标数据类型、操作类型等信息。之后，就可以向服务器发送第一请求，相应的，服务器接收到的第一请求，就可以是获取所述第二账号关联数据的操作权限的请求，该第一请求中携带有待获取权限的数据类型以及操作类型。

如果第一账号是专卖店或者专营店，则在操作界面中，同样可以提供用于输入、查询、选择品牌名称的操作选项，在接收到目标品牌名称后，可以返回该品牌的官方旗舰店的账号作为第二账号供选择。类似的，如果在注册第一账号时已经选择了具体的品牌信息，则可以直接在操作界面中展示出该品牌的官方旗舰店的第二账号。此时，第一用户可以选择目标第二账号，然后向这个第二账号发起第一请求。该第一请求为获取所述第二账号关联品牌的品牌授权的请求。需要说明的是，从业务角度而言，申请注册专卖店或者专营店的申请人通常需要具有公司的身份，也即个人用户不能注册，因此，在注册专卖店或者专营店账号时，通常还可以提供申请者的身份信息，相应的，在发送上述第一请求时，还可以携带上申请者的身份信息，以便第二账号客户端在接收到第一请求进行审核时，可以对申请者的身份信息进行审核，进而确定是否对其进行品牌授权。另外，由于从业务层面而言，专卖店只能销售一个品牌的商品，而专营店可以销售多个品牌的商品，因此，专卖店账号只能向一个品牌对应的旗舰店账号发起授权请求，而专营店账号可以向多个品牌对应的旗舰店发起授权请求。在第一请求中还可以携带上具体的店铺类型信息，旗舰店在审核时，还可以为不同类型的店铺授予不同的销售范围等，例如，专卖店可以销售全部商 品，专营店只有销售其部分商品的权限，等等。

s102：将所述第一请求转发至所述第二账号关联的第二客户端；

服务器在接收到前述第一请求后，就可以将该第一请求转发至第二账号关联的第二客户端，由第二客户端对第一账号进行审核，然后，根据审核结果确定是否授予对应的权限。其中，具体的审核方式可以根据第一账号与第二账号的实际情况而定。例如，在集团账号请求获取店铺账号授权的情况下，集团账号的管理人员可以预先与店铺账号的管理人员进行联系，表明身份后，告知将会利用某第一账号向其发送获取查看权限的请求，这样，店铺账号在接收到请求后，就可以直接返回授予相应权限的响应。或者，在专卖店或者专营店账号请求获得某品牌旗舰店的品牌授权的情况下，可以有旗舰店管理者对申请者的相关材料等通过线下等方式进行审核，或者，直接对申请者的公司身份等进行审核后即可为其授予相应的权限，等等。

s103：接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

第二账号在完成对第一账号的审核后，即可通过第二客户端向服务器返回第一响应消息，该第一响应消息中可以携带有最终的授权结果信息，例如，可以包括是否授予某项权限，等等。服务器在接收到响应消息后，可以将其中携带的授权信息与第一账号之间的对应关系进行保存。

在对上述对应关系进行保存后，还可以将响应的授权结果返回给第一客户端，第一账号就可以利用获得的权限进行后续的操作了。例如，集团账号在获得某店铺账号在查看流量数据的授权后，就可以发起查看该店铺账号的流量数据的请求，相应的，服务器就可以通过已经记录的对应关系，判断该集团账号是否具有查看该店铺账号流量数据的权限，如果有，则可以将该店铺账号关联的流量数据返回给第一客户端。其中，具体的流量数据可以通过“饼图”等进行表示，表达出各种渠道的流量分布比例等信息。也就是说，在这种情况下，服务器在接收到第一客户端发送的对指定第二账号关联的目标数据执行目标操作的第二请求时，可以根据所述记录的对应关系信息，判断所述第一客户端 关联的第一账号是否具有相应的权限，如果具有相应的权限，则可以向所述第一客户端返回相应的第二响应消息。其中的操作类型就可以包括查看操作。

其中，在实际应用中，如果一个集团账号获取到了查看多个店铺的某类型数据的权限，则该集团账号还可以同时发起查看这些店铺的某类型数据的请求，此时，服务器可以将这些店铺的数据进行汇总后返回给第一客户端。当然，在汇总之前仍然可以首先判断该集团账号是否已经获得了查看这些店铺账号相关数据的权限。也就是说，如果所述第二请求中请求查看多个第二账号关联的目标数据，则可以分别判断所述第一客户端关联的第一账号是否具有对各个第二账号关联的所述目标数据执行目标类型操作的权限，如果具有，则可以将各个第二账号关联的目标数据进行汇总后，返回所述第一客户端。

而对于专卖店或者专营店账号获得某品牌官方旗舰店品牌授权的情况下，在服务器记录了前述对应关系的情况下，专卖店或者专营店账号就可以向平台中发布具体的商品对象信息了。其中，服务器在接收到发布商品对象信息的第三请求时，可以确定出待发布商品对象的品牌信息，然后利用所述记录的对应关系，对所述第一客户端关联的第一账号是否具有该品牌销售权限进行判断，如果具有相应的权限，则允许其发布，如果不具有相应的权限，则可以返回其不具备相应权限等响应消息。

当然，在实际应用中，如果某店铺账号转移给其他管理者，则还可以将已经授予某集团账号的权限取消，或者如果某专卖店或者专营店等出现违规等现象，官方旗舰店也可以取消对对应账号的授权，等等。对于服务器而言，在接收到所述第二客户端发送的取消对所述第一账号的授权的操作指令时，可以将所述记录的对应关系删除。

总之，通过本申请实施例，如果第一账号想要获得关于第二账号在某方面的权限，则可以直接通过服务器向第二账号所在的客户端发送授权请求，第二账号客户都在接收到请求后，可以对第一账号进行相应的审核等相关操作，审核通过后，就可以向服务器返回相应的授权结果，由服务器进行记录。也就是说，在本申请实施例中，提供了一种“信用账号授权体系”，在该体系中，将原本由服务器执行的审核操作转移到第二账号侧进行，换言之，由第二账号相 应的管理人员代为执行相关的审核工作。这样，一方面可以降低服务器侧审核工作的工作量，提高效率，另一方面，由第二账号进行审核这种方式也更为合理，可以保障审核结果的准确性。

实施例二

该实施例二是与实施例一相对应的，从第一客户端的角度进行介绍。具体的，参见图2，该实施例二提供了一种获取账号授权信息的方法，该方法可以包括以下步骤：

s201：第一客户端提供用于发起获取第二账号授权信息的操作界面；其中，所述第一客户端与第一账号关联；

s202：通过所述操作界面接收第一用户的操作，并确定目标第二账号；

s203：向服务器发送获取第二账号授权信息的第一请求，以便所述服务器将所述第一请求转发至所述第二账号关联的第二客户端，并在接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

其中，具体在提供用于发起获取第二账号授权信息的操作界面，可以根据所述第一账号的类型确定待获取的授权类型(具体可以包括用于获取第二账号关联数据的操作权限，或者用于获取第二账号关联品牌的品牌授权等)，并基于该授权类型提供所述操作界面。

实施例三

该实施例三也是与实施例一相对应的，从第二客户端的角度进行介绍。具体的，参见图3，该实施例三提供了一种账号授权方法，该方法可以包括以下步骤：

s301：第二客户端接收服务器发送的第一请求，所述第一请求为第一客户 端发起的获取第二账号授权信息的请求，所述第一客户端与第一账号关联；

s302：对所述第一请求进行审核后，向服务器返回第一响应信息，以便所述服务器记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

具体实现时，第二客户端在接收到取消对所述第一账号的授权的操作指令时，还可以向所述服务器发送取消所述授权信息的通知消息，以便所述服务器根据所述通知消息，删除所述记录的对应关系。

需要说明的是，由于上述实施例二以及实施例三都是与实施例一相对应的，只是描述的角度有所不同，因此，相关的具体实现可以参见实施例一中的介绍，这里不再赘述。

与实施例一相对应，本申请实施例还提供了一种获取账号授权信息的装置，该装置应用于服务器，参见图4，该装置可以包括：

第一请求接收单元401，用于接收第一账号关联的第一客户端发送的获取第二账号授权信息的第一请求；

转发单元402，用于将所述第一请求转发至所述第二账号关联的第二客户端；

记录单元403，用于接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

其中，所述第一请求包括获取所述第二账号关联数据的操作权限的请求；所述第一请求中携带有待获取权限的数据类型以及操作类型，所述第一响应消息中携带的授权信息包括：授予所述第一账号相应操作权限的信息。

具体实现时，所述装置还可以包括：

第二请求接收单元，用于接收到第一客户端发送的对指定第二账号关联的目标数据执行目标操作的第二请求时，根据所述记录的对应关系信息，判断所 述第一客户端关联的第一账号是否具有相应的权限；

第二响应消息返回单元，用于如果具有相应的权限，则向所述第一客户端返回相应的第二响应消息。

其中，所述操作类型包括查看操作，此时，所述第二响应消息返回单元具体用于：

向所述第一客户端返回所述目标数据。

如果所述第二请求中请求查看多个第二账号关联的目标数据，则第二请求接收单元包括：

判断子单元，用于分别判断所述第一客户端关联的第一账号是否具有对各个第二账号关联的所述目标数据执行目标类型操作的权限；

则所述第二响应消息返回单元包括：

汇总子单元，用于如果具有，将各个第二账号关联的目标数据进行汇总后，返回所述第一客户端。

其中，所述数据类型包括所述第二账号关联的通讯数据、用户数据、流量数据和/或经营数据。

另一种情况下，所述第一请求包括获取所述第二账号关联品牌的品牌授权的请求，所述第一响应消息中携带的授权信息包括：授予所述第一账号相应品牌销售权限的信息。

此时，所述装置还可以包括：

第三请求接收单元，用于接收到第一客户端的发布商品对象信息的第三请求时，确定待发布商品对象的品牌信息，并利用所述记录的对应关系，对所述第一客户端关联的第一账号是否具有该品牌销售权限进行判断。

另外，所述装置还可以包括：

删除单元，用于接收到所述第二客户端发送的取消对所述第一账号的授权 的操作指令时，将所述记录的对应关系删除。

与实施例二相对应，本申请实施例还提供了一种获取账号授权信息的装置，该装置应用于第一客户端，参见图5，该装置可以包括：

操作界面提供单元501，用于提供用于发起获取第二账号授权信息的操作界面；其中，所述第一客户端与第一账号关联；

第二账号确定单元502，用于通过所述操作界面接收第一用户的操作，并确定目标第二账号；

第一请求发送单元503，用于向服务器发送获取第二账号授权信息的第一请求，以便所述服务器将所述第一请求转发至所述第二账号关联的第二客户端，并在接收到所述第二客户端返回的第一响应消息后，记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

其中，所述操作界面提供单元具体用于：

根据所述第一账号的类型确定待获取的授权类型，并基于该授权类型提供所述操作界面。

与实施例三相对应，本申请实施例还提供了一种账号授权装置，该装置应用于第二客户端，参见图6，该装置可以包括：

第一请求接收单元601，用于接收服务器发送的第一请求，所述第一请求为第一客户端发起的获取第二账号授权信息的请求，所述第一客户端与第一账号关联；

响应单元602，用于对所述第一请求进行审核后，向服务器返回第一响应信息，以便所述服务器记录所述第一响应消息中携带的授权信息与所述第一账号之间的对应关系。

具体实现时，该装置还可以包括：

取消指令接收单元，用于接收到取消对所述第一账号的授权的操作指令时，向所述服务器发送取消所述授权信息的通知消息，以便所述服务器根据所述通知消息，删除所述记录的对应关系。

通过本申请实施例，如果第一账号想要获得关于第二账号在某方面的权限，则可以直接通过服务器向第二账号所在的客户端发送授权请求，第二账号客户都在接收到请求后，可以对第一账号进行相应的审核等相关操作，审核通过后，就可以向服务器返回相应的授权结果，由服务器进行记录。也就是说，在本申请实施例中，提供了一种“信用账号授权体系”，在该体系中，将原本由服务器执行的审核操作转移到第二账号侧进行，换言之，由第二账号相应的管理人员代为执行相关的审核工作。这样，一方面可以降低服务器侧审核工作的工作量，提高效率，另一方面，由第二账号进行审核这种方式也更为合理，可以保障审核结果的准确性。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的获取账号授权信息的方法及装置，进行了详细介绍， 本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。