OAuth 2.0 简介

<ph type="x-smartling-placeholder"></ph> 您正在查看 Apigee Edge 文档。
转到 Apigee X 文档。 信息

OAuth 首页：请参阅 OAuth 首页，全面了解我们提供的 OAuth 指南。

本主题简要介绍 Apigee Edge 上的 OAuth 2.0。

什么是 OAuth 2.0？

诸多图书、博客和网站专门介绍了 OAuth 2.0。我们强烈建议您先查看 IETF OAuth 2.0 规范。以下是 OAuth 2.0 IETF 规范中给出的 OAuth 2.0 定义：

“OAuth 2.0 授权框架可以通过代表资源所有者编排资源所有者和 HTTP 服务之间的审批交互，或者允许第三方应用程序代表自己获取访问权限，从而让第三方应用获取对 HTTP 服务的有限访问权限。”

您需要了解的一点是，OAuth 2.0 为应用提供了一种获取用户受保护资源（如银行账户或其他用户可能希望通过应用访问的敏感信息）有限访问权限的方法，而无需用户将其登录凭据透露给应用。

OAuth 2.0 流程

以下是 OAuth 2.0 安全框架的一般流程。我们将以下图作为切入点开始在本主题中详细介绍此流程，图表就 OAuth 2.0 的工作原理展示了诸多内容。如果您不熟悉图表中使用的术语，请阅读本部分，快速了解相关术语。

您需要了解的术语

  • 客户端：也称为“应用”。它可以是移动设备或传统 Web 应用上运行的应用。该应用代表资源所有者向资源服务器请求访问受保护的资产。资源所有者必须向应用授予访问受保护资源的权限。
  • 资源所有者：也称为“最终用户”。通常是指能够授权访问受保护资源的人员（或其他实体）。例如，如果应用需要使用属于您的某个社交媒体网站中的数据，那么您就是资源所有者（唯一一位可以授权该应用访问您的数据的人）。
  • 资源服务器：将资源服务器视为 Facebook、Google 或 Twitter 等服务；或内网上的 HR 服务；或 B2B 外网上的合作伙伴服务。每当需要 OAuth 令牌验证来处理 API 请求时，Apigee Edge 便可充当资源服务器。资源服务器需要某种类型的授权才能为应用提供受保护的资源。
  • 授权服务器：授权服务器应按照 OAuth 2.0 规范实现，而且要负责验证授权许可并发出能让应用访问资源服务器上的用户数据的访问令牌。您可以在 Apigee Edge 上配置“令牌端点”，在这种情况下 Edge 会担任授权服务器这一角色。
  • 授权许可：授予应用代表最终用户检索访问令牌的权限。OAuth 2.0 定义了四种明确的“授权类型”。请参阅下面的“什么是 OAuth 2.0 授权类型”。
  • 访问令牌：一条长字符串，用作访问受保护资源的凭据。请参阅下面的“什么是访问令牌？”。
  • 受保护的资源：资源所有者拥有的数据。例如用户的联系人列表、账号信息或其他敏感数据。

Apigee Edge 适用的位置

您可以使用 OAuth 2.0 保护通过 Apigee Edge 的任何 API 代理。Edge 包括授权服务器实现，因此可以生成和验证访问令牌。开发者首先应使用 Apigee Edge 注册其应用。已注册的应用可以通过四种授权类型交互中的任意一种来请求访问令牌。

Apigee 提供一种多方 OAuthV2 政策，该政策可以实现每种授权类型的详情，从而让在 Apigee Edge 上设置 OAuth 变得相对比较简单。例如，您可以配置一项策略来接收访问令牌请求、评估所有必需的凭据，并在凭据有效时返回访问令牌。

请注意，安全 API 代理调用的所有资源服务器都应受防火墙保护（即，无法通过 API 代理或经过妥善保护的其他 API 之外的任何方式访问这些资源）。

什么是 OAuth 2.0 授权类型？

将授权类型视为应用获取访问令牌所采用的不同路径或交互。每种授权类型都涉及一个或多个用例，您需要根据自己的需求选择要使用的授权类型。一般来说，每种授权类型都各有利弊，您需要根据您的业务用例进行权衡。其中一个重要的考虑因素是即将访问您的数据的应用的“可信度”。通常，第三方应用的可信度不如在企业中开发和使用的应用。

Apigee Edge 支持四种主要的 OAuth 2.0 授权类型：

  • 授权代码 -- 被认为是最安全的授权类型。在授权服务器发出访问令牌之前，应用必须先从资源服务器接收授权代码。每次您的应用打开浏览器访问资源服务器的登录页面，并邀请您登录实际账号（例如 Facebook 或 Twitter）时，您都看到了此流程。

