一种资源汇聚网关及跨平台授权方法与系统

本发明涉及电信能力开放平台，具体涉及一种基于资源汇聚网关的跨平 台授权方法与系统，以及一种资源汇聚网关。

随着Web2.0的蓬勃发展，用户参与意识得到了前所未有的提升。为更 好地实现与用户的交互并满足不同用户的个性化诉求，电信领域和互联网领 域都相继推出了自己的开放平台。应该承认，这种积极的举措对于推动移动 互联网产业的发展确实起到了至关重要的作用。但是，也应该注意到无论是 电信运营商还是互联网平台商，孤立的能力或资源的提供方式，已经越来越 不能适应移动互联网时代用户对个性化和多样化融合业务的需要。

为应对这种不利的局面，业界提出了基于资源汇聚网关来统一开放电信 网络能力和互联网用户资源的策略。这种方案带来的好处主要表现在两个方 面：其一是简化了开发者融合业务开发的流程；其二是有效缓解了资源汇聚 网关在大访问量下的负载压力。不过，需要指出的是，基于资源汇聚网关实 现电信能力和互联网用户资源统一开放的方案当中，只考虑到了公有的互联 网用户资源的调用情形，而没有针对融合业务开发当中需要调用第三方互联 网平台上用户隐私信息时的具体授权机制。

在实际的应用中，随着用户参与度的加强，往往有很多融合业务需要牵 涉到第三方互联网平台上用户隐私信息的调用。现有技术中无相关解决方案。

本发明要解决的技术问题是提供一种基于资源汇聚网关的跨平台授权方 法和系统，以及一种资源汇聚网关，实现对第三方开放平台资源的调用。

为了解决上述问题，本发明提供了一种基于资源汇聚网关的跨平台授权 方法，包括：

资源汇聚网关接收到应用发送的第三方开放平台上的用户信息授权请求 后，转发给所述第三方开放平台；

所述第三方开放平台接收到所述用户信息授权请求后，引导用户授权并 返回授权码给所述资源汇聚网关，所述资源汇聚网关将所述授权码返回给所 述应用；或者，所述第三方开放平台接收到所述用户信息授权请求后，引导 用户授权并返回所述授权码给所述应用；

所述资源汇聚网关携带所述应用发送的授权码向所述第三方开放平台申 请访问令牌，并将获取的访问令牌返回给所述应用；

所述资源汇聚网关携带所述应用发送的所述访问令牌向所述第三方开放 平台申请相应的用户信息，并将获取的用户信息返回给所述应用。

进一步的，上述方法还可具有以下特点：

所述资源汇聚网关接收所述应用发送的未经用户授权的请求令牌申请 后，转发给第三方开放平台；以及，接收所述第三方开放平台返回的请求令 牌，并将所述请求令牌发送给所述应用；

所述应用发送的所述用户信息授权请求中携带所述请求令牌，所述资源 汇聚网关转发给所述第三方开放平台的用户信息授权请求中携带所述请求令 牌。

进一步的，上述方法还可具有以下特点：

所述应用发送的所述请求令牌申请中，携带电信运营商开放平台颁发的 应用标识；

所述资源汇聚网关转发所述请求令牌申请给所述第三方开放平台时，携 带所述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述方法还可具有以下特点：

所述应用发送的所述用户信息授权请求中，携带所述应用在电信运营商 开放平台注册的用于接收所述授权码的接收地址和应用标识；

所述资源汇聚网关转发所述用户信息授权请求给所述第三方开放平台 时，携带所述应用在所述电信运营商开放平台注册的用于接收所述授权码的 接收地址和所述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述方法还可具有以下特点：

所述资源汇聚网关与所述第三方开放平台之间按事先约定的密钥和加密 算法传输所述用户信息授权请求。

进一步的，上述方法还可具有以下特点：

所述应用发送的所述用户信息授权请求中，携带所述应用在电信运营商 开放平台注册的用于接收所述授权码的接收地址和应用标识；

所述资源汇聚网关转发所述用户信息授权请求给所述第三方开放平台 时，携带所述资源汇聚网关在所述第三方开放平台注册的用于接收所述授权 码的接收地址和所述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述方法还可具有以下特点：

所述资源汇聚网关与所述第三方开放平台的交互过程中，使用事先约定 的密钥和加密算法进行加解密。

进一步的，上述方法还可具有以下特点：

所述资源汇聚网关接收到所述用户信息授权请求后，创建与所述应用对 应的会话标识；或者，接收到所述应用发送的请求令牌申请后，创建与所述 应用对应的会话标识；

所述资源汇聚网关转发与所述应用相关的消息给所述第三方开放平台 时，携带所述会话标识；

