CN102238007A - 第三方应用获得用户的会话令牌的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种第三方应用获得用户的会话令牌的方法、装置及系统，用以解决现有基于HTTP跳转的方式存在的使用场景单一、可定制化程度低，以及系统的安全性较低的问题。第三方应用获得用户的会话令牌的方法，包括：第三方应用接收用户发起的访问，确认当前未获得用户的会话Token时，指示用户获得并提交授权码；第三方应用接收用户提交的从开放平台处获得的授权码；以及基于所述授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token。通过本申请，第三方应用无需通过HTTP跳转的方式即可安全获得用户的会话Token，从而实现对各种使用场景的兼容，提高可定制化程度。

Description

第三方应用获得用户的会话令牌的方法、装置及系统

技术领域

本申请涉及互联网技术领域，尤其涉及一种第三方应用获得用户的会话Token(令牌)的方法、装置及系统。

背景技术

开放平台是指由网站(例如电子商务网站)提供的、面向第三方的开放式基础服务平台，其以OpenAPI(Open Application Programming Interface，开放应用程序接口)的形式开放基础服务。开放平台具备的一个重要功能是向第三方应用授权，允许第三方应用从开放平台获取Token(令牌)，并通过该Token获取用户数据，例如用户的地址、交易信息等。

网站提供的开放平台普遍采用固定Token与会话Token相结合的授权方式，实现开放平台和用户对第三方应用的授权，会话Token也称为SessionKey(会话密钥)。固定Token与会话Token相结合的授权方式是指：开放平台向第三方应用分配一个固定Token，用户在发起对第三方应用的访问时，从开放平台获取为该用户分配的会话Token，并将该会话Token提交给第三方应用。该授权方式能够保证第三方应用必须经过开放平台与用户的双重授权，才能访问用户数据。其中，固定Token一般是由第三方应用的开发者向开放平台申请、并由开放平台的管理者批准后分配给第三方应用；第三方应用对会话Token的获取需要用户的授权。如何保证安全性、并能够兼容各种应用场景，成为解决第三方应用获得用户的会话Token的关键问题之一。

现有技术中，各个开放平台都推出了会话Token的获取机制，例如FacebookConnect、OAuth等，均是基于HTTP(HyperText Transfer Protocol，超文本传输协议)跳转的方式实现第三方应用对用户的会话Token的获取。用户访问第三方应用的实现流程，如图1所示，包括如下步骤：

步骤1、用户向开放平台发起对第三方应用的访问；

步骤2、开放平台验证用户身份；

步骤3、在用户通过身份验证之后，开放平台指示用户跳转到第三方应用，指示中携带为用户分配的会话Token；

步骤4、用户基于HTTP跳转的方式访问第三方应用，提交开放平台为该用户分配的会话Token；

步骤5、第三方应用获得用户的会话Token；

步骤6、第三方应用向开放平台访问用户数据，并携带固定Token和会话Token；

步骤7、开放平台验证第三方应用携带的固定Token和会话Token；

步骤8、对固定Token和会话Token验证通过后，开放平台向第三方应用返回用户数据；

步骤9、第三方应用根据开放平台返回的用户数据向用户进行页面展示。

其中，步骤1～步骤5为第三方应用获得用户的会话Token的实现流程，步骤6～步骤9为第三方应用访问用户数据并进行页面展示的实现流程。上述第三方应用获得用户的会话Token的技术方案，基于HTTP跳转的方式实现，即需要用户通过登录过程获取开放平台为该用户分配的会话token，用户再基于HTTP跳转的方式访问第三方应用，提交开放平台为该用户分配的会话Token。现有第三方应用获得用户的会话Token的技术方案，仅适用于Web(万维网)应用场景，而针对基于客户端软件的应用场景，以及基于命令行的应用场景无法适用，使得使用场景单一；现有第三方应用获得用户的会话Token的技术方案，要求第三方应用必需能够嵌入开放平台的用户登录页面，不适用于Iframe等场景下的页面，可定制化程度低；在第三方应用获得用户的会话Token的过程中，会话Token在开放平台与用户之间以及用户与第三方应用之间进行了多次传输，导致该会话Token容易被劫持，系统的安全性较低。

申请内容

本申请实施例提供一种第三方应用获得用户的会话令牌的方法、装置及系统，用以解决现有基于HTTP跳转的方式存在的使用场景单一、可定制化程度低，以及系统的安全性较低的问题。

