Oauth框架的制作方法

Oauth框架的制作方法
【专利摘要】一种遵循OAuth标准的框架，涉及可以由多个资源服务器使用的通用OAuth授权服务器，以便确保对存储在那些资源服务器上的资源的访问局限于资源所有者同意的访问。每个资源服务器向OAuth授权服务器登记用于那个资源服务器的元数据，该元数据指示由该资源服务器识别的范围。当代表客户端应用从资源所有者请求同意时，OAuth授权服务器参考这种元数据，使得同意具有适当的范围。当构造要提供给客户端应用在访问资源服务器上的资源时使用的访问令牌时，OAuth授权服务器参考这种元数据。OAuth授权服务器使用这种元数据把所发布的访问令牌映射到那些访问令牌准许访问的范围。
【专利说明】OAUTH框架
[0001] 优先权要求
[0002] 本申请按照美国法典第35章119条要求于2011年9月29日提交且标题为 "RELYING PARTY AND OAUTH FRAMEWORK" 的美国临时专利申请 No. 61/541, 026 的优先权。

【背景技术】
[0003] 身份管理系统是一种信息系统，或者可以用于企业或跨网络身份管理的一组技 术。身份管理描述了系统和企业边界中或者跨系统和企业边界的个人身份、其认证、授权、 角色和特权的管理，其目的在于在降低成本、停机时间和重复任务的同时提高安全性和生 产力。身份管理的一方面是"单点登录"（Single Sign-on ;SS0)。在身份管理领域中特别 有用的一个标准是OAuth。
[0004] SS0是多个相关但独立的软件系统的访问控制的一个特性。利用这个特性，用户登 录一次并且获得对所有系统的访问，而不会在每个系统都被提示再次登陆。反过来，单点登 出是使得单个登出动作终止对多个软件系统的访问的特性。由于不同的应用和资源支持不 同的认证机制，因此，单点登录在内部翻译成并存储与用于初始认证的凭证比较而言不同 的凭证。SS0减少了网络钓鱼成功，因为用户没有被培训成在每个地方都不假思索地输入 密码。SS0减小了来自不同用户名和密码组合的密码疲劳。SS0减少了花在为同一个身份 重复输入密码上的时间。由于更少数量关于密码的信息技术（IT)服务台电话，SS0减小了 IT成本。SS0对系统的进入/退出/访问的所有层次提供了安全性，而没有重新提示用户 的不便。SS0还允许对合规性的集中式报告。SS0使用所有其它应用和系统用于认证目的 时都使用的集中式认证服务器，并且把这与确保用户不必主动输入其凭证多于一次的技术 相结合。
[0005] OAuth是用于授权的一种开放式标准。授权的间接效果是认证。OAuth允许用户 把存储在一个站点的他们的私有资源（例如，照片、视频、联系人列表等）与另一个站点共 享，而不必散发其凭证，作为替代，通常是提供用户名和密码令牌。每个令牌准许对一个具 体站点的具体资源访问既定的持续时间。这允许用户准许第三方站点访问他们利用另一个 服务提供者存储的信息，而不共享他们的访问许可或者他们的全部数据。例如，令牌可以准 许在接下来的两小时访问视频编辑站点来获取来自一个具体相册的视频。
[0006] 例如，在一个典型的场景下，Linkedln的用户可以被请求把用户的联系人从 Yahoo导入到Linkedln中的许可。Linkedln可能想获得这些联系人，以便发送例如邀请用 户的每个联系人加入Linkedln的电子邮件消息。在OAuth之前，这种对许可的请求可以 涉及用户向Linkedln提供用户的Yahoo用户身份和密码的请求。这个彳目息被请求，使得 Linkedln可以作为那个用户登录到该用户的Yahoo账户中，然后从用户的Yahoo账户获得 那个用户的联系人。一般来说，允许Linkedln (或者任何站点）具有用户的Yahoo (或任何 其它站点）身份和密码是个坏主意，因为它准许前者站点不受限制地访问后者站点上用户 的账户。这种不受限制的访问几乎总是比前者站点实现其目标，诸如仅仅是获得联系人列 表，实际所需多得多的访问。
[0007] 一个更好的构思是为前者站点提供相对于后者站点上用户帐户的有限授权。有限 的授权可以规定前者站点相对于后者站点上用户的帐户能够执行的具体操作集合。例如， 参考以上的典型场景，有限的授权可以规定Linkedln只能访问用户的联系人列表，而不执 行关于用户在Yahoo上的账户的其它操作。OAuth允许这种有限的授权。OAuth提供了授 权的委托。
[0008] OAuth通过其委托授权的技术可以相对于类比来理解。当车主暂时把对他的车 的控制转让给服务员使得该服务员可以为车主停车时，车主常常不向服务员提供通用的主 钥匙，而是向服务员提供更有限用途的服务员钥匙。服务员钥匙允许服务员具有开车的足 够访问，但不向服务员提供对车主在车中所拥有的每件事物的访问。以相同的方式，例如， OAuth的使用可以准许第一个站点访问由第二个站点存储的用户的联系人列表，而不允许 第一个站点相对于用户在第二个站点上的账户执行其它操作-诸如读取可能存储在第二 个站点上的电子邮件消息。OAuth允许给予第一个站点有限的授权来相对于第二个站点执 行规定的操作集合，而且不执行其它操作。
[0009] 对于另一个例子，用户可能想使用由第一个站点，诸如Snapfish，提供的照片打印 服务来打印电子存储在独立于第一个站点的第二个站点，诸如Flickr，上的某些彩色照片。 更具体而言，用户可能只想打印存储在Flickr上的特定相册，诸如包含用户最近参观阿拉 斯加的照片的相册，当中的照片。虽然用户可以具有存储在其Flickr账户上的多个不同相 册，但是用户可能只想打印来自阿拉斯加相册的照片。在这种情形下，用户有可能更想让 Snapfish不访问除阿拉斯加相册中所包含的那些照片之外其Hickr相册的任何内容。在 前面的场景下，利用OAuth术语，Snapfish被认为是客户端，而Hickr被认为是资源服务器 (照片数据是资源）以及OAuth授权服务器。作为由资源服务器存储的资源（例如，照片数 据）的所有者，用户也是资源所有者。
[0010] 给定以上给出的例子，用户可以首先使用他的互联网浏览器应用指引客户端（例 如，Snapfish)打印资源服务器（例如，Flickr)上用户阿拉斯加相册中的照片。作为响应， 客户端（例如，Snapfish)把用户重定向到资源授权服务器（例如，Flickr)的站点。这种重 定向操作可以向资源服务器指示客户端期望访问的有限数据集（例如，阿拉斯加相册的内 容）。在那个时候，资源授权服务器不知道用户是谁，因为用户还没有向资源授权服务器认 证他自己。因此，资源授权服务器需要用户进行认证。如以上所提到的，授权的间接效果是 认证。在用户向资源授权服务器认证他自己之后（例如，通过提供与资源授权服务器相关 的用户名和密码），资源授权服务器向用户的互联网浏览器发送同意页面。该同意页面请用 户验证资源授权服务器（例如，Flickr)具有向客户端（例如，Snapfish)提供有限的、规定 的数据集合（例如，阿拉斯加相册的内容）的用户许可。假设用户同意，则资源授权服务器 作为响应向客户端发送授权码。这个授权码可以通过"前方通道"，或者换句话说，利用重定 向经用户的互联网，发送。
[0011] 在这种场景下，客户端（例如，Snapfish)是授权服务器（例如，Flickr)值得信任 的合作者。客户端接收授权码，或"准许"，并且存储该授权码。客户端无限期地维护这个授 权码，直到用户主动宣告该授权码无效。用户可以登录到OAuth授权服务器，以便看OAuth 授权服务器己经代表用户向各个客户端提供的准许列表。响应于接收授权码，客户端（例 如，Snapfish)向授权服务器（例如，Flickr)作出"后方通道"调用。后方通道调用是不涉 及用户的互联网浏览器的一种通信。后方通道调用从授权服务器请求访问令牌。访问令牌 规定客户端被允许在授权服务器上对用户帐户访问的范围。例如，访问令牌可以指示客户 端被允许只访问用户的阿拉斯加相册的内容。授权服务器把所请求的访问令牌经后方通道 发送回客户端。客户端存储该访问令牌。其后，直到访问令牌到期，或者直到用户宣告该准 许（即，授权码）无效，用户可以向资源服务器呈交该访问令牌，以便访问资源服务器上由 该访问令牌规定的资源。如果用户已经宣告关于该访问令牌的准许无效，则，即使该访问令 牌还没有到期，该访问令牌也变得无效。
[0012] 除了访问令牌，授权服务器还可以向客户端提供"刷新令牌"。虽然访问令牌常常 具有规定的寿命，在此之后它将过期，但刷新令牌是长期令牌。客户端可以连同相关的访问 令牌一起存储刷新令牌。其后，如果资源服务器提出反对，说客户端当前访问令牌已经过 期，则客户端可以向资源服务器呈交刷新令牌，以便从资源服务器获得新的访问令牌。
[0013] 有利地，OAuth采用的方法避免向客户端公开资源服务器上用户帐户的用户密码。 这种凭证公开的避免防止客户端相对于用户在资源服务器上的账户执行未授权的动作。用 户提供其密码的唯一时间是在从客户端站点重定向之后用户与资源服务器的直接初始认 证期间。


