一种用于浏览器内应用的授权码流的制作方法

本公开涉及使用授权码和访问码来访问信息资源，并且在实施例中，并非限制，涉及使用授权码流来检索以及提供授权码和访问码用于浏览器内应用的系统和服务。

背景技术：

在基于web的应用的早期阶段，有许多这样的情况，其中用户被要求提供他或她最为秘密的凭据，例如用户名和密码，以访问网页或网站。然后，网站可以浏览用户的邮箱，并代表用户访问用户的受保护资源(如电子邮箱)。从安全的角度来看这被认为是不可接受的，因为用户正在把他或她最秘密的凭据转交给可能不完全值得信赖的应用。然后，信赖有问题的应用将被允许在用户凭据的全部范围内代表用户行事。在这种情况下，网站甚至能够在用户不知情的情况下以用户的名义发送电子邮件。

附图说明

在附图的图中通过示例而非限制的方式示出了本公开的一些示例性实施例，其中相同的附图标记指示相似的元件，并且其中：

图1是OAuth2.0授权码流的框图和本公开的一个或多个实施例可以在其上运行的应用服务器。

图2是在图1的应用服务器中运行的本公开的实施例的框图。

图3A、图3B和图3C是示出浏览器内应用的授权码流的操作和特征的框图。

图4是示出能够从机器可读介质(例如，机器可读存储介质)读取指令并执行本文所讨论的任何一种或多种方法的机器的组件的框图。

具体实施方式

本公开的示例方法和系统使用授权码和访问码来访问用于浏览器内应用的信息资源。在下面的描述中，为了解释的目的，阐述了许多具体细节，以便提供对示例性实施例的透彻理解。然而，对于本领域技术人员显而易见的是，可以在没有这些具体细节的情况下实践本实施例。

如上所述的与基于web的应用的早期阶段相关的安全问题是引入作为授权的开放标准的OAuth标准的基本动机。它通常用作互联网用户使用在其他基于互联网的应用(如Google、Facebook和Twitter)上的用户帐户登录第三方网站的方式。OAuth的优点是用户不会公开他或她的密码。通常，OAuth代表资源所有者向客户端提供对服务器资源的安全委托访问。它指定资源所有者授权第三方访问其服务器资源而无需第三方共享其凭据的过程。OAuth本质上允许授权服务器在获得资源所有者批准的情况下，向第三方客户端发送访问令牌。第三方然后使用访问令牌访问由资源服务器托管的受保护资源。

OAuth授权服务的访问令牌在被称为OAuth流中生成。要获得访问令牌，用户必须使用授权请求从授权服务器请求访问令牌。授权服务器首先需要知道用户是谁，对用户进行身份验证(例如使用用户名和密码)，并且在成功认证后，授权服务器询问用户是否允许发送授权请求的客户端代表用户操作。在某些情况下，这一切都在特定的范围内进行，范围进一步缩小了客户端代表用户允许做什么。

OAuth服务器询问用户是否允许客户端访问特定范围内的资源，并且如果用户确认，则OAuth服务器向OAuth客户端应用发回授权码。客户端应用然后使用代表一次性令牌的授权码来指示用户授予客户端应用由客户端代表用户访问用户的受保护资源。

一般来说，使用OAuth授权，客户端或作为OAuth客户端的访问令牌的接收者需要确保访问令牌被安全地存储。然而，使用浏览器内应用，没有存储该秘密或机密凭据(访问令牌)的地方，因此它仍然是授予该凭据的所有者某些权限以访问所有者的受保护资源的凭据。这就是访问令牌，就像密码一样，应该被安全地存储的原因。但是，在浏览器中运行的基于JavaScript的应用没有真正安全的位置来存储这些访问令牌。因此，开发本公开的实施例将提供安全地存储这些访问令牌的地方。也就是说，这些实施例在服务器端管理用于这些访问令牌的安全存储协议。