所述资源汇聚网关是根据如下方式将与所述应用相关的信息发送给所述 应用：所述资源汇聚网关接收所述第三方开放平台返回的与所述应用相关的 信息和会话标识，根据所述会话标识与所述应用之间的对应关系，将与所述 应用相关的信息发送给所述应用；

所述与所述应用相关的消息包括：请求令牌申请、用户信息授权请求、 申请访问令牌和申请用户信息；或者，包括：用户信息授权请求、申请访问 令牌和申请用户信息；所述与所述应用相关的信息包括：请求令牌、授权码、 访问令牌和用户信息；或者，包括：授权码、访问令牌和用户信息。

本发明还提供一种资源汇聚网关，包括：

处理模块，用于接收应用发送的请求，在检测到该请求对应的资源位于 第三方开放平台上时，将该请求转发给授权管理模块；所述请求包括用户信 息授权请求、申请访问令牌请求和申请用户信息请求；

授权管理模块，用于确认所述第三方开放平台所支持的OAuth版本类型， 将所述第三方开放平台的OAuth版本信息发送给授权模块；以及，将所述用 户信息授权请求、申请访问令牌请求和所述申请用户信息请求转发给所述授 权模块；

授权模块，用于接收所述授权管理模块下发的用户信息授权请求后，将 所述用户信息授权请求转发给第三方开放平台；以及，接收所述授权管理模 块下发的申请访问令牌请求后，携带所述应用发送的授权码向所述第三方开 放平台申请访问令牌，并将获取的访问令牌返回给所述应用；以及，接收所 述授权管理模块下发的申请用户信息请求后，携带所述应用发送的所述访问 令牌向所述第三方开放平台申请相应的用户信息，并将获取的用户信息返回 给所述应用。

进一步的，上述资源汇聚网关还可具有以下特点，

所述处理模块还用于，接收所述应用发送的未经用户授权的请求令牌申 请后，将该请求令牌申请转发给所述授权管理模块；

所述授权管理模块还用于，将所述请求令牌申请转发给所述授权模块；

所述授权模块还用于，接收到所述授权管理模块下放的所述请求令牌申 请后，转发给第三方开放平台；接收所述第三方开放平台返回的请求令牌， 并将所述请求令牌发送给所述应用；以及，在转发给所述第三方开放平台的 用户信息授权请求中携带所述请求令牌。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块转发所述请求令牌申请给所述第三方开放平台时，携带所 述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块转发所述用户信息授权请求给所述第三方开放平台时，携 带所述应用在电信运营商开放平台注册的用于接收所述授权码的接收地址和 所述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块与所述第三方开放平台之间按事先约定的密钥和加密算法 传输所述用户信息授权请求。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块转发所述用户信息授权请求给所述第三方开放平台时，携 带所述资源汇聚网关在所述第三方开放平台注册的用于接收所述授权码的接 收地址和所述第三方开放平台颁发给所述资源汇聚网关的标识。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块与所述第三方开放平台的交互过程中，使用事先约定的密 钥和加密算法进行加解密。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权模块还用于，接收所述第三方开放平台引导用户授权后返回的 授权码，并将所述授权码返回给所述应用。

进一步的，上述资源汇聚网关还可具有以下特点，

所述授权管理模块还用于：收到所述用户信息授权请求后，创建与所述 应用对应的会话标识，或者，接收到所述应用发送的请求令牌申请后，创建 与所述应用对应的会话标识；在转发所述用户信息授权请求或请求令牌申请 给所述授权模块时，携带所述会话标识；

所述授权模块还用于，转发与所述应用相关的消息给所述第三方开放平 台时，携带所述会话标识；以及，接收所述第三方开放平台返回的与所述应 用相关的信息和会话标识后，根据所述会话标识与所述应用之间的对应关系， 将与所述应用相关的信息发送给所述应用；

其中，所述与所述应用相关的消息包括：请求令牌申请、用户信息授权 请求、申请访问令牌和申请用户信息；或者包括：用户信息授权请求、申请 访问令牌和申请用户信息；所述与所述应用相关的信息包括：请求令牌、授 权码、访问令牌和用户信息；或者包括：授权码、访问令牌和用户信息。

本发明还提供一种基于资源汇聚网关的跨平台授权系统，包括上述资源 汇聚网关，还包括第三方开放平台，其中：

所述第三方开放平台用于，接收到所述用户信息授权请求后，引导用户 授权并返回授权码给所述资源汇聚网关；或者，所述第三方开放平台接收到 所述用户信息授权请求后，引导用户授权并返回所述授权码给所述应用。

本发明提供的方法和系统，实现了对第三方开放平台资源的调用。

图1是跨平台授权的参与各方示意图；