【发明内容】

[0014] 本发明的实施例涉及身份管理、认证和授权框架。在一种实施例中，提供了用于在 企业身份和访问管理（IAM)基础设施中集成互联网身份的框架。根据另一种实施例，提供 了用于开放式授权的框架。对于OAuth系统，有许多不同的用例，以至于单一的方法不是总 能适合每个用例。因此，本发明的实施例使OAutii系统更灵活。本发明的实施例使OAuth 系统更容易让该系统的企业管理员为他们自己的使用来定制。本发明的实施例使OAuth系 统更可以由应用和资源提供者定制。
[0015] 传统上，资源服务器和OAuth授权服务器曾经是同一个实体。根据本发明的一个 实施例，提供了把资源服务器从OAuth授权服务器的责任中释放出来的通用框架。这些责 任可以包括范围管理、授权令牌的发布、刷新令牌的发布，以及访问令牌的发布。因而，通用 OAuth授权服务器可以根据这种通用框架来实现。因此，每个个别的资源服务器不需要实现 它自己专属的OAuth授权服务器。实际上，根据本发明的一个实施例，多个不同的资源服务 器可以全部都同时使用同一个通用OAuth授权服务器的功能。例如，在本发明的一个实施 例中，单个OAuth授权服务器可以完全同时地为几个不同的资源服务器管理范围。在资源 服务器和OAuth授权服务器之间可以存在多对一的关系。
[0016] 在本发明的一种实施例中，为了实现与多个不同资源服务器交互的能力，通用 OAuth授权服务器维护指示哪些令牌属于哪些资源服务器、每个资源服务器值得信任的合 作者是谁等的映射数据。此外，在本发明的一个实施例中，该通用OAuth框架是以这样一种 方式构造的，该方式使得资源服务器管理员可以容易地定制该框架，以适应用于他的资源 服务器的特定用例。不同的资源服务器管理员可以把他们的具体部件"插入"通用OAuth框 架中。因而，在本发明的一种实施例中，每个资源服务器通知通用OAuth授权服务器关于该 资源服务器可能使用的潜在范围（即，相对于资源的有限操作）。
[0017] 在参考以下说明书、权利要求和附图之后，以上所述连同其它特征和实施例将变 得更加显然。

【专利附图】