因此，本公开的一个或多个实施例的目的是允许浏览器内应用利用OAuth 2.0授权码许可流程。存在由OAuth 2.0授权框架描述的不同授权流程。许可流中的一个，授权码流，涉及在应用服务器上运行的应用的一部分。该部分可以与用户代理(或网络浏览器)之外的授权服务器通信，并且可以提供客户端凭证并获得访问令牌，而无需将访问令牌公开给资源所有者的用户代理。授权码授权流程有其他流程(对于例如，隐式授权流)不具有的优点，例如验证客户端的能力，以及将访问令牌直接发送到客户端，而无需使其通过资源所有者的用户代理并可能将访问令牌暴露给包括资源所有者的其他人。实施例允许浏览器内应用利用授权码流及其安全性的优点，并且基本上是由浏览器内应用调用的服务，其中服务执行对OAuth授权服务器的请求并处理来自OAuth授权服务器的响应。

浏览器内应用不能使用授权码授权流，因为浏览器内应用除了经由用户代理不能与OAuth授权服务器进行通信。因此，这样的浏览器内应用使用OAuth2.0授权网络的隐式授权流。然而，隐式授权流，如上所述的OAuth之前的框架，具有安全隐患。隐式授权流被开发和设计为服务于浏览器内应用，即应用是Java-Script应用，并仅在网络浏览器中运行。因此，这意味着每个用户都可以查看它，并且因此浏览器内应用无法安全地存储任何凭据。这就是浏览器内应用不能拥有客户ID的原因和浏览器内应用无法存储访问令牌的原因。如上所述，正是这种架构导致本公开的实施例所解决的不同的安全问题。

在实施例中，这些Java-Script浏览器内应用的安全问题由在应用服务器上运行的所公开的服务(disclosed service)来解决。所公开的服务具有三个端点或节点。浏览器内应用可以与这三个端点进行通信。端点包括用户特定的消费者或用户配置。因此，这些端点的每个用户都可以拥有他或她自己的帐户，即他或她自己的配置。在此设置中，服务的一个用户不会干扰服务的任何其他用户。实施例还可以保持所获得的访问令牌，使得其可以用于在稍后时间访问同一资源服务器的不同资源。

为了从OAuth授权服务器请求授权码，向授权服务器提交请求。该请求包含与OAuth客户ID、重定向统一资源定位符(URL)、范围和状态相关的信息。驻留在应用服务器中的服务提供了可由网络浏览器访问的端点，例如：

https://oauthasservices-y2dee844e.example.com/oauth2/request。

URL的y2dee844e部分标识服务的用户，以便实现使用与该特定用户相关的配置。浏览器内应用将用户代理重定向到端点。该服务读取用户特定的配置，为用户创建会话，并将用户代理重定向到授权服务器。从用户特定的配置取得请求所需的授权服务器码端点URL、范围和OAuth客户ID。重定向URL参数指向由服务提供的另一个端点，即可以由例如：

https://oauthasservices-y2dee844e.example.com/oauth2/callback表示或调用的“回调端点”。

状态参数由服务生成，其值存储在用户会话中。调用者的来源也记录在用户会话中。

授权服务器一旦发回授权码，则经由用户代理将授权码发送到回调端点。回调端点从请求中提取授权码和状态。将状态值与存储在用户会话中的状态值进行比较。只有当两个状态值匹配时，才会进一步处理请求。该服务通过运行用户代理之外的要求授权服务器的令牌端点的请求来请求访问令牌。从用户特定的配置中检索授权服务器的令牌端点的URL。该服务还使用来自配置的客户ID和客户端密码。作为该调用的结果，服务获取访问令牌。注意到，在一个实施例中，服务为不同用户提供不同的端点，从而允许服务识别用户并使用与特定用户相关的配置。

为了使用正确的访问令牌向资源服务器执行请求，浏览器内应用调用由服务提供的另一个端点，例如：

https://oauthasservices-y2dee844e.example.com/oauth2/proxy。