图2是跨平台授权参与方的基本调用关系图；

图3是资源汇聚网关内部示意图；

图4是非加密传输方式下的跨平台OAuth1.0a授权流程；

图5是加密传输方式下的跨平台OAuth1.0a授权流程；

图6是非加密传输方式下的跨平台OAuth2.0授权流程；

图7是加密传输方式下的跨平台OAuth2.0授权流程。

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图 对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申 请中的实施例及实施例中的特征可以相互任意组合。

本发明实施例中提供了一种用于基于资源汇聚网关的跨平台授权系统， 该系统中，包括应用、资源汇聚网关、第三方开放平台和电信能力引擎。应 用可以是开发者/SP(Service Provider，服务提供商)的应用。

对于开发者/SP应用来说，需要通过资源汇聚网关调用两类能力：一类 是电信能力引擎提供的电信能力；另一类则是经资源汇聚网关从第三方开放 平台引入的用户私有资源。其中，第二类资源的获取具有跨平台的特点。

为了简化开发者的业务开发流程和复杂度，资源汇聚网关需要结合互联 网用户资源的OAuth认证授权特点，进行必要的改进和优化，以便将这种跨 平台的授权流程做到向开发者/SP透明。

具体来说，可以分成两种视角来阐述这一过程：在开发者/SP的应用看 来，它所需要调用的所有能力和资源都是向电信运营商的资源汇聚网关申请， 并从所述资源汇聚网关获取相应的结果。也就是说，它根本无需关心，当前 所申请的能力和资源到底是运营商平台本身提供的，还是从第三方开放平台 获取到的。在资源汇聚网关看来，当它发现开发者/SP的应用为申请用户私 有资源向自己的请求令牌地址、授权地址和访问令牌地址发出请求令牌申请、 用户信息授权请求和申请访问令牌时，会将这些请求向用户资源的实际所在 地的请求令牌地址、授权地址和访问令牌地址依次发送，并将返回的结果转 发给开发者/SP的应用。

为达成上述目标，需要对当前的资源汇聚网关在跨平台授权方面加以改 进。具体来说，在资源汇聚网关当中，要引入授权模块，该模块负责按照 OAuth1.0a和OAuth2.0版本的流程进行二次封装，将资源汇聚网关向开发者 /SP提供的请求令牌地址、授权地址和访问令牌地址转换成资源汇聚网关向 用户资源真正所在地的第三方开放平台的相应地址进行请求。为使跨平台授 权流程正常进行，还需要引入授权管理模块来维护用户资源与第三方开放平 台之间的对应关系、对应平台上使用的OAuth版本类型以及同一次会话当中 会话ID(ReqID)与应用的对应关系。

这个过程中，开发者/SP应用向资源汇聚网关的授权地址发送用户信息 授权请求时，需要附带从电信运营商开放平台申请的api_key和它在电信运 营商开放平台注册过的授权码接收地址(redirct_url)，api_key用来标识应 用本身的合法性，redirect_url则用来接收最终从用户资源所在地返回的授权 码CODE。

电信运营商开放平台是指用于实现运营商自有电信能力和其他互联网资 源以API的方式统一开放给第三方应用的系统统称，业界的产品实现上一般 称之为SDP(Service Delivery Platform，业务交付平台)。资源汇聚网关是 电信运营商开放平台的一个组成部分。它主要负责能力和资源的聚合和开放， 第三方应用的api_key等由电信运营商开放平台里的管理模块颁发。

资源汇聚网关在进行授权转发时，需要附带第三方开放平台颁发的 api_key和接收地址(redirect_url)。其中，redirect_url在不同的场景下，对 应不同的选择。当申请的用户资源不涉及指定的业务数据和个人信息时，传 输过程无需进行加密处理，redirect_url直接选择开发者/SP应用提交给电信 运营商开放平台的redirect_url即可；否则需要提交电信运营商开放平台向第 三方开放平台注册的redirect_url。指定的业务数据和个人信息可以是重要的 业务数据和个人信息。

这里，需要特别指出的是，电信运营商开放平台向开发者/SP颁发的 api_key在访问次数限制上(SLA，Service-Level Agreement，服务等级协 议)需要与第三方开放平台颁发给资源汇聚网关的api_key相适配。理想情 况下，只要资源汇聚网关在单位时间内访问第三方开放平台的次数与开发者 /SP应用单位时间内提交访问请求的次数以及开发者/SP的应用个数三者之 间相适配(开发者/SP应用个数*单位时间内访问次数＜＝资源汇聚网关允许在 单位时间内的访问第三方开放平台的次数)，就可以保障系统的正常运转。