本申请实施例提供一种第三方应用获得用户的会话令牌的方法，包括：

第三方应用接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；

第三方应用接收用户提交的从开放平台处获得的授权码；以及

基于所述授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token。

本申请实施例提供一种第三方应用获得用户的会话令牌的装置，包括：

处理单元，用于接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；

接收单元，用于接收用户提交的从开放平台处获得的授权码；

获取单元，用于基于所述授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token。

本申请实施例提供一种第三方应用获得用户的会话令牌的方法，包括：

开放平台接收用户获取授权码的请求；

开放平台在用户通过身份验证之后，向用户提供授权码，以使所述用户将获得的授权码提交给第三方应用；

开放平台接收第三方应用基于所述授权码对用户的会话Token的申请，对所述授权码进行验证，并在验证通过后向第三方应用返回用户的会话Token。

本申请实施例提供一种第三方应用获得用户的会话令牌的系统，包括第三方应用和开放平台，其中：

所述第三方应用，用于接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；接收用户提交的从开放平台处获得的授权码，以及基于所述授权码向开放平台申请用户的会话Token，并获得开放平台返回的用户的会话Token；

所述开放平台，用于向用户提供授权码，以及在第三方应用发起对用户的会话Token的申请时，对所述授权码进行验证并在验证通过后向第三方应用返回用户的会话Token。

本申请实施例提供的第三方应用获得用户的会话Token的方法、装置及系统，用户首先从开放平台处获得授权码并提交给第三方应用，第三方应用基于授权码向开放平台申请用户的会话Token，并最终获得用户的会话Token。本申请实施例将用户登录与第三方应用的使用相分离，用户通过登录过程获取到授权码之后，在使用第三方应用时直接提交授权码，以一种比较简单和安全的基于授权码的方式，实现开放平台向第三方应用的单向授权，第三方应用无需通过HTTP跳转的方式即可安全获得用户的会话Token，从而实现对各种使用场景的兼容，提高可定制化程度。在第三方应用获得用户的会话Token的过程中，以授权码代替会话Token在开放平台与用户之间以及用户与第三方应用之间进行传输，即使该授权码被劫持，劫持者也不能凭借该授权码访问用户数据，通过减少会话Token在系统中的传输次数，从而有效增强了系统的安全性。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

图1为现有技术中用户访问第三方应用的实现流程图；

图2为本申请实施例中第三方应用获得用户的会话Token的方法流程图；

图3为本申请实施例中用户访问第三方应用的实现流程图；

图4为本申请实施例中第一页面的示意图；

图5为本申请实施例中第二页面的示意图；

图6为本申请实施例中第三方应用获得用户的会话Token的系统示意图；

图7为本申请实施例中第三方应用获得用户的会话Token的装置框图。

具体实施方式

本申请实施例提供了一种第三方应用获得用户的会话Token即会话密钥的方法、装置及系统，基于授权码的方式实现，第三方应用无需通过HTTP跳转的方式即可安全获得用户的会话Token，从而实现对各种使用场景的兼容，提高可定制化程度。

以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请，并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本申请的具体实施涉及开放平台、第三方应用、以及用户之间的相互信任和授权，前提条件如下：

1)用户完全信任开放平台，向开放平台提供用户ID(Identifier，标识)和密码；

2)第三方应用可以基于用户的授权获取用户数据；

3)第三方应用从开放平台获取用户数据时，开放平台需要验证为第三方应用分配的固定Token和为用户分配的会话Token。

本申请实施例提供的第三方应用获得用户的会话Token的方法，需要用户从开放平台处获得授权码，用户获得授权码之后，第三方应用即可基于该授权码向开放平台申请用户的会话Token。在保证安全性的前提下，使得第三方应用能够通过更加灵活的方式获得授权码进而获得用户的会话Token。如图2所示，包括如下步骤：

S201、第三方应用接收用户发起的访问，确认当前未获得用户的会话Token时，指示用户获得并提交授权码；

S202、开放平台接收用户获取授权码的请求，在用户通过身份验证之后，向用户提供授权码；

S203、第三方应用接收用户提交的从开放平台处获得的授权码；

S204、第三方应用基于用户提交的授权码向开放平台申请用户的会话Token；

S205、开放平台对该授权码进行验证，并在验证通过后向第三方应用返回用户的会话Token。