该服务通过保存用户唯一ID的cookie识别用户，并且如果有可用的服务，则服务寻找关联的访问令牌。该服务使用可用的访问令牌来向资源服务器发出用户代理外部的请求。经由用户特定的配置，服务器主机是已知的。服务将资源服务器接收的响应返回给调用者，因此信息到达浏览器内应用。

在实施例中，由于获取的访问令牌可以被多次使用，如上所述，它可以留存。当它留存时，访问令牌与和用户相关联的唯一ID相关联。当与用户的代理建立会话时，将发布具有唯一ID的浏览器cookie。在稍后的请求中，用户的代理将该cookie发送回来从而识别用户，并且仅使用与用户相关联的令牌。

以如下方式运行对授权服务器的请求。浏览器内应用与服务的请求端点进行通信，其基于配置将请求发送到授权服务器。该请求通过浏览器，但请求不包含任何机密信息。现在，在这个时间点，授权服务器接收请求并发出授权码。授权码被发送回服务，也就是，发送到发出请求的系统。由第二个端点(回调端点)接收来自授权服务器的授权码。然后，服务将授权码交换为其后被安全地存储的访问令牌。在这个时间点，服务具有不以任何方式与浏览器内应用共享的访问令牌。由于上述讨论的安全问题，不期望共享访问令牌。然而，该服务仍然希望提供浏览器内应用可以使用此访问令牌请求资源的方法。

因此，为了使服务为浏览器内应用提供使用访问令牌请求资源的方法，服务提供第三端点，以上称为资源请求端点。资源请求端点的目的是浏览器内应用可以使用OAuth请求资源保护的材料，但浏览器内应用实际上经由资源请求端点请求资源保护材料。当资源请求端点接收到请求时，它使用访问令牌来增强请求，然后请求实际资源，接收资源，并将资源发送到浏览器内应用。以这种方式，该服务避免了隐式授权流的所有问题，并且浏览器内应用在其编程模型的方式上不必进行任何改变。

如所指出的，在一个实施例中，请求端点可以多次使用访问令牌来处理针对不同受保护资源的多个请求。为了能够做到这一点，访问令牌是用户特定的，以便可以识别用户。也就是说，服务必须将访问令牌(其被存储在应用服务器中的服务中)与用户相关联。该服务通过发出浏览器本身处理的特定Cookie来执行此操作。浏览器存储cookie，并在每个请求将Cookie发送到资源请求端点。因此，Cookie可以将存储的访问令牌与用户相关联，然后对许多请求重新使用访问令牌。因此，网络浏览器中的用户可以寻找不同的资源，而不必再次通过(go through)授权服务器、访问码请求端点或回调端点。

然后，实施例基本上使用使能了(enable)OAuth2.0流的服务器端服务扩展了OAuth2.0标准以被浏览器内应用安全地使用。现有标准随着使用本公开的新架构方法而得到扩展。

图3A、图3B和图3C是示出浏览器内应用的授权码流的操作和特征的框图。图3A、图3B和图3C包括多个处理块300-372。虽然在图3A、图3B和图3C的例子中顺序排列，但其他示例可以使用多个处理器或被组织为两个或更多个虚拟机或子处理器的单个处理器来重新排序块、省略一个或多个块和/或并行地执行两个或更多个块。此外，还有其他示例可以将块实现为一个或多个特定的互连硬件或集成电路模块，其中相关控制和数据信号在模块之间以及通过模块通信。因此，任何处理流都适用于软件、固件、硬件和混合实现。

现在具体参考图1、图2、图3A、图3B和图3C，在300，用于浏览器内应用(105、107)的基于服务器的授权服务经由网络230从浏览器内应用107接收用于授权码的请求125。如下面将要解释的，对授权码的这种请求是针对特定用户的。如在302所示，来自浏览器内应用的授权码的请求由应用服务器110中的授权码请求端点节点252接收。