在现实运营当中，一方面应用在运营的不同阶段或时间段往往会有不同 的SLA需求，另一方面开发者人数和应用个数都是在不断变化的过程当中。 这样，就导致无法非常精确地将资源汇聚网关的SLA与应用的SLA对应起 来。为缓解这种矛盾，一种可行的方案是资源汇聚网关事先与第三方开放平 台达成相应的SLA协议，该SLA协议既能够充分保障资源汇聚网关逐步增 长的访问频次需要，又能够提供与之相适应的QoS(服务质量)。

本发明实施例提供一种基于资源汇聚网关的跨平台授权方法，包括：

资源汇聚网关接收到应用发送的第三方开放平台上的用户信息授权请求 后，转发给第三方开放平台；

所述第三方开放平台接收到所述用户信息授权请求后，引导用户授权并 返回授权码给所述资源汇聚网关，所述资源汇聚网关将所述授权码返回给所 述应用；或者，所述第三方开放平台接收到所述用户信息授权请求后，引导 用户授权并返回所述授权码给所述应用；

所述资源汇聚网关携带所述应用发送的所述授权码向所述第三方开放平 台申请访问令牌，并将获取的访问令牌返回给所述应用；

所述资源汇聚网关携带所述应用发送的所述访问令牌向所述第三方开放 平台申请相应的用户信息，并将获取的用户信息返回给所述应用。

其中，所述方法还包括：资源汇聚网关接收所述应用发送的未经用户授 权的请求令牌申请，转发给第三方开放平台；接收所述第三方开放平台返回 的请求令牌，并将所述请求令牌返回给所述应用。所述应用发送的所述用户 信息授权请求中携带所述请求令牌，所述资源汇聚网关转发给所述第三方开 放平台的用户信息授权请求中携带所述请求令牌。

其中，所述应用发送的所述请求令牌申请中，携带电信运营商开放平台 颁发的应用标识；所述资源汇聚网关转发所述请求令牌申请给所述第三方开 放平台时，携带第三方开放平台颁发给所述资源汇聚网关的标识。

其中，所述应用发送的所述用户信息授权请求中，携带所述应用在电信 运营商开放平台注册的用于接收所述授权码的接收地址和应用标识；或者， 携带所述应用在电信运营商开放平台注册的用于接收所述授权码的接收地 址、应用标识和所述请求令牌；

所述资源汇聚网关转发所述用户信息授权请求给所述第三方开放平台 时，携带所述应用在所述电信运营商开放平台注册的用于接收所述授权码的 接收地址和第三方开放平台颁发给资源汇聚网关的标识；或者，携带所述应 用在所述电信运营商开放平台注册的用于接收所述授权码的接收地址、第三 方开放平台颁发给资源汇聚网关的标识和所述请求令牌。

其中，所述应用发送的所述用户信息授权请求中，携带所述应用在电信 运营商开放平台注册的用于接收所述授权码的接收地址和应用标识；或者， 携带所述应用在电信运营商开放平台注册的用于接收所述授权码的接收地 址、应用标识和所述请求令牌；

所述资源汇聚网关转发所述用户信息授权请求给所述第三方开放平台 时，携带所述资源汇聚网关在所述第三方开放平台注册的用于接收所述授权 码的接收地址和第三方开放平台颁发给资源汇聚网关的标识；或者，携带所 述资源汇聚网关在所述第三方开放平台注册的用于接收所述授权码的接收地 址、第三方开放平台颁发给资源汇聚网关的标识和所述请求令牌。

其中，所述资源汇聚网关与所述第三方开放平台之间按事先约定的密钥 和加密算法传输所述用户信息授权请求。

其中，所述资源汇聚网关与所述第三方开放平台的交互过程中，使用事 先约定的密钥和加密算法进行加解密。即交互的全程中，进行加密。

其中，所述资源汇聚网关收到所述用户信息授权请求后，创建与所述应 用对应的会话标识；或者，所述资源汇聚网关收到所述请求令牌申请后，创 建与所述应用对应的会话标识；

所述资源汇聚网关转发与所述应用相关的消息给所述第三方开放平台 时，携带所述会话标识；

所述资源汇聚网关是根据如下方式将与所述应用相关的信息发送给所述 应用：所述资源汇聚网关接收所述第三方开放平台返回的与所述应用相关的 信息和会话标识，根据所述会话标识与所述应用之间的对应关系，将与所述 应用相关的信息发送给所述应用；

所述与所述应用相关的消息包括：请求令牌申请、用户信息授权请求、 申请访问令牌和申请用户信息；或者，包括：用户信息授权请求、申请访问 令牌和申请用户信息；所述与所述应用相关的信息包括：请求令牌、授权码、 访问令牌和用户信息；或者，包括：授权码、访问令牌和用户信息。