至此，已经实现了第三方应用对用户的会话Token的获取，后续第三方应用向开放平台访问用户数据时，与现有技术中一致，开放平台验证为第三方应用分配的固定Token和为用户分配的会话Token，并在验证通过后向第三方应用返回用户数据，最终实现第三方应用向用户进行页面展示。

基于上述第三方应用获得用户的会话Token的实现流程，如图3所示，本申请实施例同时提供了一种用户访问第三方应用的实现流程，包括如下步骤：

步骤1、用户发起对第三方应用的访问。

步骤2、第三方应用通过向用户返回用于获得并提交授权码的第一页面指示用户获得并提交授权码，第一页面中携带开放平台中用于提供授权码的第二页面的地址信息；

第二页面的地址信息可以为该第二页面的文本超链接或者图片超链接，第二页面的文本超链接包括第二页面的URL(Uniform/Universal ResourceLocator，统一资源定位符)和相关的文本信息，第二页面的图片超链接包括第二页面的URL和相关的图片信息，其中，相关的文本信息或图片信息用于向用户说明通过点击该超链接能够获得授权码。

步骤3、用户通过第二页面的地址信息访问开放平台中用于提供授权码的第二页面。

步骤4、如果用户未通过身份验证时，开放平台提示用户登录以验证用户身份。

步骤5、开放平台在用户通过身份验证之后，在第二页面中向用户展示当前为该用户分配的授权码；

具体实施中，授权码一般由用户ID、授权时间和开放平台的签名组成，将用户标识、授权时间和开放平台的签名等信息采用特定的编码技术(例如Base64编码、Base16编码等)进行编码之后在第二页面中展示给用户。为了保证安全可靠性，开放平台为用户分配的授权码为一次性有效并且在设定的时间长度后过期的信息，时间长度一般设定为5分钟、10分钟等，还可以根据实际情况灵活调整。

步骤6、用户通过第一页面向第三方应用提交获得的授权码。

步骤7、第三方应用基于用户提交的授权码向开放平台申请用户的会话Token。

步骤8、开放平台验证该授权码。

步骤9、开放平台对该授权码验证通过后向第三方应用返回用户的会话Token。

在步骤7～步骤9的具体实施中，第三方应用将用户通过第一页面提交的授权码发送给开放平台中的应用容器，开放平台中的应用容器对授权码验证通过后，根据第三方应用的注册信息通过URL回调该第三方应用，该URL中携带开放平台为用户分配的会话Token；从而第三方应用从URL中获得用户的会话Token。需要说明的是，为了实现对第三方应用的回调，URL中包括第三方应用的回调地址。具体实施中，该URL除了携带用户的会话Token之外，一般还可携带第三方应用的上下文参数、以及开放平台为第三方应用分配的固定Token。

步骤10、第三方应用基于开放平台为该第三方应用分配的固定Token和为用户分配的会话Token向开放平台访问用户数据；

需要说明的是，固定Token一般是由第三方应用的开发者向开放平台申请、并由开放平台的管理者批准后分配给第三方应用的，一般预先配置给第三方应用。具体实施中，如果URL中携带有开放平台为第三方应用分配的固定Token，则第三方应用也可以直接从URL中获取该固定Token。

步骤11、开放平台验证第三方应用上报的固定Token和会话Token。

步骤12、对固定Token和会话Token验证通过后，开放平台向第三方应用返回用户数据。

步骤13、第三方应用根据开放平台返回的用户数据向用户进行页面展示。

下面，举例说明第三方应用获得用户的会话Token的实现流程，假设提供开放平台的网站为“AAA网”，具体包括如下步骤：

步骤一、用户发起对第三方应用的访问。

第三方应用接收到用户发起的访问时，需要判断当前是否已经获得用户的会话Token。如果已经获得用户的会话Token，则不再执行后续各步骤，直接访问用户数据并进行页面展示。如果未获得用户的会话Token，则需要向用户返回一个用于获得并提交授权码的页面，使得用户通过该页面能够获得并提交授权码，为了便于区分，本申请实施例中将该页面称为第一页面。

较佳的，为了方便用户从开放平台处获得授权码，开放平台中包括另一用于提供授权码的页面，为了便于区分，本申请实施例中将该页面称为第二页面。在此基础上，第一页面中可以携带开放平台中用于提供授权码的第二页面的地址信息，该地址信息可以采用第二页面的文本超链接或者图片超链接的形式表示。第一页面的示意图如图4所示，可以看出“获取AAA网授权码”的按钮即为第二页面的文本超链接，通过点击该文本超链接能够使用户跳转到如下地址：