在310，授权服务创建会话，其将浏览器内应用107重定向到授权服务器115。如在312所示，授权服务器115使用用于授权的OAuth1.0和/或OAuth2.0标准配置。来自浏览器内应用107的对授权码的请求包括客户ID、统一资源定位符(URL)、范围参数和状态参数(314)。客户ID用于标识特定用户。URL是浏览器内应用107重定向到的地址。范围参数和状态参数用于验证浏览器内应用107和授权服务250是否同步，这将在下面详细讨论。此外，如316所示，授权服务250使用浏览器内部应用107被重定向到的URL、范围参数、客户ID和状态参数来创建重定向浏览器内应用107到授权服务器115的会话。在318，授权服务250使用与特定用户相关联的配置来提供浏览器内应用被重定向到的URL、标识特定用户的客户ID以及与特定用户相关联的客户端密码或秘密，以在来自授权服务器115的对访问令牌的请求中使用。该配置存储在用户特定配置259中。这些操作涉及授权服务器115的许可请求130和网络浏览器105的许可供应135。

在320，授权服务250通过浏览器内应用107接收来自授权服务器115的授权码150。如在322处所指示的，授权码150由回调端点节点254接收。可操作回调端点节点254以将从授权服务器115接收到的状态参数与从浏览器内应用107接收到的状态值进行比较，并且在当状态参数与状态值(324)不匹配时终止浏览器内应用107。

在330，授权服务250向授权服务器115请求访问令牌165(155、160)。如上所述，通过向授权服务器115提供以下信息来进行该请求：客户ID、统一资源定位符(URL)、范围参数和状态参数。如在332所示的，运行来自授权服务器115对访问令牌165的请求，而不涉及浏览器内应用107。在340，授权服务250从授权服务器115接收访问令牌165。在350，授权服务250接收来自浏览器内应用107的对资源的请求，并且在360，授权服务250使用访问令牌165向第三方资源服务器120请求资源(170)。如在362所示，对第三方资源服务器120的请求由资源请求端点节点256运行。在370，授权服务250将资源(175)返回到浏览器内应用107。资源请求端点节点256可以通过在网络浏览器105上的cookie在258识别特定用户来存留(persist)访问令牌165。这样的cookie包括用户ID。资源请求端点节点256然后寻找与用户ID相关联的访问令牌，并在稍后时间使用相关联的访问令牌165来访问第三方资源服务器120以获得不同的资源。资源请求端点节点256然后从第三方资源服务器120接收不同的资源，并在372将不同的资源返回给浏览器内应用(107)。

模块，组件和逻辑

某些实施例在本文中被描述为包括逻辑或多个组件、模块或机制。模块可以构成软件模块(例如，在机器可读介质上或传输信号中实施的代码)或硬件模块。硬件模块是能够执行某些操作并且可以以某种方式配置或布置的有形单元。在示例实施例中一个或多个计算机系统(例如，独立的、客户端或服务器计算机系统)或计算机系统(例如，处理器或一组处理器)的一个或多个硬件模块可以由软件(例如，应用或应用部分)配置操作以执行如本文所述的某些操作的硬件模块。

在各种实施例中，硬件模块可以机械地或电子地实现。例如，硬件模块可以包括永久配置的专用电路或逻辑(例如，作为专用处理器，例如现场可编程门阵列(FPGA)或专用集成电路(ASIC))来执行某些操作。硬件模块还可以包括由软件临时配置以执行某些操作的可编程逻辑或电路(例如，包含在通用处理器或其他可编程处理器内)。应当理解，以专用和永久配置的电路，或临时配置的电路(例如，由软件配置)机械地实现硬件模块的决定可以由成本和时间考虑来驱动。

因此，术语“硬件模块”应理解为包括有形实体，即物理构造、永久配置(例如，硬连线)或临时配置(例如，编程)来以某种方式操作和/或执行本文所述的某些操作的实体。考虑到其中硬件模块被临时配置(例如，编程)的实施例，硬件模块中的每一个不需要在任何一个时间上配置或实例化。例如，在其中硬件模块包括被配置为使用软件的通用处理器的情况下，通用处理器可以在不同时间被配置为相应的不同的硬件模块。因此，软件可以相应地配置处理器，例如，在一个时间点构成特定的硬件模块，并在不同的时间点构成不同的硬件模块。