【附图说明】
[0018]图1是根据本发明一个实施例、说明OAuth系统体系架构及其逻辑部件的框图； [0019]图2是根据本发明一个实施例、说明资源服务器环境的框图；
[0020]图3是根据本发明一个实施例、说明〇Auth客户端环境的框图；
[0021]图4是根据本发明一个实施例、说明用于向通用〇Auth授权服务器登记第一资源 服务器的元数据的技术的流程图；
[0022]图5是根据本发明一个实施例、说明用于向OAuth授权服务器登记第二资源服务 器的元数据的技术的流程图；
[0023]图6是说明根据本发明一个实施例可以使用的系统环境的部件的简化框图；及 [0024]图7是根据本发明实施例可以使用的计算机系统的简化框图。 具体实施例
[0025]在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理 解。但是，将认识到，本发明没有这些具体细节也可以实践。于2011年9月29日提交且标 题为"RELYING PARTY AND OAUTH FRAMEWORK"的美国临时专利申请 No. 61/541，026 通过引 用被结合于此。
[0026]图1是根据本发明一个实施例、说明OAuth系统体系架构100及其逻辑部件的框 图。体系架构1〇〇包括资源所有者（或用户）102、客户端应用104、资源寄存器106以及资 源生态系统110。资源生态系统包括客户端寄存器112、令牌-范围寄存器114、范围寄存 器lie、用户同意1 2〇和资源服务器122。虽然示出了一个资源服务器，但是本发明的实施 例可以包括多个独立的资源服务器。如从图1中的连接看到的，客户端应用104和资源寄 存器106交互。资源所有者1〇 2和资源寄存器106并和客户端寄存器112交互。授权服务 器118和客户端寄存器II2、令牌-范围寄存器114及用户同意120交互。资源服务器122 和令牌-范围寄存器114交互。用户同意120和范围寄存器116交互。各种这些部件及其 功能在以下进一步讨论。
[0027] 本发明的实施例可以涉及授权的委托。不同的资源用例有时候需要不同的范围定 义。不同的资源有时候会依赖不同的授权模型和解决方案。会需要不同的具体用户动作来 给予客户端应用访问由不同资源服务器维护的同意。优选地，每个不同的资源提供者应当 不需要提供独立的专属OAuth授权服务器来和那个资源提供者的细节集成。每个资源提供 者提供独立专属OAuth授权服务器的不幸结果将是企业希望和多个不同的资源提供者集 成并且多个不同的客户端形式因子将不得不处理无数不同的OAuth授权服务器接口。
[0028] 因此，在本发明的一个实施例中，提供了通用OAuth框架体系架构。该框架可以包 括OAuth有线协议部件（客户端和服务器），包括元数据和运行时寄存器。该框架可以包括 可插拔"合同"的基础设施，以定制并部署特定于应用的解决方案。
[0029] 在本发明的一种实施例中，资源服务器122在令牌-范围寄存器114中存储资源 服务器122识别的范围指示。每个这种范围可以指示相对于资源服务器122上存储的不同 资源集合可以执行的不同操作集合。因为某些实施例可以包括多个不同的或独立的资源服 务器，所以令牌-范围寄存器114可以存储不同资源服务器和不同范围之间的映射。此外， 在本发明的一种实施例中，每个范围映射到令牌-范围寄存器114中一个独立的令牌。因 而，通过参考令牌-范围寄存器114,资源服务器12 2可以确定映射到由客户端应用104向 资源服务器122呈交的特定令牌的操作集合以及资源集合。资源服务器122可以关于由资 源服务器122维护的资源把客户端应用1〇4执行的操作限定到由映射到该特定令牌的操作 集合具体指示的那些操作。
[0030]因而，在本发明的一种实施例中，多个资源服务器的组中每个特定的资源服务器 向OAuth框架提供不同的元数据集合，元数据集合指示可以映射到可用于访问特定资源 服务器上的资源的令牌的范围。因此，范围是可以由资源服务器的管理员定制的，从而使 OAuth框架灵活并且适用于许多不同的用例。因此，许多不同类型的资源服务器全都可以使 用相同的通用OAuth框架，而无需为每种不同类型的资源服务器创建具体的 0Auth框架。 [0031]在一个实施例中，图1中所示的通用OAuth框架提供了基本的概念结构。OAuth框 架可以叠加在现有的身份管理产品之上。在OAuth框架中，合同可以定义与这些现有产品 的集成点。OAuth框架与合同实现的结合可以满足各种各样的用例和部署选项。根据一个 实施例，OAuth框架包括两个广义的"角色":消费者/客户端角色，以及授权服务器/资源 服务器角色。授权服务器/资源服务器角色在以下参考图2讨论，而消费者/客户端角色 在以下参考图3讨论。
[0032]图2是根据本发明一个实施例、说明资源服务器环境200的框图。在本发明的一个 实施例中，环境2〇〇包括资源所有者（或用户）202、客户端应用204、资源服务器210、OAuth 授权服务器220、策略服务240以及令牌服务250。资源服务器210包括资源服务器应用 212，该应用包括访问令牌确认API 214和门（gate) 216。OAuth授权服务器220包括令牌-范 围寄存器222、资源&范围寄存器224、用户同意编排（orchestration) 226、0PSS_TS (Oracle 平台安全性服务-TS) 228、0PSS-AZ (Oracle平台安全性服务-AZ) 230、OAuth核心引擎232、 OAuth协议引擎2：34以及客户端寄存器236·^在一个实施例中，资源所有者202通过门216 和客户端应用204交互，其中门216访问访问令牌确认API214。客户端应用204还和OAuth 授权服务器220交互。访问令牌确认API214和令牌-范围寄存器222并和策略服务240 交互。0PSS-TS和令牌服务250交互。0PSS-AZ和策略服务250交互。部件228-234集合 起来和令牌-范围寄存器222并和资源&范围寄存器224交互。用户同意编排226与资源 &范围寄存器224交互。
[0033] 在本发明的一个实施例中，资源&范围寄存器224存储与经OAuth授权服务器220 暴露的资源和服务相关的资源信息、范围和各种各样的元数据。在本发明的一个实施例中， 客户端寄存器236存储用于被授权的远端客户端（例如，客户端应用204)的信任密钥和 秘密。在一个实施例中，令牌-范围寄存器222存储基于用户（例如，资源所有者202)同 意而发布给客户端（例如，客户端应用204)的访问令牌和刷新令牌。在一个实施例中，令 牌-范围寄存器222存储与所发布的访问令牌相关联的AuthZ范围信息。
[0034] 在本发明的一个实施例中，资源服务器210向OAuth授权服务器220登记其自己 的元数据。不同的资源服务器可以向同一个OAuth授权服务器登记不同的元数据。作为登 记过程的一部分，这种元数据导入OAuth授权服务器220。元数据指示由资源服务器210识 别，或者暴露，的各种不同范围。每个范围规定由资源服务器210维护的不同资源子集。在 本发明的一个实施例中，在登记时，由资源服务器210识别的每个范围映射到（只）资源& 范围寄存器224中的资源服务器210。因而，在本发明的一个实施例中，对于每个登记的范 围，资源&范围寄存器指示在那个范围内可访问的对应资源服务器的资源集合。范围可以 指示，例如，只有一张特定的照片可以被访问，或者一个特定的照片文件夹可以被访问，或 者特定的文件夹集合可以被访问。范围可以指示相对于规定的资源被允许的操作，诸如读 取、更新、删除、创建，等等。
[0035] 在本发明的一个实施例中，OAuth授权服务器220向客户端应用204发布访问令 牌。在一个实施例中，对于每个这种访问令牌，OAuth授权服务器220在令牌-范围寄存器 222中存储访问令牌和指定给那个访问令牌的特定范围（选自资源&范围寄存器224中所 存储的范围）之间的映射。用于同一资源服务器的不同访问令牌可以具有指定给它们的不 同范围。因而，当客户端应用204向OAuth授权服务器220呈交访问令牌时，OAuth授权服 务器220可以参考令牌-范围寄存器222来确定映射到那个访问令牌的范围，然后可以参 考资源&范围寄存器224来确定在那个范围内可访问的资源。
[0036] 在本发明的一个实施例中，为了让OAuth授权服务器220向客户端应用204准许 访问令牌，需要来自资源所有者202的用户同意。例如，如果客户端应用204请求对来自资 源服务器210的特定资源（或者包括那个资源的特定范围）的访问，则资源服务器210可 以把该请求重定向到OAuth授权服务器220。OAuth授权服务器220可以调用用户同意编 排226,以便请求资源所有者202验证客户端应用204应当被准许访问该特定的资源（或特 定的范围）。在一个实施例中，用户同意编排226向资源所有者202指示客户端应用204寻 求访问的范围，并且向资源所有者202提供同意或拒绝对那个范围的访问的机会。更具体 而言，OAuth授权服务器220可以请求资源所有者220验证客户端应用204应当被准许对 由包括特定资源的特定范围规定的访问（如在资源&范围寄存器224中所指示的）。响应 于从资源所有者202接收到同意，OAuth授权服务器220可以生成访问令牌并且在令牌-范 围寄存器222中存储那个访问令牌和该特定范围之间的映射。OAuth授权服务器220可以 向客户端应用204提供该访问令牌。
[0037] 然后，通过向资源服务器应用212呈交访问令牌，客户端应用204可以尝试访问资 源服务器210上的特定资源。资源服务器应用212上的代理可以截获令牌并且在允许客 户端应用204访问特定资源之前利用OAuth授权服务器220确认该令牌（例如，经访问令 牌确认API214)。如果客户端应用204尝试访问的特定资源不在映射到令牌-范围寄存器 222中的访问令牌的范围内（例如，如果客户端应用204尝试访问在资源所有者202之前同 意访问的范围之外的文件夹），则OAuth授权服务器220将不确认该令牌，并且资源服务器 210将拒绝准许客户端应用204访问特定的资源。因为，访问的范围是基于资源所有者202 对那个范围的具体同意。资源所有者202有机会拒绝向客户端应用204所请求的具体范围 给予同意，在这种情况下，OAuth授权服务器220将不为客户端应用204创建访问令牌。在 本发明的一种实施例中，每个客户端应用访问由资源服务器210维护的资源的请求还规定 映射到资源&范围寄存器224中的资源服务器210的范围，并且就是为这个规定的范围请 求资源所有者202的同意，如以上所讨论的。
[0038] 根据本发明的一个实施例，与以上所讨论的一致，在客户端应用2〇4向资源服务 器210呈交访问令牌的时候，访问约束的强制执行发生。强制执行需要对由访问令牌编码 的范围的理解。访问令牌是由OAuth授权服务器220经范围定义发布的。访问令牌经由所 发布的令牌编码的范围来确认。在本发明的一种实施例中，策略服务240和令牌服务250 相结合来维护所发布的访问令牌的状态并且授权所发布的访问令牌。在本发明的一个实施 例中，消费者（即，资源服务器210的运营者和/或所有者）可以提供其自己的策略服务 240和令牌服务250。OAuth框架可以提供编程合同或编程接口，通过这些合同或接口，这 种消费者可以把他们自己的策略和令牌服务以匹配那些消费者定义的范围的方式插入到 OAuth框架中。每个消费者可以公布它自己的范围集合。所公布的范围集合可以指示消费 者的令牌服务将返回的数据的形式。OAuth框架附加地可以向这种消费者提供允许策略在 令牌发布时创建的编程合同或编程接口。这些编程合同或编程接口允许消费者把他们自己 的定制编程代码插入OAuth框架。利用这些编程接口，消费者可以把其现有的基础设施连 接到OAuth系统中。在一个实施例中，公布其范围集合的消费者负责确保其令牌和/或策 略服务返回包括与所公布范围一致的范围信息的令牌。响应于客户端应用204尝试使用令 牌，OAuth授权服务器220可以调用将查找消费者的策略并确认那个令牌的应用编程接口 (API)。
[0039] 在一个实施例中，OAuth框架规定消费者的代码（例如，用于令牌服务250和策略 服务240的代码）为了与OAuth授权服务器220接口而需要实现的接口。该接口可以公布， 使得消费者意识到每个接口期望接收的参数以及每个接口期望返回的值。当客户端应用 204对OAuth授权服务器220作出请求时，OAuth授权服务器220对与那个请求相关的API 作出响应性调用。例如，这些调用可以涉及对例如生成访问令牌并且把那些访问令牌提供 给客户端应用204的消费者编码的部件的调用。在本发明的一种实施例中，OAuth授权服 务器220以0PSS-TS228和0PSS-AZ230的形式暴露以上提到的编程合同或编程接口。消费 者自己对令牌服务250的实现可以与0PSS-TS228接口，而消费者自己对策略服务240的实 现可以与0PSS-AZ230接口。OAuth授权服务器220可以调用独立的API，来进行访问令牌 的创建和访问令牌的确认。消费者可以实现执行每个任务的定制编程代码。在确认期间， 在令牌创建过程中构造的策略可以被访问，以确定客户端应用204相对于资源寻求执行的 动作是否匹配通过客户端应用204呈交的访问令牌编码的策略。
[0040] 此外，在本发明的一种实施例中，消费者自己对用户同意编排226的实现可以插 入到OAuth授权服务器220中，其中用户同意编排226在客户端应用204寻求来自OAuth 授权服务器220的访问令牌时被调用。到资源&范围寄存器224和令牌-范围寄存器222 的接口可以向消费者提供，使得消费者可以设计其对用户同意编排226的实现，以便从部 件222和224获得在构造同意请求时使用的数据。
[0041]在本发明的一个实施例中，存储在资源&范围寄存器224中的映射不仅指示包括 在每个范围中的资源子集，并且指示被允许由客户端应用相对于那些资源子集执行的排他 性操作子集。例如，特定的映射可以指示读取和更新操作但是无创建或删除操作可以相对 于资源服务器210上维护的资源（例如，文件、文件夹、目录、列表、简档、图像、文档等）的 规定子集执行的特定范围。因而，在本发明的一种实施例中，以上所讨论的同意请求不仅规 定与一个范围关联的资源子集，并且规定与那个范围关联的操作子集。因此，资源所有者 2〇2精确地知道他同意客户端应用204相对于在同意请求所规定范围内的资源子集执行的 操作的种类。
[0042] 根据本发明的一个实施例，客户端应用204请求等效于资源服务器210已经向 OAuth授权服务器220登记的具体范围之一的资源访问。因而，在本发明的一种实施例中， 客户端应用204利用意识到将为资源服务器210登记的具体范围来设计。因为客户端应用 204可以和由各个不同资源服务器维护的资源交互，所以各个资源服务器的供应者可以对 它们的资源服务器将向OAuth授权服务器220登记的标准范围集合取得一致，由此减轻设 计者对客户端应用204和其它客户端应用的设计任务。
[0043] 在本发明的一种实施例中，提供了客户端框架，以便允许客户端应用，诸如客户 端应用204,实现用于各种不同类型资源提供者的"钩子"。例如，客户端应用204可以为 Google、Facebook、Yahoo、Linkedln等实现独立的钩子。图3是根据本发明一个实施例、 说明OAuth客户端环境300的框图。OAuth客户端环境300包括资源所有者302、资源服务 器304、OAuth授权服务器306、客户端应用308以及OAuth客户端320。客户端应用308包 括OAuth客户端API310。OAuth客户端320包括OAuth客户端引擎322、资源寄存器324、 本地应用寄存器326以及令牌寄存器328。资源服务器304和OAuth授权服务器306彼此 交互。资源服务器304和OAuth客户端320彼此交互。OAuth授权服务器306和OAuth客 户端320经资源所有者302 (例如，通过由资源所有者302的互联网浏览器实现的重定向） 彼此交互。资源所有者302还和客户端应用308交互。客户端应用308通过OAuth客户端 API310和OAuth客户端引擎322交互。OAuth客户端引擎322和资源寄存器324、本地应用 寄存器326及令牌寄存器328交互。
[0044] 根据本发明的一个实施例，关于客户端应用308可以与之交互的所有不同类型的 资源服务器的元数据都存储在资源寄存器324中，使得客户端应用308能够与各种不同的 资源服务器交互。资源寄存器可以指示，例如，由每个不同类型资源服务器识别的不同范围 集合。因此，客户端应用308能够请求对应于由资源服务器304识别的特定范围的访问，并 且这个特定的范围可以在OAuth授权服务器306代表客户端应用308发送到资源所有者 3〇2的同意请求中规定。资源提供者可以公布他们与OAuth标准兼容的范围规范，使得设 计者可以利用用于那些提供者的资源服务器的适当服务器到范围映射来填充资源寄存器 3〇8。在一个实施例中，因为资源寄存器308可以独立于客户端应用308来填充，所以客户 端应用308不需要为了与新发现的资源服务器交互而修订；相反，开发者可以简单地把用 于那些资源服务器的新映射"插入"客户端应用308与之交互的资源寄存器324中。
[0045] 充当资源提供者或服务器的复杂网站常常不是整体式的应用。相反，复杂的网站 常常由多个不同的应用组成。在本发明的一个实施例中，本地应用寄存器326存储各个不 同资源提供者和由那些资源提供者提供或暴露的应用集合之间的映射。每个这种应用都可 以在本地应用寄存器326中映射到用于那个应用的独立的统一资源定位器（URL)。在本发 明的一种实施例中，本地应用寄存器326存储信任密钥，以行使（exercise)访问远端资源 的OAuth客户端角色。
[0046] 通常，客户端应用3〇8能够使用一个特定的访问令牌多次，以便在那个特定的访 问令牌到期之前访问由资源服务器3〇4维护的资源。在本发明的一个实施例中，客户端应 用3〇8从OAuth授权服务器306获得的访问令牌存储在令牌寄存器328中。因为客户端应 用3〇 8可以与多个不同的资源服务器交互，所以令牌寄存器328可以维护访问令牌和与那 些访问令牌有关的不同资源服务器之间的映射。令牌寄存器328可以存储用于各种不同远 端资源服务器（例如，资源服务器304)以及范围的访问令牌和刷新令牌。
[0047] 图4是根据本发明一个实施例、说明用于向通用OAuth授权服务器登记第一资源 服务器的元数据的技术400的流程图。虽然技术400涉及某些方框或操作，但是备选实施 例可以涉及比所说明的那些更多、更少或不同的操作。此外，备选实施例可以涉及以与所说 明次序不同的次序对操作的执行。在方框402中，OAuth授权服务器从第一资源服务器接 收指示由第一资源服务器识别的第一范围集合的第一元数据集合。在方框404中，响应于 接收到第一元数据集合，OAuth授权服务器存储第一范围集合中的范围和由第一资源服务 器维护的资源子集之间的映射。在一种实施例中，响应于接收到第一元数据集合，OAuth授 权服务器存储特定范围、由第一资源服务器存储的资源子集和映射到该特定范围的特定令 牌的持有者被允许相对于第一资源子集中的资源执行的操作集合之间的映射。
[0048] 在方框406中，OAuth授权服务器接收规定来自第一范围集合的第一范围的特定 请求。在方框408中，响应于接收到规定该第一范围的请求，OAuth授权服务器请求包含 在该第一范围中的资源的所有者同意准许与第一范围一致的客户端应用访问。在方框41〇 中，响应于从所有者接收到同意，OAuth授权服务器（a)创建第一访问令牌，（b)存储第一访 问令牌和第一范围之间的映射，并且（c)向客户端应用发送第一访问令牌。在一种实施例 中，响应于从所有者接收到同意，OAuth授权服务器调用由不提供OAuth授权服务器的消费 者（例如，第一资源服务器的所有者）提供的编程代码。该编程代码实现由OAuth授权服 务器的提供者提供给消费者的接口。该编程代码创建第一访问令牌。
[0049] 在方框412中，OAuth授权服务器从第一资源服务器接收确认第一访问令牌的请 求。在方框414中，响应于接收到确认第一访问令牌的请求，OAuth授权服务器基于第一访 问令牌和第一范围之间的映射确认第一访问令牌。在一种实施例中，为了确认第一访问令 牌，OAuth授权服务器调用由不提供OAuth授权服务器的消费者（例如，第一资源服务器的 所有者）提供的编程代码。该编程代码实现由OAuth授权服务器的提供者提供给消费者的 接口。该编程代码确认第一访问令牌。
[0050] 在方框416中，响应于确认第一访问令牌，OAuth授权服务器向第一资源服务器指 示向第一资源服务器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维 护并由第一范围规定的资源集合执行操作。
[0051] 图5是根据本发明一个实施例、说明用于向通用OAuth授权服务器登记第二资源 服务器的元数据的技术的流程图。虽然技术500涉及某些方框或操作，但是备选实施例可 以涉及比所说明的那些更多、更少或不同的操作。此外，备选实施例可以涉及以与所说明次 序不同的次序对操作的执行。在方框502中，OAuth授权服务器从与第一资源服务器（在图 4中引用）分开的第二资源服务器接收指示由第二资源服务器识别的第二范围集合的第二 元数据集合，该第二范围集合与第一范围集合（在图4中引用）不同。在方框504中，响应 于接收到第二元数据集合，OAuth授权服务器存储第二范围集合中的范围和由第二资源服 务器维护的资源子集之间的映射。在方框506中，OAuth授权服务器存储第二访问令牌和 来自第二范围集合的第二范围之间的映射。在方框5〇 8中，OAuth授权服务器从第二资源 服务器接收确认第二访问令牌的请求。在方框510中，响应于接收到确认第二访问令牌的 请求，OAuth授权服务器基于第二访问令牌和第二范围之间的映射确认第二访问令牌。在 方框512中，响应于确认第二访问令牌，OAuth授权服务器向第二资源服务器指示向第二资 源服务器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二 范围规定的资源集合执行操作。 ' ^ 一
[0052]图6是说明可以根据本发明的一个实施例使用的系统环境6〇〇的部件的简化框 图。如所不出的，系统环境600包括一个或多个客户端计算设备6〇2、604、606、608，这些客 户端计算设备配置为操作诸如web浏览器、专属客户端（例如， 0racle F〇rms)等的客户端 应用。在各种实施例中，客户端计算设备602、604、606、608可以和服务器612交互。
[0053] 客户端计算设备6〇2、604、606、608可以是通用个人计算机（作为例子，包括运行 各种版本的Microsoft Windows和/或Apple Macintosh操作系统的个人计算机和/或 膝上型计算机）、智能电话或PDA(运行诸如Microsoft Windows Mobile的软件并且启用 Internet、电子邮件、SMS、Blackberry或其它通信协议），和/或运行各种商业可用的UNIX 或像UNIX的操作系统（包括但不限于各种GNU/Linux操作系统）中任何一种的工作站计 算机。作为替代，客户端计算设备602、 6〇4、606、608可以是能够经网络（例如，以上所述的 网络610)通信的任何其它电子设备，诸如瘦客户端计算机、启用互联网的游戏系统，和/或 个人发消息设备。虽然不例性系统环境600不为具有四个客户端计算设备，但是任意数量 的客户端计算设备都可以被支持。诸如带传感器的设备等的其它设备可以和服务器 612交 互。
[0054] 系统环境600可以包括网络610。网络610可以是本领域技术人员熟悉的、可以 利用各种商业可用的协议中任何一种支持数据通信的任何类型的网络，包括但不限于TCP/ 1?、3嫩、1?14口1)1(^11^等。仅仅是作为例子，网络610可以是局域网（1^)，诸如以太网、 令牌环网等；广域网；虚拟网，包括但不限于虚拟专用网（VPN);互联网；内联网；外联网； 公共交换电话网（PSTN);红外线网络；无线网络（例如，在本领域中已知的IEEE802.il协 议套件、蓝牙协议和/或任何其它无线协议下运行的网络）；和/或这些和/或其它网络的 任意组合。
[0055] 系统环境600还包括一个或多个服务器计算机612,这可以是通用计算机、专用服 务器计算机（作为例子，包括PC服务器、UNIX服务器、中档服务器、大型计算机、机架式服务 器等）、服务器场、服务器集群，或者任何其它适当的布置和/或组合。在各种实施例中，服 务器612可以适于运行前面公开内容中所描述的一个或多个服务或软件应用。例如，服务 器61 2可以对应于根据本发明的一个实施例用于执行依赖方和开放式授权处理的服务器。 [0056] 服务器612可以运行包括以上讨论的那些当中任何一个以及任何商业可用的服 务器操作系统的操作系统。服务器612还可以运行各种附加的服务器应用和/或中间层应 用中任何一种，包括HTTP服务器、FTP服务器、CGI服务器、Java服务器、数据库服务器等。 不例性数据库服务器包括但不限于从Oracle、Microsoft.、Sybase、IBM等可商业获得的那 些服务器。
[0057] 系统环境600还可以包括一个或多个数据库614、616。数据库614、616可以驻留 在各个位置。作为例子，数据库614、616中的一个或多个可以驻留在服务器612本地的非 临时性存储介质中（和/或驻留在服务器612中）。作为替代，数据库614、 616可以远离 服务器612,并且经基于网络的或者专用的连接与服务器612通信。在一组实施例中，数据 库614、616可以驻留在本领域技术人员熟悉的存储区域网络（SAN)中。类似地，用于执行 属于服务器612的功能的任何必要的文件都可以适当地本地存储在服务器 612上和/或远 端存储。在一组实施例中，数据库614、616可以包括适于响应于SQL格式化的命令而存储、 更新和检索数据的关系数据库，诸如由Oracle提供的数据库。
[0058]图7是可以根据本发明实施例使用的计算机系统700的简化框图。例如，服务器 602可以利用诸如系统700的系统实现。计算机系统700示为包括可以经总线724电耦合 的硬件元件。硬件元件可以包括一个或多个中央处理单元（CPU) 702、一个或多个输入设备 704 (例如，鼠标、键盘等），以及一个或多个输出设备7〇6 (例如，显示设备、打印机等）。计 算机系统700还可以包括一个或多个存储设备70S。作为例子，存储设备708可以包括诸如 盘驱动器、光学存储设备以及诸如随机存取存储器（RAM)和/或只读存储器（ROM)的固态 存储设备的设备，这些设备可编程、可闪存更新（flash-updateable)等。
[0059] 计算机系统700可以附加地包括计算机可读存储介质读取器712、通信子系统 714 (例如，调制解调器、网卡（无线或有线）、红外线通信设备等），以及可以包括如上所述 RAM和ROM设备的工作存储器718。在有些实施例中，计算机系统700还可以包括处理加速 单元716,这可以包括数字信号处理器（DSP)、专用处理器等。
[0060] 计算机可读存储介质读取器712还可以连接到计算机可读存储介质710,一起（并 且，可选地，结合存储设备708)综合地代表远端、本地、固定和/或可移除的存储设备外加 用于暂时地和/或更持久地包含计算机可读信息的存储介质。通信系统714可以允许数据 利用网络leio和/或以上关于系统环境woo所述的任何其它计算机交换。
[0061] 计算机系统7〇〇还可以包括软件元件，示为目前位于工作存储器718中，包括操作 系统720和/或其它代码722,诸如应用程序（可以是客户端应用、Web浏览器、中间层应 用、RDBMS等）。在示例性实施例中，工作存储器718可以包括可执行代码和用于如上所述 依赖方和开放式授权相关的处理的相关联数据结构。应当认识到，计算机系统700的备选 实施例可以具有与以上所述不同的多种变化。例如，定制的硬件也可以使用和/或特定的 元件可以在硬件、软件（包括便携式软件，诸如小应用程序（applet))或者二者当中实现。 另外，可以采用到诸如网络输入/输出设备的其它计算设备的连接。
[0062]用于包含代码或者代码部分的存储介质和计算机可读介质可以包括本领域中已 知或使用的任何适当介质，包括存储介质和通信介质，诸如但不限于以用于信息存储和/ 或发送的任何方法或技术，诸如计算机可读指令、数据结构、程序模块或其它数据，实现的 易失性和非易失性（非暂时性）的、可移除和不可移除的介质，包括RAM、R0M、EEPR0MJX|# 存储器或其他存储器技术、CD-ROM、数字通用盘（DVD)或其它光学储存器、磁带盒、磁带、磁 盘储存器或者其它磁性存储设备、数据信号、数据传输，或者可以用于存储或发送期望信息 并可以被计算机访问的任何其它介质。
[0063] 虽然已经描述了本发明的具体实施例，但是各种修改、变更、备选构造和等价物也 包含在本发明的范围内。本发明的实施例不限于某些具体数据处理环境中的操作，而是自 由地在多种数据处理环境中操作。此外，虽然本发明的实施例已经利用特定的事务和步骤 序列进行了描述，但是本领域技术人员应当认识到，本发明的范围不限于所述的事务和步 骤序列。
[0064]另外，虽然本发明的实施例已经利用硬件和软件的特定组合进行了描述，但是应 当认识到，硬件和软件的其它组合也在本发明的范围内。本发明的实施例可以只在硬件中、 只在软件中或者利用其组合来实现。
[0065] 相应地，说明书和附图应当在说明性而不是约束性的意义上看待。但是，很显然， 在不背离最广泛主旨和范围的情况下，可以对其进行增加、减少、删除及其它修改和变化。