http://auth.open.AAA.com/authorize/？appkey＝{appkey}

其中{appkey}表示该第三方应用的AppKey(应用密钥)，即固定Token。

步骤二、用户从开放平台处获得授权码。

用户访问地址“http://auth.open.AAA.com/authorize/？appkey＝{appkey}”时，开放平台向用户返回第二页面，具体实施中，如果用户未登录AAA网，开放平台先提示用户登录AAA网，然后再向用户返回第二页面。第二页面的示意图如图5所示，开放平台在第二页面中向用户展示当前为其分配的授权码，从而使得用户可以在第二页面中获得授权码。

具体实施中，除了页面展示授权码的方式之外，开放平台还可以采用其它方式向用户展示授权码，例如短消息展示方式、语音展示方式等等。以短消息展示方式为例说明，开放平台可以在第一页面中向用户展示用于提供授权码的服务号码，如果用户使用移动终端拨打该服务号码或者向该服务号码发送短消息，则开放平台采用无线方式将授权码发送到用户的移动终端上。

步骤三、用户通过第一页面向第三方应用提交授权码。

用户可以将步骤二中获得的授权码复制粘贴到第一页面的相应位置处即“请填入AAA网授权码”位置处，并提交授权码。

步骤四、第三方应用将用户提交的授权码发送到开放平台中的应用容器，具体提交到如下地址表示的应用容器中：

http://container.open.AAA.com/container？authcode＝{authcode}

其中，authcode表示步骤二中用户获得的授权码。

步骤五、第三方应用获得用户的会话Token。

开放平台中的应用容器会根据第三方应用的注册信息，通过URL回调该第三方应用，假设第三方应用的回调地址为http://app-callback/，则URL为：

http://app-callback/？top_appkey＝{top_appkey}&top_parameters＝{top_parame ters}&top_session＝{top_session}&top_sign＝{top_sign}

其中，

{top_appkey}表示第三方应用的AppKey(应用密钥)，即固定Token；

{top_parameters}表示第三方应用的上下文参数；

{top_session}表示用户的SessionKey(会话密钥)，即会话Token；

{top_sign}表示AAA网对上述{top_appkey}、{top_parameters}、{top_session}等参数的签名；

第三方应用从该URL中即可获得用户的会话Token。

基于同一技术构思，本申请实施例提供了一种第三方应用获得用户的会话Token的系统，如图6所示，包括第三方应用601和开放平台602，其中：

第三方应用601，用于接收用户发起的访问，确认当前未获得用户的会话Token时，指示用户获得并提交授权码；接收用户提交的从开放平台处获得的授权码，以及基于获得的授权码向开放平台602申请用户的会话Token，并获得开放平台602返回的用户的会话Token；

开放平台602，用于向用户提供授权码，以及在第三方应用601发起对用户的会话Token的申请时，对该授权码进行验证并在验证通过后向第三方应用601返回用户的会话Token。

本申请实施例同时提供了一种第三方应用获得用户的会话Token的装置，该装置一般设置在提供第三方应用的实体设备中，如图7所示，包括：

处理单元701，用于接收用户发起的访问，确认当前未获得用户的会话Token时，指示用户获得并提交授权码；

接收单元702，用于接收用户提交的从开放平台获得的授权码时；

获取单元703，用于基于该授权码向开放平台申请用户的会话Token，并获得开放平台对该授权码验证通过后返回的用户的会话Token。

较佳的，为了实现第三方应用访问用户数据并进行页面展示，该装置还可包括：

访问单元，用于基于开放平台为该第三方应用分配的固定Token和为用户分配的会话Token向开放平台访问用户数据，并接收开放平台对固定Token和会话Token验证通过后返回的用户数据；

展示单元，用于根据开放平台返回的用户数据向用户进行页面展示。

本申请实施例提供的第三方应用获得用户的会话Token的方法、装置及系统，用户首先从开放平台获得授权码并提交给第三方应用，第三方应用基于授权码向开放平台申请用户的会话Token，并最终获得用户的会话Token。本申请实施例将用户登录与第三方应用的使用相分离，用户通过登录过程获取到授权码之后，在使用第三方应用时直接提交授权码，以一种比较简单和安全的基于授权码的方式，实现开放平台向第三方应用的单向授权。第三方应用无需通过HTTP跳转的方式即可安全获得用户的会话Token，从而实现对各种使用场景的兼容，提高可定制化程度。在第三方应用获得用户的会话Token的过程中，以授权码代替会话Token在开放平台与用户之间以及用户与第三方应用之间进行传输，即使该授权码被劫持，劫持者也不能凭借该授权码直接访问用户数据，通过减少会话Token在系统中的传输次数，从而有效地地增强了系统的安全性；同时，通过设定授权码为一次性有效并且在设定的时间长度后过期，能够进一步避免授权码被劫持之后所带来的系统的安全性隐患。