硬件模块可以向其他硬件模块提供信息并从其他硬件模块接收信息。因此，所描述的硬件模块可以被认为是通信耦合的。当在同时存在多个这样的硬件模块的情况下，可以通过连接硬件模块的信号传输(例如，通过适当的电路和总线)来实现通信。在其中在不同时间配置或实例化多个硬件模块的实施例中，可以通过例如多个硬件模块能够访问的存储器结构中的信息的存储和检索来实现这种硬件模块之间的通信。例如，一个硬件模块可以执行操作并将该操作的输出存储在与其通信耦合的存储器件中。然后，另外的硬件模块可以在稍后的时间访问存储器件以检索和处理所存储的输出。硬件模块还可以启动与输入或输出设备的通信，并且可以对资源进行操作(例如，信息的集合)。

本文描述的示例性方法的各种操作至少部分地可以由临时配置(例如通过软件)或永久配置为执行相关操作的一个或多个处理器来执行。无论是临时还是永久配置，这些处理器可以构成操作以执行一个或多个操作或功能的处理器实现的模块。在一些示例性实施例中，这里所指的模块可以包括处理器实现的模块。

类似地，本文描述的方法可以至少部分地由处理器实现。例如，方法的至少一些操作可由一个或多个处理器或处理器实现的模块来执行。某些操作的执行可以分布在一个或多个处理器中，不仅驻留在单个机器内，而且部署在多台机器上。在一些示例实施例中，处理器或多个处理器可以位于单个位置(例如，在家庭环境、办公环境或服务器场内)，而在其他实施例中，处理器可以分布在多个位置。

一个或多个处理器还可以操作以支持“云计算”环境或作为“软件即服务”(SaaS)中的相关操作的执行。例如，至少一些操作可以由一组计算机(例如包括处理器的机器)来执行，这些操作可经由网络(例如，图2的网络230)以及经由一个或多个适当的接口(例如API)访问。

示例实施例可以在数字电子电路中或在计算机硬件、固件、软件或它们的组合中实现。示例性实施例可以使用计算机程序产品来实现，例如，有形地实施在例如在机器可读介质中的信息载体中的计算机程序，用于由数据处理装置运行或控制数据处理装置的操作，数据处理装置例如可编程处理器、计算机或多台计算机。

计算机程序可以以任何形式的编程语言编写，包括编译或解释语言，并且可以以任何形式部署，包括作为独立程序或作为模块、子程序或适用于计算环境的其他单元。计算机程序可以在一个计算机上或在一个站点或分布在多个站点上并由通信网络互连的多个计算机上部署以运行。

在示例实施例中，操作可以由运行计算机程序的一个或多个可编程处理器执行，以通过操作输入数据并生成输出来执行功能。方法操作也可由专用逻辑电路(例如，FPGA或ASIC)来执行，并且示例实施例的装置可以以其来实现。

计算系统可以包括客户端和服务器。客户端和服务器通常彼此远离，并且典型地通过通信网络进行交互。客户端和服务器的关系产生于在相应计算机上运行并且彼此之间具有客户端-服务器关系的计算机程序。在部署可编程计算系统的实施例中，应当理解，硬件和软件架构两者都值得考虑。具体来说，应当理解，是否在永久配置的硬件(例如，ASIC)、在临时配置的硬件(例如，软件和可编程处理器的组合)或永久地和临时地组合配置硬件中实现某些功能的选择，可以作为设计选择。下面列出了在各种示例性实施例中可以部署的硬件(例如机器)和软件体系结构。

