本文是oauth.com上的教程的翻译。（原文地址）

本章是对OAuth服务提供商的指导。

范围(scope)是一种限制应用访问用户数据的方法。与授予对用户帐户的完全访问权限相比，为应用程序提供一种方式，来限制他们代表用户访问和操作的范围，通常是一种更有效的方式。

某些应用仅使用OAuth来识别用户，因此他们只需要访问用户ID和基本配置文件信息。其他应用可能需要知道更敏感的信息，例如用户的生日，或者他们可能需要能够代表用户发布内容，或修改个人资料数据。如果用户确切知道应用程序可以和不能对他们的帐户做什么，他们将更愿意授权应用程序。范围是一种控制访问权限的方法，可帮助用户识别他们授予应用程序的权限。

定义范围

定义范围的好地方是分别定义读取与写入。这适用于Twitter，因为并非所有应用程序实际上都希望能够将内容发布到您的Twitter帐户，有些只需要访问您的个人资料信息。

定义服务范围时的挑战是不要因定义太多范围而被忽略。用户需要能够理解他们授予的授权范围，并且这将在列表中呈现给用户。当呈现给用户时，他们需要真正了解正在发生的事情。如果您为用户设计的过度复杂，他们可能会单击“确定”直到应用程序正常工作，并忽略任何警告。

读与写

通常，在定义服务范围时，读取和写入访问是一个很好的起点。通常，对想要更新配置文件信息的应用程序，使用单独的访问控制来处理对用户的私有配置文件信息的读访问。

需要能够代表用户创建内容的应用程序（例如，将推文发布到用户的时间线的第三方Twitter应用程序），与仅需要读取用户的公共数据的应用程序相比，需要获得不同级别的访问权限。

限制对敏感信息的访问

通常，对于不同安全级别的用户，服务将具有不同的配置。例如，GitHub有一个单独的范围，允许应用程序访问私有存储库。默认情况下，应用程序无权访问私有存储库，除非他们要求该范围，因此用户可以放心地知道他们选择的应用只能访问属于其组织的私有存储库。

GitHub提供了一个单独的范围，允许应用程序删除repos，因此用户可以放心，随机应用程序无法绕过这个范围删除其存储库。

Dropbox为应用程序提供了一种限制自己只能编辑单个文件夹中文件的方法。这为尝试使用Dropbox作为存储或同步机制的应用程序提供了一种方法，用户无需担心应用程序可能会读取其所有文件。

通过功能选择性地启用访问

范围的一个很好的用途是根据所需的功能选择性地启用对用户帐户的访问。例如，Google为其各种服务提供了一组范围，例如Google云端硬盘，Gmail，YouTube等。这意味着需要访问YouTube API的应用程序也不一定能够访问用户的Gmail帐户。

谷歌的API是有效使用范围的一个很好的例子。有关Google OAuth API支持的范围的完整列表，请访问https://developers.google.com/oauthplayground/上的 OAuth 2.0 Playground。

限制对可结算资源的访问

如果您的服务提供的API可能会导致用户产生费用，那么设定范围是防止滥用此功能的应用程序的好方法。

例如，在提供使用许可内容的高级功能的情况下，提供用于聚合给定区域的人口统计数据的API。用户在使用服务时收取费用，费用取决于要查询的区域的大小。当用户登录使用完全不同的API部分的应用时，用户希望确保此应用无法使用人口统计信息API，因为这会导致该用户产生费用。在这种情况下，服务应定义一个特殊范围，例如“人口统计”。人口统计信息API应仅响应来自包含此范围的令牌的API请求。

在此示例中，人口统计信息API可以使用令牌自解析端点来查找对此令牌有效的范围列表。如果响应在范围列表中不包含“人口统计”，则端点将使用HTTP 403响应拒绝该请求。

用户界面

用户在授权应用程序时看到的界面需要清楚地显示应用程序请求的范围列表。用户可能不知道服务提供的范围的所有可能性，因此最好使该文本尽可能清晰明了，避免使用行话和缩写。

如果请求授予应用程序对用户帐户的完全访问权限，或访问其帐户的大部分内容，例如除了更改密码之外能够执行所有操作，则该服务应该非常清楚。例如，Dropbox授权用户界面上的第一句话是“示例OAuth应用程序希望访问Dropbox中的文件和文件夹”，其中包含“了解更多”链接，该链接指向帮助页面，该帮助页面准确描述了应用程序将具有哪些访问权限。

Flickr授权界面显示用户在登录时授予应用程序的三件事，并清楚地显示应用程序不具有的权限。显示这一点的好处是，用户可以放心，他们授权的应用程序将无法进行潜在的破坏性操作。