【背景技术】 [0066]
[0067] 本发明的实施例涉及身份管理、认证及授权框架。
[0068] 简要概述
[0069] 本发明的实施例涉及身份管理、认证及授权框架。在一种实施例中，提供了用于在 企业身份和访问管理（IAM)基础设施中集成互联网身份的框架。根据另一种实施例，提供 了用于开放式授权的框架。还提供了用于依赖方功能性的框架。
[0070] 参考以下说明书、权利要求和附图，以上所述连同其它特征和实施例将变得更加 显然。

【专利附图】

【附图说明】 [0071]
[0072] 在这个文档中包括几个附图。
[0073] 另外，图1是说明根据本发明一个实施例可以使用的系统环境的部件的简化框 图；及
[0074]图2是说明根据本发明一个实施例可以使用的计算机系统的简化框图。
[0075] 具体实施例
[0076] 在以下描述中，为了解释，阐述了具体的细节，以便提供对本发明实施例的透彻理 解。但是，很显然，本发明没有这些具体细节也可以实践。
[0077] 特征:
[0078] ⑴用于在现有企业身份和访问管理（IAM)基础设施中集成互联网身份的依赖方 平台/框架
[0079] 企业，尤其是具有面向互联网的属性（网站、电子商务应用、移动应用等）的那 些企业，期望朝着获得更高采纳和更高收入而拓展他们的用户群。"互联网身份"是在 像Facebook、Google、Yahoo等公共站点保留的用户帐户-这些是数千万用户的宝库 (treasure trove)。同时,企业在没有配备成处理这些身份的IAM系统中有现有的投资； 二者都是就与这些变化的技术集成以及面向互联网的部署的规模和安全性方面而言的。有 些现有的解决方案是定制的/自组织的（ad hoc)/点对点的/拍的（slapped-on)/昂贵 的-"创可贴" 一样一起放到企业上。有些产品提供一些集成解决方案，但是它们过于绑 定到产品。整体上看，现有的解决方案缺乏既解决应付变化的互联网环境的问题又保留现 有IAM解决方案中投资的可扩充性、可缩放性和安全性。
[0080] 根据本发明的一个实施例，提供了具有以下特征的框架或平台：
[0081] ?用于众所周知的互联网身份提供者（IDP)，诸如Google、Yahoo、Facebook、 Linkedln、Twitter等，的内置连接器。
[0082] ?与兼容IDP集成的、基于标准的接口（0penID、0Auth(开放式授权）、安全访问标 记语言（SAML)等）。
[0083] ?用于引导IAM供应商（诸如Oracle、CA、IBM等）的内置集成。
[0084] ?经抽象工作流/过程之上分层的插件点来定制以满足具体部署需求的可扩充 性。
[0085] 示例工作流过程流：
[0086]-用户向IDP认证，这导致适当水平的企业会话创建。
[0087]-渐进式用户注册。
[0088]-经与"本地"认证集成的基于策略的认证升级（up-leveling)。
[0089] 实施例提供了几个新颖的特征，包括但不限于关于框架、基于工作流/过程的插 件、渐进式和按需/应用驱动的用户进入（on boarding)和认证等的特征。
[0090] 本发明的一个实施例提供了优于现有解决方案的显著改进。抽象工作流/过程模 型允许企业处理商业用例，而不是关于产品细节的专门技术。本发明的一个实施例可以结 合从小型（例如，简单LDAP、基于JESSI0NID的）到大规模IAM部署的各种IAM解决方案一 起使用。
[0091] (2)0Auth 框架
[0092] 企业需要经互联网与几个实体（消费者、员工、合作者、云服务等）交互，以保留竞 争性并成长。社交网络和以用户为中心的身份的最新进展已经导致公司集合起来创建一个 称为OAuth的开放式标准，以方便企业之间安全的域间通信。广义地讲，这个标准覆盖从一 个域到另一个域对服务和资源的点到点安全访问。服务/资源一般性地分成以下的类：
[0093]-用户控制的数据-诸如用户的日历、照片、联系人列表等
[0094]-企业控制的数据-诸如CRM SaaS服务、消费者列表、用户管理数据、用户供应 (provisioning)服务、SLA 等
[0095] 这些服务/资源可以在内部或在云上托管。
[0096] 对于经广大的互联网共享数据和资源，由于其简单性和互联网缩放性，0Auth2. 0 已经在最近两年内获得了极大的普及。
[0097] 现有解决方案是基于个别资源/服务所有者提供的"工具箱"，通常对于每个客户 端形式因子有一个不同的"工具箱"：手机、web浏览器、web服务器、独立应用等。问题是， 虽然OAuth是标准的，但它不是"可互操作的"规范-因此每个个别的工具箱以其自己的 具体方式实现协议和交互。因此，希望与多个合作者集成并且处于不同客户端形式因子的 企业具有处理无数工具箱的巨大挑战。而且，好的实现需要能够处理细粒度和动态的策略 的健壮授权模型，以确保数据安全性及其可说明性（accountability)(例如，适应变化的 商业关系）。
[0098] 有些现有解决方案是定制的/自组织的/点对点的/拍的/昂贵的-"创可贴" 一样一起放到企业上，它们不能与现有的企业IAM部署良好地集成。整体上，现有解决方案 缺乏既解决应付变化的互联网环境的问题又保留现有IAM解决方案中的投资的可扩充性、 可缩放性和安全性。
[0099] 本发明的一个实施例提供了具有以下特征的OAuth框架或平台：
[0100] ?用于众所周知的互联网资源和授权服务器，诸如Google Docs、Yahoo、Facebook、 Linkedln、Twitter、Salesforce.com、Oracle 0D、Oracle Web Center 等，的内置连接器。
[0101] ?用于引导IAM供应商（诸如Oracle、CA、IBM等）的内置集成。
[0102] ?经抽象工作流/过程之上分层的插件点来定制以满足具体部署需求的可扩充 性。
[0103] 在一种实施例中，工作流过程流如下：
[0104] -用户授权导致用于资源/服务访问的令牌发布。
[01 05]-对远端服务/资源的应用驱动的访问。
[0106]-本地资源/服务对合作者实体的基于策略的暴露。
[0107]-令牌生命周期-用户驱动的、管理员驱动的、策略驱动的。
[0108]实施例提供了几个新颖特征，包括关于框架/平台、基于工作流/过程的插件、按 需/应用驱动的资源访问等的特征。
[0109]本发明的一个实施例提供了优于现有解决方案的几个改进。抽象工作流/过程模 型允许企业处理商业用例而不是关于产品细节的专门技术。本发明的一个实施例可以与从 小型（例如，简单LDAP、基于JSESSIONID的）到大规模IAM部署的各种 IAM解决方案一起 使用。
[0110] 更多细节在以下章节/部分（部分1至7)中描述。以下各个部分描沭各种实施 例；该描述本质上不是约束性或限制性的。
[0111] 第一部分
[0112]