图4是根据一些示例实施例的计算机系统400的示例形式的机器的框图，其中可以运行用于导致机器执行本文所讨论的任何一种或多种方法的指令424。在替代实施例中，机器作为独立设备操作或者可以连接(例如，联网)到其他机器。在网络部署中，该机器可以以服务器-客户端网络环境中的服务器或客户机的资格，或作为对等(或分布式)网络环境中的对等机器操作。该机器可以是个人计算机(PC)、平板电脑、机顶盒(STB)，个人数字助理(PDA)、蜂窝电话、网络设备、网络路由器、交换机或网桥，或能够运行指定该机器要采取的动作的指令(顺序地或其他)的任何机器。此外，虽然仅示出了单个机器，但是术语“机器”还应被视为包括单独或共同运行一组(或多组)指令以执行本文所讨论的任何一种或多种方法的机器的任何集合。

示例性计算机系统400包括处理器402(例如，中央处理单元(CPU)、图形处理单元(GPU)或两者)、主存储器404和静态存储器406，其经由总线408相互通信。计算机系统400还可以包括视频显示单元410(例如，液晶显示器(LCD)或阴极射线管(CRT))。计算机系统400还包括字母数字输入设备412(例如，键盘)、用户界面(UI)导航(或光标控制)设备414(例如，鼠标)、磁盘驱动器单元416、信号生成设备418(例如，扬声器)和网络接口设备420。

磁盘驱动器单元416包括其上存储了一组或多组实施由本文所述的任何一种或多种方法或功能或被其利用的数据结构和指令424(例如，软件)的机器可读介质422。在由计算机系统400运行期间，指令424还可以完全地或至少部分地驻留在主存储器404内和/或处理器402内，主存储器404和处理器402也构成机器可读介质。指令424也可以完全地或至少部分地驻留在静态存储器406内。

虽然在示例性实施例中将机器可读介质422显示为单个介质，但术语“机器可读介质”可以包括存储一个或多个指令424或数据结构的单个介质或多个介质(例如，集中式或分布式数据库，和/或相关联的高速缓存和服务器)。术语“机器可读介质”还应被认为包括能够存储、编码或携带用于由机器运行并使机器执行本实施例的任何一种或多种方法，或者能够存储、编码或携带由这些指令使用或与之相关联的数据结构的任何有形介质。因此，术语“机器可读介质”应被认为包括但不限于固态存储器以及光学和磁性介质。机器可读介质的具体示例包括非易失性存储器，包括例如半导体存储器件(例如，可擦除可编程只读存储器(EPROM)、电可擦除可编程只读存储器(EEPROM)和闪存器件)；如内部硬盘和可移动磁盘的磁盘；磁光盘；以及光盘只读存储器(CD-ROM)和数字通用盘(或数字视盘)只读存储器(DVD-ROM)盘。

还可以使用传输介质经由通信网络426进一步发送或接收指令424。可以使用网络接口设备420和众所周知的传输协议(例如，HTTP)中的任何一个传输指令424。通信网络的示例包括LAN、WAN、因特网、移动电话网络、POTS网络和无线数据网络(例如，WiFi和WiMax网络)。术语“传输介质”应被视为包括能够存储、编码或携带由机器运行的指令的任何无形介质，并且包括数字或模拟通信信号或促进这种软件的通信的其他无形介质。

虽然已经参考特定示例实施例描述了实施例，但是显而易见的是，在不脱离本公开的更广泛的精神和范围的情况下，可以对这些实施例进行各种修改和改变。因此，说明书和附图被认为是说明性的而不是限制性的。构成其一部分的附图通过说明而非限制的方式示出了可以实践主题的具体实施例。所描述的实施例足够详细地被描述，以使本领域技术人员能够实践本文公开的教导。可以利用和导出其他实施例，使得可以在不脱离本公开的范围的情况下进行结构和逻辑替换和改变。因此，这个具体描述不应被认为是限制性的，并且各种实施例的范围仅由所附权利要求以及这些权利要求所赋予的等同物的全部范围来限定。

虽然本文已经示出和描述了具体实施例，但是应当理解，为实现相同目的而计算的任何布置可以替代所示的具体实施例。本公开旨在覆盖各种实施例的任何和所有修改或变化。一旦阅读上述描述，上述实施例和本文中未具体描述的其他实施例的组合对于本领域技术人员将是显而易见的。