本发明实施例以电信运营商开放平台上的融合业务为实施例，来具体阐 述基于资源汇聚网关的跨平台授权流程。考虑到主流的开放平台支持两种版 本的OAuth认证授权流程，而从传输过程是否需要加密，又分为加密方式下 和非加密方式下的认证授权方案。基于此，可组合出四种跨平台的授权方法。

在图1所示的跨平台授权参与方中，包括融合应用的使用者(即用户 101)、应用102、资源汇聚网关103、第三方开放平台104和电信能力引擎 105。

图2所示的跨平台授权参与方的基本调用关系可用如下步骤来描述：

1)用户101启动应用102；

2)应用102向资源汇聚网关103提交能力和资源调用请求；

3)资源汇聚网关103将电信能力的调用请求下发给相应的电信能力引擎 105；

4)资源汇聚网关103将第三方开放平台的用户资源请求转发给第三方开 放平台104；

5)电信能力引擎105返回调用结果给资源汇聚网关103；

6)第三方开放平台104引导用户授权并返回相应的用户信息给资源汇聚 网关103；

7)资源汇聚网关103将用户信息返回给应用102；

8)应用102将结果呈现给用户101，完成用户交互。

为完成图2所示的流程，资源汇聚网关103需要具备图3所示的功能模 块。包括：接收模块301、鉴权模块302、SLA模块303、处理模块304、计 费模块305、授权管理模块306和授权模块307。其中：

接收模块301用于接收外部请求和返回响应结果。

鉴权模块302和SLA模块303分别完成用户、应用的鉴权和SLA控制。

处理模块304用于实现能力调用的相关逻辑：如果是电信能力调用，将 请求下发给电信能力引擎105，如果是第三方私有资源获取请求，则将请求 下发给授权管理模块306；所述请求包括用户信息授权请求、申请访问令牌 请求和申请用户信息请求；

授权管理模块306用于确认所述第三方开放平台所支持的OAuth版本类 型，将所述第三方开放平台的OAuth版本信息发送给授权模块；以及，将所 述用户信息授权请求、申请访问令牌请求和所述申请用户信息请求转发给所 述授权模块；

授权模块307，用于接收所述授权管理模块下发的用户信息授权请求后， 将所述用户信息授权请求转发给第三方开放平台；以及，接收所述授权管理 模块下发的申请访问令牌请求后，携带所述应用发送的授权码向所述第三方 开放平台申请访问令牌，并将获取的访问令牌返回给所述应用；以及，接收 所述授权管理模块下发的申请用户信息请求后，携带所述应用发送的所述访 问令牌向所述第三方开放平台申请相应的用户信息，并将获取的用户信息返 回给所述应用。

计费模块305用于完成相应的计费操作。

授权管理模块306还负责维护reqID和应用之间的对应关系。

其中，所述处理模块304还用于，接收所述应用发送的未经用户授权的 请求令牌申请后，将该请求令牌申请转发给所述授权管理模块；

所述授权管理模块306还用于，将所述请求令牌申请转发给所述授权模 块；

所述授权模块307还用于，接收到所述授权管理模块下放的所述请求令 牌申请后，转发给第三方开放平台；接收所述第三方开放平台返回的请求令 牌，并将所述请求令牌发送给所述应用；以及，在转发给所述第三方开放平 台的用户信息授权请求中携带所述请求令牌。所述授权模块307转发所述请 求令牌申请给所述第三方开放平台时，携带所述第三方开放平台颁发给所述 资源汇聚网关的标识。

其中，所述授权模块307转发所述用户信息授权请求给所述第三方开放 平台时，携带所述应用在电信运营商开放平台注册的用于接收所述授权码的 接收地址和所述第三方开放平台颁发给所述资源汇聚网关的标识。所述授权 模块307与所述第三方开放平台之间按事先约定的密钥和加密算法传输所述 用户信息授权请求。

其中，所述授权模块307转发所述用户信息授权请求给所述第三方开放 平台时，携带所述资源汇聚网关在所述第三方开放平台注册的用于接收所述 授权码的接收地址和所述第三方开放平台颁发给所述资源汇聚网关的标识。 所述授权模块307与所述第三方开放平台的交互过程中，使用事先约定的密 钥和加密算法进行加解密。

所述授权模块307还用于，接收所述第三方开放平台引导用户授权后返 回的授权码，并将所述授权码返回给所述应用。

所述授权管理模块306用于：收到所述用户信息授权请求后，创建与所 述应用对应的会话标识，或者，接收到所述应用发送的请求令牌申请后，创 建与所述应用对应的会话标识；在转发所述用户信息授权请求或请求令牌申 请给所述授权模块307时，携带所述会话标识；