【权利要求】
1. 一种方法，包括： 在OAuth授权服务器处，从第一资源服务器接收指示由第一资源服务器识别的第一范 围集合的第一元数据集合； 响应于接收到第一元数据集合，在OAuth授权服务器处，存储第一范围集合中的范围 和由第一资源服务器维护的资源子集之间的映射； 在OAuth授权服务器处，存储第一访问令牌和来自第一范围集合的第一范围之间的映 射； 在OAuth授权服务器处，从第一资源服务器接收确认第一访问令牌的请求； 响应于接收到确认第一访问令牌的请求，OAuth授权服务器基于第一访问令牌和第一 范围之间的映射确认第一访问令牌；及 响应于确认第一访问令牌，OAuth授权服务器向第一资源服务器指示向第一资源服务 器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规 定的资源集合执行操作。
2. 如权利要求1所述的方法，还包括： 在OAuth授权服务器处，接收规定第一范围的特定请求； 响应于接收到规定第一范围的请求，OAuth授权服务器请求包含在第一范围中的资源 的所有者同意准许与第一范围一致的客户端应用访问； 响应于从所有者接收到同意，OAuth授权服务器（a)创建第一访问令牌，（b)存储第一 访问令牌和第一范围之间的映射，并且（c)向客户端应用发送第一访问令牌。
3. 如权利要求1所述的方法，还包括： 响应于接收到第一元数据集合，在OAuth授权服务器处，存储第一范围、由第一资源服 务器存储的第一资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子 集中的资源执行的第一操作集合之间的映射。
4. 如权利要求1所述的方法，其中确认第一访问令牌包括OAuth授权服务器调用由不 提供OAuth授权服务器的消费者提供的编程代码；其中该编程代码实现由OAuth授权服务 器的提供者提供给消费者的接口；其中该编程代码确认第一访问令牌。
5. 如权利要求1所述的方法，还包括： 在OAuth授权服务器处，接收规定第一范围的特定请求； 响应于接收到规定第一范围的请求，OAuth授权服务器请求包含在第一范围中的资源 的所有者同意准许与第一范围一致的客户端应用访问； 响应于从所有者接收到同意，OAuth授权服务器调用由不提供OAuth授权服务器的消 费者提供的编程代码；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的 接口；其中该编程代码创建第一访问令牌。
6. 如权利要求1所述的方法，还包括： 在OAuth授权服务器处，从与第一资源服务器分开的第二资源服务器接收指示由第 二资源服务器识别的第二范围集合的第二元数据集合，该第二范围集合与第一范围集合不 同； 响应于接收到第二元数据集合，在OAuth授权服务器处，存储第二范围集合中的范围 和由第二资源服务器维护的资源子集之间的映射； 在OAuth授权服务器处，存储第二访问令牌和来自第二范围集合的第二范围之间的映 射； 在OAuth授权服务器处，从第二资源服务器接收确认第二访问令牌的请求； 响应于接收到确认第二访问令牌的请求，OAuth授权服务器基于第二访问令牌和第二 范围之间的映射确认第二访问令牌；及 响应于确认第二访问令牌，OAuth授权服务器向第二资源服务器指示向第二资源服务 器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规 定的资源集合执行操作。
7. -种包括指令的计算机可读存储器，指令当被一个或多个处理器执行时，使这一个 或多个处理器执行： 在OAuth授权服务器处，从第一资源服务器接收指示由第一资源服务器识别的第一范 围集合的第一元数据集合； 响应于接收到第一元数据集合，在OAuth授权服务器处，存储第一范围集合中的范围 和由第一资源服务器维护的资源子集之间的映射； 在OAuth授权服务器处，存储第一访问令牌和来自第一范围集合的第一范围之间的映 射； 在OAuth授权服务器处，从第一资源服务器接收确认第一访问令牌的请求； 响应于接收到确认第一访问令牌的请求，OAuth授权服务器基于第一访问令牌和第一 范围之间的映射确认第一访问令牌；及 响应于确认第一访问令牌，OAuth授权服务器向第一资源服务器指示向第一资源服务 器呈交第一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规 定的资源集合执行操作。
8. 如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时， 还使这一个或多个处理器执行： 在OAuth授权服务器处，接收规定第一范围的特定请求； 响应于接收到规定第一范围的请求，OAuth授权服务器请求包含在第一范围中的资源 的所有者同意准许与第一范围一致的客户端应用访问； 响应于从所有者接收到同意，OAuth授权服务器（a)创建第一访问令牌，（b)存储第一 访问令牌和第一范围之间的映射，并且（c)向客户端应用发送第一访问令牌。
9. 如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行时， 还使这一个或多个处理器执行： 响应于接收第一元数据集合，在OAuth授权服务器处，存储第一范围、由第一资源服务 器存储的第一资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子集 中的资源执行的第一操作集合之间的映射。
10. 如权利要求7所述的计算机可读存储器，其中确认第一访问令牌包括OAuth授权 服务器调用由不提供OAuth授权服务器的消费者提供的编程代码；其中该编程代码实现由 OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码确认第一访问令牌。
11. 如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行 时，还使这一个或多个处理器执行： 在OAuth授权服务器处，接收规定第一范围的特定请求； 响应于接收到规定第一范围的请求，OAuth授权服务器请求包含在第一范围中的资源 的所有者同意准许与第一范围一致的客户端应用访问； 响应于从所有者接收到同意，OAuth授权服务器调用由不提供OAuth授权服务器的消 费者提供的编程代码；其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的 接口；其中该编程代码创建第一访问令牌。
12. 如权利要求7所述的计算机可读存储器，其中，指令当被一个或多个处理器执行 时，还使这一个或多个处理器执行： 在OAuth授权服务器处，从与第一资源服务器分开的第二资源服务器接收指示由第 二资源服务器识别的第二范围集合的第二元数据集合，该第二范围集合与第一范围集合不 同； 响应于接收到第二元数据集合，在OAuth授权服务器处，存储第二范围集合中的范围 和由第二资源服务器维护的资源子集之间的映射； 在OAuth授权服务器处，存储第二访问令牌和来自第二范围集合的第二范围之间的映 射； 在OAuth授权服务器处，从第二资源服务器接收确认第二访问令牌的请求； 响应于接收到确认第二访问令牌的请求，OAuth授权服务器基于第二访问令牌和第二 范围之间的映射确认第二访问令牌；及 响应于确认第二访问令牌，OAuth授权服务器向第二资源服务器指示向第二资源服务 器呈交第二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规 定的资源集合执行操作。
13. -种OAuth授权服务器，包括： 配置为从第一资源服务器接收指示由第一资源服务器识别的第一范围集合的第一元 数据集合的一个或多个硬件处理器； 配置为，响应于接收到第一元数据集合，存储第一范围集合中的范围和由第一资源服 务器维护的资源子集之间的映射的一个或多个硬件处理器； 配置为存储第一访问令牌和来自第一范围集合的第一范围之间的映射的一个或多个 硬件处理器； 配置为从第一资源服务器接收确认第一访问令牌的请求的一个或多个硬件处理器； 配置为，响应于接收到确认第一访问令牌的请求，基于第一访问令牌和第一范围之间 的映射确认第一访问令牌的一个或多个硬件处理器；及 配置为，响应于确认第一访问令牌，向第一资源服务器指示向第一资源服务器呈交第 一访问令牌的客户端应用被授权相对于由第一资源服务器维护并由第一范围规定的资源 集合执行操作的一个或多个硬件处理器。
14. 如权利要求13所述的OAuth授权服务器，还包括： 配置为接收规定第一范围的特定请求的一个或多个硬件处理器； 配置为，响应于接收到规定第一范围的请求，请求包含在第一范围中的资源的所有者 同意准许与第一范围一致的客户端应用访问的一个或多个硬件处理器； 配置为，响应于从所有者接收到同意，（a)创建第一访问令牌，（b)存储第一访问令牌 和第一范围之间的映射，并且（C)向客户端应用发送第一访问令牌的一个或多个硬件处理 器。
15. 如权利要求13所述的OAuth授权服务器，还包括： 配置为，响应于接收到第一元数据集合，存储第一范围、由第一资源服务器存储的第一 资源子集和映射到该第一范围的令牌的持有者被允许相对于第一资源子集中的资源执行 的第一操作集合之间的映射的一个或多个硬件处理器。
16. 如权利要求13所述的OAuth授权服务器，其中一个或多个硬件处理器配置为至少 部分通过调用由不提供OAuth授权服务器的消费者提供的编程代码来确认第一访问令牌； 其中该编程代码实现由OAuth授权服务器的提供者提供给消费者的接口；其中该编程代码 配置为确认第一访问令牌。
17. 如权利要求13所述的OAuth授权服务器，还包括： 配置为在OAuth授权服务器处接收规定第一范围的特定请求的一个或多个硬件处理 器； 配置为，响应于接收到规定该第一范围的请求，请求包含在第一范围中的资源的所有 者同意准许与第一范围一致的客户端应用访问的一个或多个硬件处理器； 配置为，响应于从所有者接收到同意，调用由不提供OAuth授权服务器的消费者提供 的编程代码的一个或多个硬件处理器；其中该编程代码实现由OAuth授权服务器的提供者 提供给消费者的接口；其中该编程代码配置为创建第一访问令牌。
18. 如权利要求13所述的OAuth授权服务器，还包括： 配置为，从与第一资源服务器分开的第二资源服务器接收指示由第二资源服务器识别 的第二范围集合的第二元数据集合的一个或多个硬件处理器，该第二范围集合与第一范围 集合不同； 配置为，响应于接收到第二元数据集合，存储第二范围集合中的范围和由第二资源服 务器维护的资源子集之间的映射的一个或多个硬件处理器； 配置为存储第二访问令牌和来自第二范围集合的第二范围之间的映射的一个或多个 硬件处理器； 配置为从第二资源服务器接收确认第二访问令牌的请求的一个或多个硬件处理器； 配置为，响应于接收到确认第二访问令牌的请求，基于第二访问令牌和第二范围之间 的映射确认第二访问令牌的一个或多个硬件处理器；及 配置为，响应于确认第二访问令牌，向第二资源服务器指示向第二资源服务器呈交第 二访问令牌的客户端应用被授权相对于由第二资源服务器维护并由第二范围规定的资源 集合执行操作的一个或多个硬件处理器。
【文档编号】G06F7/04GK104255007SQ201280058348
【公开日】2014年12月31日 申请日期:2012年9月28日 优先权日:2011年9月29日
【发明者】V·U·斯瑞尼瓦森, R·安加尔, A·桑德海, S·彼哈特 申请人:甲骨文国际公司