GitHub在提供有关用户授予范围的详细信息方面做得非常出色。请求的每个范围都会在页面上显示一个部分，其中包含名称，图标，突出显示是只读还是读写的简短说明，以及下拉列表以查看更详细的说明。

Google为其所有服务提供单一授权终端，包括Gmail API，Google云端硬盘，Youtube等。其授权界面会在列表中显示每个范围，并包含一个“信息”图标，您可以点击该图标以获取有关特定内容的详细信息范围。

单击信息图标会显示一个叠加层，详细描述此范围允许的内容。

您可以看到有多种方法可以为用户提供有关OAuth授权范围的信息，并且各种服务采用了截然不同的方法。在您定义范围时，请务必考虑应用程序的隐私和安全要求。

复选框

虽然这是一个看似未充分利用的功能，但OAuth 2.0规范明确允许授权服务器授予访问令牌的范围小于应用程序的请求。这为一些有趣的可能性留下了空间。

在开始开发OAuth 2.0规范之前，OAuth 1已部署在Twitter上，Twitter应用程序生态系统正在迅速发展。在创建Twitter应用程序时，您可以选择您的应用程序是需要读取+写入权限还是只读取对用户帐户的访问权限。这是一种开发OAuth 2.0范围概念的机制。但是，这种实现是相当有限的，因为应用程序要么不请求写访问权限，要么用户可能只是拒绝该请求，如果他们不想授予应用程序写访问权限。

很快就开发了一种常见的Twitter应用程序的反模式，它只使用写访问权来发布推文给应用程序做广告。其中一个更臭名昭着的事件发生在2010年，当时应用程序“Twifficiency”声称“根据你的推特活动计算你的推特效率”，但这却很快失控。您将使用您的Twitter帐户登录该应用程序，它会抓取您过去的推文并对其进行分析。但是，它也自动发推文“我的Twifficiency得分是__％。你的是多少？”从而链接到第三方网站。许多人甚至不知道应用程序正在执行此操作，或者他们已授予此应用程序权限以发布到其帐户。这导致应用程序变成病毒式传播，因为使用该应用程序的任何人的关注者都会在他们的时间轴中看到它。

许多人对此感到不安，并在Twitter上大声抱怨。当时雅虎的开发人员Ben Ward更进一步，创建了一个可以解决这个问题的潜在用户界面的模型，并写了一篇简短的博客文章解释它。https://benward.uk/blog/tumblr-968515729

在帖子中，Ward描述了一个允许应用程序请求特定权限的用户界面，用户可以选择授予或不授予每个权限。这将允许用户登录应用程序但不允许其首先发布到其帐户。稍后，如果用户确实想要允许该应用发布，则该应用可以提供在Twitter上重新授权用户的机制。几个月后，沃德在Twitter被聘用。

这篇文章引发了一些参与OAuth规范开发的人们之间的讨论，这个讨论现在只存在于archive.org上的Google Buzz主题：http://web.archive.org/web/20100823114908/,http://www.google.com/buzz/tantek/5YHAAmztLcD/t-Look-BenWard-schools-Twitter-on-OAuth。

直到今天，Twitter仍然没有提供这种细粒度的授权。但是，其他服务已经开始实现类似的功能，在授权流程中为用户提供更多控制，而不是使其看起来像“单击确定以继续”对话框。

Facebook推出了最近的更新，为初始页面提供了一个简单的用户界面，允许用户点击编辑应用程序将被授予的范围，如下所示。

如果单击“编辑您提供的信息”，则会转到一个界面，列出应用程序请求的每个范围，您可以根据需要取消选中它们。在下面的屏幕截图中，我选择不允许应用程序查看我的朋友列表。

只有应用程序请求的范围才会出现在此列表中。这为用户提供了更好的体验，因为他们能够保持控制并更好地了解应用程序如何使用其帐户。

FitBit跟踪用户健康的许多方面，例如步数，心率，消耗的食物和饮料，睡眠质量，体重等。FitBit API对第三方应用程序提供对所有这些数据的访问。由于许多第三方应用程序只会读取或写入某些类型的数据，FitBit会提供精细的范围，以便用户只能授予对其配置文件的某些部分的访问权限。

FitBit的授权页面（如下所示）允许用户有选择地授予或拒绝访问应用程序请求的每个特定范围。

GitHub 在2013 年的博客文章中描述了他们计划允许用户编辑范围，但截至2018年，依旧没有后续跟进。

使用户能够选择授予哪些范围是让人们对使用第三方应用感到更舒服的好方法。每个范围旁边加复选框就足够了，或者您可以将控件移动到像Facebook这样的单独屏幕。您需要确保在发送访问令牌响应时，它包括用户所授予的范围列表，而不是应用程序请求的。