从0开始构建一个Oauth2Server服务 16 #
授权范围 Scope #
范围是一种限制应用程序访问用户数据的方法。与其授予对用户帐户的完全访问权限，不如让应用程序能够代表用户请求更有限范围内允许它们执行的操作，这通常很有用。
有些应用仅使用 OAuth 来识别用户，因此它们只需要访问用户 ID 和基本配置文件信息。其他应用程序可能需要了解更敏感的信息，例如用户的生日，或者它们可能需要能够代表用户发布内容或修改个人资料数据。如果用户确切知道应用程序可以用他们的帐户做什么和不能做什么，他们将更愿意授权应用程序。范围是一种控制访问并帮助用户识别他们授予应用程序的权限的方法。
请务必记住，作用域与 API 的内部权限系统不同。范围是一种限制应用程序在用户可以做的事情的上下文中可以做的事情的方法。例如，如果您在“customer”组中有一个用户，并且应用程序正在请求“admin”范围，则 OAuth 服务器不会创建具有“admin”范围的访问令牌，因为不允许该用户自己使用该范围。
范围应被视为应用程序向使用该应用程序的用户请求许可。
定义范围 #
作用域是一种让应用程序请求对用户数据进行有限访问的机制。
为您的服务定义范围时的挑战是不要因定义太多范围而忘乎所以。用户需要能够理解他们授予应用程序的访问级别，这将以某种列表的形式呈现给用户。当呈现给用户时，他们需要真正了解正在发生的事情，而不是被信息淹没。如果您为用户过于复杂化，他们只会单击“确定”直到应用程序运行，并忽略任何警告。
读与写 #
在定义服务范围时，读取与写入访问是一个很好的起点。通常，对用户的私人配置文件信息的读取访问权限是通过与想要更新配置文件信息的应用程序分开的访问控制来处理的。
需要能够代表用户创建内容的应用程序（例如，将推文发布到用户时间轴的第三方 Twitter 应用程序）需要与仅需要读取用户公共数据的应用程序不同级别的访问权限。
限制对敏感信息的访问 #
通常，一项服务将具有用户帐户的各个方面，这些方面具有不同的安全级别。例如， GitHub有一个单独的范围，允许应用程序访问私有存储库。默认情况下，应用程序无权访问私人存储库，除非他们要求该范围，因此用户可以放心地知道只有他们选择的应用程序才能访问属于他们组织的私人存储库。
GitHub 提供了一个单独的范围，允许应用程序删除 repos，因此用户可以放心，随机的应用程序无法绕过删除他们的 repos。
Dropbox为应用程序提供了一种限制自身只能编辑单个文件夹中文件的方法。这提供了一种方式，用户可以试用使用 Dropbox 作为存储或同步机制的应用程序，而不必担心该应用程序可能有能力读取他们的所有文件。
按功能有选择地启用访问 #
范围的一个重要用途是根据所需的功能有选择地启用对用户帐户的访问。例如，Google 为其各种服务（如 Google Drive、Gmail、YouTube 等）提供了一组范围。这意味着需要访问 YouTube API 的应用程序不一定也能够访问用户的 Gmail 帐户。
Google 的 API 是有效使用范围的一个很好的例子。有关 Google OAuth API 支持范围的完整列表，请访问他们的 OAuth 2.0 游乐场，网址为https://developers.google.com/oauthplayground/
限制对计费资源的访问 #
如果您的服务提供的 API 可能会导致用户产生费用，则范围是防止应用程序滥用此功能的好方法。
让我们使用一个服务示例，该服务提供使用许可内容的高级功能，在本例中，该服务提供一个 API 来聚合给定区域的人口统计数据。用户在使用服务时收取费用，费用根据查询区域的大小而定。登录到使用 API 的完全不同部分的应用程序的用户希望确保此应用程序无法使用人口统计 API，因为这会导致该用户产生费用。在这种情况下，服务应该定义一个特殊的范围，比如“人口统计”。人口统计 API 应仅响应来自包含此范围的令牌的 API 请求。
在此示例中，人口统计 API 可以使用 令牌自省端点来查找对此令牌有效的范围列表。如果响应在范围列表中不包含“人口统计”，端点将拒绝使用 HTTP 403 响应的请求。
用户界面 #
用户在授权应用程序时看到的界面需要清楚地显示应用程序正在请求的范围列表。用户可能不知道服务提供的所有范围的可能性，因此最好使此文本尽可能清晰明了，避免使用行话和缩写。
如果请求授予应用程序对用户帐户的完全访问权限，或访问其帐户的大部分内容（例如能够执行除更改密码之外的所有操作），则服务应非常清楚地说明这一点。
例如，Dropbox 授权 UI 上的第一句话是“Example OAuth App would like access to the files and folders in your Dropbox”和“Learn More”链接，链接到一个帮助页面，准确描述了应用程序将拥有的访问权限。
Flickr 授权界面显示了用户在我登录时授予应用程序的三件事，并清楚地显示了应用程序不会拥有的权限。显示这一点的好处是用户可以放心，他们授权的应用程序将无法执行潜在的破坏性操作。
GitHub 在提供有关用户授予的范围的详细信息方面做得很好。每个请求的范围在页面上都有一个部分，其中包含名称、图标、突出显示这是只读还是读写的简短描述，以及用于查看更详细说明的下拉列表。
Google 为其所有服务（包括 Gmail API、Google Drive、Youtube 等）提供单一授权端点。他们的授权界面在列表中显示每个范围，并包含一个“信息”图标，您可以单击该图标以获取有关特定范围的更多信息范围。
单击信息图标会显示一个叠加层，详细描述此范围允许的内容。
您可以看到，您可以通过多种方式向用户提供有关 OAuth 授权范围的信息，并且各种服务采用了截然不同的方法。在决定范围的详细程度时，一定要考虑应用程序的隐私和安全要求。
Checkboxes #
虽然看似未被充分利用的功能，但 OAuth 2.0 规范明确允许授权服务器授予范围小于应用程序请求的访问令牌。这为一些有趣的可能性留下了空间。
在 OAuth 2.0 规范开始制定之前，OAuth 1 已部署在 Twitter，Twitter 应用生态系统正在快速发展。在创建 Twitter 应用程序时，您可以选择您的应用程序是需要读+写访问权限还是只需要读取用户帐户的访问权限。这是一种导致 OAuth 2.0 范围概念发展的机制。然而，这种实现相当有限，因为应用程序要么请求写入访问权限，要么不请求写入访问权限，如果用户不想授予应用程序写入访问权限，则用户可能会简单地拒绝该请求。
很快就开发了一种常见的 Twitter 应用程序反模式，该模式仅使用写入权限来发布推文来宣传该应用程序。其中一个更臭名昭著的事件发生在 2010 年，当时声称“根据你的推特活动计算你的推特效率”的应用程序“Twifficiency”逐渐失控。您可以使用您的 Twitter 帐户登录该应用程序，它会抓取您过去的推文并进行分析。然而，它也自动发推文说“我的 Twifficiency 分数是 __%。你的是啥呢？” 带有网站链接。许多人甚至不知道该应用程序正在执行此操作，或者他们已授予该应用程序发布到他们帐户的权限。这导致该应用程序走红，因为使用该应用程序的任何人的关注者都会在他们的时间轴中看到它。