本领域的技术人员应明白，本申请的实施例可提供为方法、装置、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (12)

1.一种第三方应用获得用户的会话令牌的方法，其特征在于，包括：

第三方应用接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；

第三方应用接收用户提交的从开放平台处获得的授权码；以及

基于所述授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token。

2.如权利要求1所述的方法，其特征在于，第三方应用指示用户获得并提交授权码，具体包括：

第三方应用通过向用户返回用于获得并提交授权码的第一页面指示用户获得并提交授权码。

3.如权利要求2所述的方法，其特征在于，所述第一页面中携带开放平台中用于提供授权码的第二页面的地址信息；以及

开放平台为用户分配授权码，具体包括：

开放平台在用户通过第二页面的地址信息发起对所述第二页面的访问时，对用户进行身份验证；并

在用户通过身份验证之后，在第二页面中向用户展示当前为用户分配的授权码。

4.如权利要求1、2或3所述的方法，其特征在于，所述授权码为一次性有效并且在设定的时间长度后过期的信息。

5.如权利要求2所述的方法，其特征在于，所述基于授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token，具体包括：

第三方应用将用户通过第一页面提交的授权码发送给开放平台中的应用容器；以及

接收开放平台中的应用容器对所述授权码验证通过后，根据第三方应用的注册信息回调该第三方应用时使用的统一资源定位符URL，所述URL中携带开放平台为用户分配的会话Token；

第三方应用从所述URL中获得用户的会话Token。

6.如权利要求5所述的方法，其特征在于，所述URL中还携带第三方应用的上下文参数、以及开放平台为第三方应用分配的固定Token。

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

第三方应用基于开放平台为该第三方应用分配的固定Token和为用户分配的会话Token向开放平台访问用户数据；并

接收开放平台对所述固定Token和会话Token验证通过后返回的用户数据；

第三方应用根据开放平台返回的用户数据向用户进行页面展示。

8.一种第三方应用获得用户的会话令牌的装置，其特征在于，包括：

处理单元，用于接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；

接收单元，用于接收用户提交的从开放平台处获得的授权码；

获取单元，用于基于所述授权码向开放平台申请用户的会话Token，并获得开放平台对所述授权码验证通过后返回的用户的会话Token。

9.如权利要求8所述的装置，其特征在于，还包括：

访问单元，用于基于开放平台为该第三方应用分配的固定Token和为用户分配的会话Token向开放平台访问用户数据，并接收开放平台对所述固定Token和会话Token验证通过后返回的用户数据；

展示单元，用于根据开放平台返回的用户数据向用户进行页面展示。

10.一种第三方应用获得用户的会话令牌的方法，其特征在于，包括：

开放平台接收用户获取授权码的请求；

开放平台在用户通过身份验证之后，向用户提供授权码，以使所述用户将获得的授权码提交给第三方应用；

开放平台接收第三方应用基于所述授权码对用户的会话Token的申请，对所述授权码进行验证，并在验证通过后向第三方应用返回用户的会话Token。

11.如权利要求10所述的方法，其特征在于，还包括：

开放平台接收第三方应用对用户数据的访问，所述访问基于开放平台为该第三方应用分配的固定Token和为用户分配的会话Token发起；

开放平台对所述固定Token和会话Token验证通过后向第三方应用返回用户数据，使第三方应用根据所述用户数据向用户进行页面展示。

12.一种第三方应用获得用户的会话令牌的系统，其特征在于，包括第三方应用和开放平台，其中：

所述第三方应用，用于接收用户发起的访问，确认当前未获得用户的会话令牌Token时，指示用户获得并提交授权码；接收用户提交的从开放平台处获得的授权码，以及基于所述授权码向开放平台申请用户的会话Token，并获得开放平台返回的用户的会话Token；

所述开放平台，用于向用户提供授权码，以及在第三方应用发起对用户的会话Token的申请时，对所述授权码进行验证并在验证通过后向第三方应用返回用户的会话Token。

Images