所述授权模块307还用于，转发与所述应用相关的消息给所述第三方开 放平台时，携带所述会话标识；以及，接收所述第三方开放平台返回的与所 述应用相关的信息和会话标识后，根据所述会话标识与所述应用之间的对应 关系，将与所述应用相关的信息发送给所述应用；

其中，所述与所述应用相关的消息包括：请求令牌申请、用户信息授权 请求、申请访问令牌和申请用户信息；或者包括：用户信息授权请求、申请 访问令牌和申请用户信息；所述与所述应用相关的信息包括：请求令牌、授 权码、访问令牌和用户信息；或者包括：授权码、访问令牌和用户信息。

下面通过具体实施例进一步说明本发明。

根据传输过程当中是否需要加密处理，跨平台授权又分为非加密传输方 式下跨平台OAuth1.0a授权和加密传输模式下跨平台OAuth1.0a授权两种不 同的流程，分别如图4和图5所示。

在图4中，一个完整的非加密传输方式下OAuth1.0a跨平台授权流程如 下：

401)开发者/SP的应用向资源汇聚网关的请求令牌地址申请请求令牌， 请求参数中包括电信运营商开放平台颁发给应用的api_key；

开发者/SP向电信运营商开放平台注册应用时，运营商在审核后会颁发 与之对应的api_key和api_secret来唯一标识该应用。在用户使用应用的过程 中，一旦涉及到电信运营商开放平台上能力和资源的调用，都需要携带 api_key和/或api_secret，这样电信运营商开放平台就可以知道是哪个应用发 来的请求，而后据此进行收费和SLA控制等。

402)资源汇聚网关接收到请求令牌申请请求后，它会把该请求及其后续 的信息获取过程看作是一次会话，并动态生成一个与应用唯一对应的会话标 识reqID，然后将该请求令牌申请请求进行转发，提交给第三方开放平台的 请求令牌申请地址，请求参数中包括第三方开放平台颁发给资源汇聚网关的 api_key和reqID；

403)第三方开放平台生成请求令牌request_token并返回给资源汇聚网 关，同时返回的还有会话标识reqID；

404)资源汇聚网关根据reqID和应用的对应关系，将请求令牌 request_token返回给应用；

405)开发者/SP的应用向资源汇聚网关的授权地址请求用户授权，请 求参数中包括电信运营商开放平台颁发给应用的api_key、上一步获取的请求 令牌request_token和用于接收授权码的redirect_url；

redirect_url是基于OAuth进行授权的机制当中特有的参数，它本身是一 个url(如http://www.exam/index)，由开发者/SP提供，它的作用是告 诉请求的响应方，用户完成授权后反馈回来的授权码(CODE)应该向哪个 地址发送。通常在开发者/SP向电信运营商开放平台注册应用时，需要提交 这个参数。这样做的目的是，当电信运营商开放平台发现开发者/SP每次请 求当中提交的redirect_url与其注册时提供的redirect_url不一致时，就认为是 非法的钓鱼操作而不予处理，进而降低用户资源被非法使用的风险(防止 api_key和api_secret被盗用)。

406)资源汇聚网关接收到用户信息授权请求后，将该用户信息授权请求 进行转发，提交给第三方开放平台的授权地址，请求参数中包括第三方开放 平台颁发给资源汇聚网关的api_key和应用提供的redirect_url、request_token。 由于redirect_url是动态提供的(不同的应用对应不同的redirect_url)，而通 常情况下第三方开放平台需要根据应用注册时提供的redirect_url与请求当中 的redirect_url做比较以防止非法钓鱼操作。解决这种矛盾的方法是：资源汇 聚网关与第三方开放平台之间需要事先约定好发送用户信息授权请求时的加 密算法和密钥，实现该请求的加密传输；

407)第三方开放平台解密资源汇聚网关发出的用户信息授权请求，引导 用户登录和授权；

408)用户使用自己的账号在第三方开放平台登录页面登录，并进行相应 的授权操作；

409)第三方开放平台向应用的redirct_url返回授权码CODE；

410)应用获取授权码CODE，并向资源汇聚网关的访问令牌地址发出请 求，请求参数包括电信运营商开放平台颁发的api_key、api_secret和授权码 CODE；

411)资源汇聚网关向第三方开放平台的访问令牌地址发出请求，请求参 数包括第三方开放平台颁发给资源汇聚网关的api_key、api_secret、应用提供 的授权码CODE和本次会话的reqID；

412)第三方开放平台接收资源汇聚网关的请求信息，生成访问令牌 (access_token)并与reqID一起返回给资源汇聚网关；

413)资源汇聚网关根据reqID与应用的映射关系，将access_token返回 给应用；