如果您成功登录，该应用将会收到一个可用来与授权服务器协商访问令牌的授权代码。通常，如果应用位于服务器上而不是客户端上，则使用此授权类型。这种授权类型被认为高度安全，因为客户端应用永远不会处理或看到资源服务器的用户名或密码（具体来说，例如应用始终不会看到或处理 Twitter 凭据）。这种授权类型流程也称为“三足式”OAuth。

  • 隐式 -- 被认为是简化版授权代码。通常，如果应用位于客户端上，则使用此授权类型。例如，应用的代码使用 JavaScript 或其他脚本语言在浏览器中实现（而不是在单独的网络服务器上驻留和运行）。在这种授权类型流程中，授权服务器会在用户通过身份验证时直接返回访问令牌，而不是先发出授权代码。在某些情况下，隐式授权可以提升应用响应速度，但需要权衡这一优点和 IETF 规范中所述的潜在安全隐患。
  • 资源所有者密码凭据 -- 在此流程中，当用户的用户名/密码通过授权服务器验证时，客户端会获得访问令牌。建议对非常值得信赖的应用采用此流程。此流程有一个优点，即基本身份验证，这是指用户只需提供一次用户名/密码。之后便使用访问令牌。
  • 客户端凭据 -- 在客户端应用以自己的名义进行操作的情形中可以考虑这一类型。也就是说，客户端也是资源所有者。例如，当应用需要访问后端数据存储服务时，通常会使用此授权类型。应用需要使用该服务来完成其工作，而该服务对最终用户来说是不透明的。有了这种授权类型，应用可以通过向授权服务器提供客户端 ID 和客户端密钥来接收访问令牌。无需进一步操作。Edge 提供开箱即用且易于为任何 API 代理实现的客户端凭据解决方案。

什么是访问令牌？

访问令牌是一条长字符串，可用作访问受保护资源的凭据。资源令牌（也称为不记名令牌）在 Authorization 标头中传递，如下所示：

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

资源服务器了解访问令牌“代表”用户名和密码等凭据。此外，可以对发出的访问令牌设限，例如，使应用程序可以读取但不能写入或删除资源服务器上的数据。请注意，举例来说，如果应用被破解，访问令牌会被撤消。在这种情况下，您需要获取新的访问令牌，以便继续使用应用；但是，您不必在受保护的资源服务器（例如 Facebook 或 Twitter）上更改用户名或密码。

访问令牌通常设有有效期（出于安全原因）。某些授权类型允许授权服务器发出刷新令牌，这允许应用在旧令牌到期时获取新的访问令牌。如需详细了解访问令牌和刷新令牌，请参阅 IETF OAuth 2.0 规范。

通过范围限制访问权限

通过范围机制，OAuth 2.0 可以向应用授予受保护资源的有限访问权限。例如，应用可能只拥有访问特定资源的权限、可能可以更新资源，或者只被授予只读权限。在所谓的“三足式”OAuth 流程下，用户通常通过同意页面（例如，用户使用其他机制的复选框选择范围的网页）指定访问权限级别。

注册应用

所有客户端（应用）都必须注册准备向其请求访问令牌的 OAuth 2.0 授权服务器。注册应用时，您会收到一组密钥。一个是称为客户端标识符的公钥，另一个是称为客户端密钥的密钥。如果没有这些密钥，应用将无法向授权服务器请求授权代码或访问令牌。请注意，尽管 IETF OAuth 规范称这些密钥为客户端 ID 和客户端密钥，但 Apigee Edge 界面称其为使用方 ID 和使用方密钥。它们没有区别。

OAuth 2.0 用例摘要

您选择实现的 OAuth 2.0 授权类型流程取决于您的具体使用场景，因为在某些情况下，某些授权类型更安全。您对于授权类型的选择取决于客户端应用的可信度，并且需要谨慎考察，如下表所述：

使用场景 可信度 建议的 OAuth 2.0 授权许可类型 说明
B2B（外网）、内网、其他

高度可信的应用，由内部开发者或与 API 提供商建有受信任业务关系的开发者编写。

需要代表自身访问资源的应用。
  • 客户端凭据
  • 通常，应用也是资源所有者
  • 需要客户端 ID 和客户端密钥
  • 需要在服务提供商处注册应用
内网网站、门户

可信应用，由内部或受信任的第三方开发者编写。

一个良好的示例便是登录贵公司的 HR 网站来选择保险、提交评价或更改个人信息。
  • 密码
  • 隐式
  • 需要客户端 ID 和密钥，以及用户名和密码
  • 需要在服务提供商处注册应用
公开可用的应用 不受信任的应用，由未与 API 提供商建有受信任业务关系的第三方开发者编写。例如，注册公共 API 项目的开发者通常不应受信任。
  • 授权代码
  • 要求用户登录第三方资源提供商（例如，Twitter、Facebook）
  • 应用绝不会看到用户的用户名和密码
  • 需要在服务提供商处注册应用
B2C 涉及个人最终用户（移动用户），并且用户凭据存储在移动设备上。
  • 隐式
  • 需要在服务提供商处注册应用。
  • 用户凭据存储在运行应用的设备上。

OAuth 2.0 与 API 密钥的安全性

API 密钥验证要求应用将密钥发送到 Edge。密钥必须是来自与 API 代理相关的 Apigee Edge 开发者应用的有效使用方密钥。如果由于某种原因，您需要撤消客户端应用调用代理的权限，则必须撤消该使用方密钥。任何使用该密钥的客户端应用也将无法访问 API 代理。另一方面，您可以随时撤消 OAuth 令牌，而无需撤消应用的密钥。应用只能代表用户请求新令牌，如果授予令牌，则应用可以继续使用 API 代理。

API 密钥和令牌之间的另一个区别是，令牌可以包含您可以检索并稍后使用的元数据属性。例如，您可以存储发出 API 调用的用户的 ID，并使用它自定义对后端目标服务的调用。

如需详细了解 API 密钥验证，请参阅 API 密钥。如需了解如何将自定义属性与 OAuth 令牌搭配使用，请参阅自定义令牌和授权代码。

推荐资源

阅读

请参阅了解 OAuth 2.0。