414)应用向资源汇聚网关请求用户信息，请求参数包括access_token；

所述用户信息包括当前授权用户在第三方开放平台上的个人信息，比如 个人简介、好友等。

415)资源汇聚网关向第三方开放平台请求用户信息，请求参数包括 access_token和reqID；

416)第三方开放平台返回用户信息给资源汇聚网关，返回结果中包括 reqID；

417)资源汇聚网关返回用户信息给与reqID相对应的应用，应用呈现融 合业务给用户。

在安全加密传输的场景下，跨平台授权流程需要稍作修改，如图5所示， 包括：

501)开发者/SP的应用向资源汇聚网关的请求令牌地址申请请求令牌， 请求参数中包括电信运营商开放平台颁发给应用的api_key；

502)资源汇聚网关接收到请求令牌申请请求后，它会把该请求及其后续 的信息获取过程看作是一次会话，并动态生成一个与应用唯一对应的会话标 识reqID，然后将该请求令牌申请请求进行转发，提交给第三方开放平台的 请求令牌申请地址，请求参数中包括第三方开放平台颁发给资源汇聚网关的 api_key和reqID。在资源汇聚网关与第三方开放平台之间，按事先约定好的 密钥和加密算法加密传输上述信息；

503)第三方开放平台解密资源汇聚网关发送过来的请求令牌申请请求， 生成请求令牌request_token并以加密的方式返回给资源汇聚网关，同时返回 的还有会话标识reqID；

504)资源汇聚网关解密后，根据reqID和应用的对应关系，将请求令牌 request_token返回给应用；

505)开发者/SP的应用向资源汇聚网关的授权地址请求用户授权，请求 参数中包括电信运营商开放平台颁发给应用的api_key、上一步获取到的 request_token和用于接收授权码的redirect_url；

506)资源汇聚网关将该授权请求进行转发，提交给第三方开放平台的授 权地址，请求参数中包括第三方开放平台颁发给资源汇聚网关的api_key、应 用提交的request_token、资源汇聚网关向第三方开放平台注册的redirect_url 和会话标识reqID。在资源汇聚网关与第三方开放平台之间，按事先约定好 的密钥和加密算法加密传输上述信息；

507)第三方开放平台解密资源汇聚网关发出的用户信息授权请求，引导 用户登录和授权；

508)用户使用自己的账号在第三方开放平台登录页面登录，并进行相应 的授权操作；

509)第三方开放平台向资源汇聚网关提交的redirct_url返回经过加密后 的授权码CODE和相应的reqID；

510)资源汇聚网关解密后，根据reqID和应用的映射关系，向该应用的 redirect_url返回授权码CODE；

511)应用获取授权码CODE，并向资源汇聚网关的访问令牌地址发出请 求，请求参数包括电信运营商开放平台颁发的api_key、api_secret和上一步 的授权码CODE；

512)资源汇聚网关以加密方式向第三方开放平台的访问令牌地址发出请 求，请求参数包括第三方开放平台颁发给资源汇聚网关的api_key、api_secret、 应用提供的授权码CODE和与应用对应的会话码reqID；

513)第三方开放平台解密资源汇聚网关的请求信息，生成access_token 并与reqID一起，经过加密后返回给资源汇聚网关；

514)资源汇聚网关解密后，根据reqID与应用的对应关系，将access_token 返回给应用；

515)应用向资源汇聚网关请求用户信息，请求参数包括access_token；

516)资源汇聚网关以加密的方式向第三方开放平台请求用户信息，请求 参数包括access_token和reqID；

517)第三方开放平台解密后，获取对应的用户信息并与reqID一起以加 密的方式返回给资源汇聚网关；

518)资源汇聚网关解密后，根据reqID与应用的对应关系，返回用户信 息给对应的应用，应用呈现业务数据给用户。

在OAuth2.0的授权方法中，根据传输过程当中是否需要加密处理，跨平 台授权又分为非加密传输方式下跨平台OAuth2.0授权和加密传输模式下跨 平台OAuth2.0授权两种不同的流程，分别如图6和图7所示。

在图6中，一个完整的非加密传输方式下OAuth2.0跨平台授权流程如下：

601)开发者/SP的应用向资源汇聚网关的授权地址请求用户授权，请求 参数中包括电信运营商开放平台颁发给应用的api_key和用于接收授权码的 redirect_url；

602)资源汇聚网关接收到授权请求后，它会把该请求及其后续的信息获 取过程看作是一次会话，并动态生成一个与应用唯一对应的会话标识reqID， 然后将该授权请求进行转发，提交给第三方开放平台的授权地址，请求参数 中包括第三方开放平台颁发给资源汇聚网关的api_key和应用提供的 redirect_url。由于redirect_url是动态提供的(不同的应用对应不同的 redirect_url)，而通常情况下第三方开放平台需要根据应用注册时提供的 redirect_url与请求当中的redirect_url做比较以防止非法钓鱼操作。解决这种 矛盾的方法是：资源汇聚网关与第三方开放平台之间需要事先约定好发送用 户信息授权请求时的加密算法和密钥，实现该请求的加密传输；

603)第三方开放平台解密资源汇聚网关发出的用户信息授权请求，引导 用户登录和授权；

604)用户使用自己的账号在第三方开放平台登录页面登录，并进行相应 的授权操作；

605)第三方开放平台向应用的redirct_url返回授权码CODE；

606)应用获取授权码CODE，并向资源汇聚网关的访问令牌地址发出请 求，请求参数包括电信运营商开放平台颁发的api_key、api_secret和授权码 CODE；

607)资源汇聚网关向第三方开放平台的访问令牌地址发出请求，请求参 数包括第三方开放平台颁发给资源汇聚网关的api_key、api_secret、应用提供 的授权码CODE和本次会话的reqID；

608)第三方开放平台接收资源汇聚网关的请求信息，生成访问令牌 (access_token)并与reqID一起返回给资源汇聚网关；

609)资源汇聚网关根据reqID与应用的映射关系，将access_token返回 给应用；

610)应用向资源汇聚网关请求用户信息，请求参数包括access_token；

所述用户信息包括当前授权用户在第三方开放平台上的个人信息，比如 个人简介、好友等。

611)资源汇聚网关向第三方开放平台请求用户信息，请求参数包括 access_token和reqID；

612)第三方开放平台返回用户信息给资源汇聚网关，返回结果中包括 reqID；

613)资源汇聚网关返回用户信息给与reqID相对应的应用，应用呈现融 合业务给用户。

在安全加密传输的场景下，跨平台授权流程需要稍作修改，如图7所示， 包括：

701)开发者/SP的应用向资源汇聚网关的授权地址请求用户授权，请求 参数中包括电信运营商开放平台颁发给应用的api_key和用于接收授权码的 redirect_url；

702)资源汇聚网关将该授权请求进行转发，提交给第三方开放平台的授 权地址，请求参数中包括第三方开放平台颁发给资源汇聚网关的api_key、资 源汇聚网关向第三方开放平台注册的redirect_url和资源汇聚网关动态生成的 reqID。其中，reqID用于对应用进行标识，以便识别后续从第三方开放平台 返回的结果应该转发给哪个应用。在资源汇聚网关与第三方开放平台之间， 按事先约定好的密钥和加密算法加密传输上述信息；

703)第三方开放平台解密资源汇聚网关发出的用户信息授权请求，引导 用户登录和授权；

704)用户使用自己的账号在第三方开放平台登录页面登录，并进行相应 的授权操作；

705)第三方开放平台向资源汇聚网关提交的redirct_url返回经过加密后 的授权码CODE和相应的reqID；

706)资源汇聚网关解密后，根据reqID和应用的映射关系，向该应用的 redirect_url返回授权码CODE；

707)应用获取授权码CODE，并向资源汇聚网关的访问令牌地址发出请 求，请求参数包括电信运营商开放平台颁发的api_key、api_secret和上一步 的CODE；

708)资源汇聚网关以加密方式向第三方开放平台的访问令牌地址发出请 求，请求参数包括第三方开放平台颁发给资源汇聚网关的api_key、api_secret、 应用提供的CODE和与应用对应的会话码reqID；

709)第三方开放平台解密资源汇聚网关的请求信息，生成access_token 并与reqID，经过加密后一起返回给资源汇聚网关；

710)资源汇聚网关解密后，根据reqID与应用的对应关系，将access_token 返回给应用；

711)应用向资源汇聚网关请求用户信息，请求参数包括access_token；

712)资源汇聚网关以加密的方式向第三方开放平台请求用户信息，请求 参数包括access_token和reqID；

713)第三方开放平台解密后，获取对应的用户信息并与reqID一起以加 密的方式返回给资源汇聚网关；

714)资源汇聚网关解密后，根据reqID与应用的对应关系，返回用户信 息给对应的应用，应用呈现业务数据给用户。

本发明实施例还提供一种基于资源汇聚网关的跨平台授权系统，包括上 述资源汇聚网关和第三方开放平台，其中：

所述第三方开放平台用于，接收到所述用户信息授权请求后，引导用户 授权并返回授权码给所述资源汇聚网关；或者，所述第三方开放平台接收到 所述用户信息授权请求后，引导用户授权并返回所述授权码给所述应用。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序 来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读 存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用 一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用 硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任 何特定形式的硬件和软件的结合。