在 HTTP 协议中，内容协商是一种机制，用于为同一 URI 提供资源不同的表示形式，以帮助用户代理指定最适合用户的表示形式（例如，哪种文档语言、哪种图片格式或者哪种内容编码）。 备注： 你可以在来自 WHATWG 的维基页面发现 HTTP 内容协商的一些缺点。HTML5 提供其他的选择来进行内容协商。
HTTP（HyperText Transfer Protocol）是万维网（World Wide Web）的基础协议。自 Tim Berners-Lee 博士和他的团队在 1989-1991 年间创造出它以来，HTTP 已经发生了太多的变化，在保持协议简单性的同时，不断扩展其灵活性。如今，HTTP 已经从一个只在实验室之间交换文件的早期协议进化到了可以传输图片，高分辨率视频和 3D 效果的现代复杂
OAuth 2.0“设备流”扩展在具有 Internet 连接但没有浏览器或没有简单的文本输入方法的设备上启用 OAuth。如果您曾在 Apple TV 等设备上登录过 YouTube 帐户，那么您已经遇到过此工作流程。Google 参与了此扩展的开发，并且也是生产中的早期实施者。
为本机应用程序支持 OAuth 时要牢记的一些特殊注意事项。与基于浏览器的应用程序一样，本机应用程序不能使用客户端机密，因为这将要求开发人员在应用程序的二进制分发中传送机密。事实证明，反编译和提取秘密相对容易。因此，本机应用程序必须使用不需要预注册客户端密码的 OAuth 流程。
资源服务器是 API 服务器的 OAuth 2.0 术语。资源服务器在应用程序获得访问令牌后处理经过身份验证的请求。 大规模部署可能有多个资源服务器。例如，谷歌的服务有几十个资源服务器，如谷歌云平台、谷歌地图、谷歌云端硬盘、Youtube、谷歌+等。这些资源服务器中的每一个都是明显独立的，但它们都共享同一个授权服务器。
OAuth 2.0 规范中没有任何内容要求用户能够撤销访问权限，甚至没有建议如何执行此操作，因此我们将查看几个主要的 API 提供商以获取有关如何完成此操作的灵感。
通常，刷新令牌仅用于机密客户端。但是，由于可以在没有客户端密码的情况下使用授权代码流，因此没有密码的客户端也可以使用刷新授权。如果向客户端发出了一个秘密，则客户端必须对该请求进行身份验证。通常，该服务将允许附加请求参数client_id和client_secret，或者接受 HTTP 基本身份验证标头中的客户端 ID 和密码。如果客户端没有密码，则此请求中不会出现客户端身份验证。
当您的服务发出访问令牌时，您需要就您希望令牌持续多长时间做出一些决定。不幸的是，没有针对每项服务的一揽子解决方案。不同的选项会带来各种权衡，因此您应该选择最适合您的应用程序需求的选项（或选项组合）
令牌提供了一种通过在令牌字符串本身中编码所有必要信息来避免将令牌存储在数据库中的方法。这样做的主要好处是 API 服务器能够验证访问令牌，而无需对每个 API 请求进行数据库查找，从而使 API 更容易扩展。 OAuth 2.0 Bearer Tokens 的好处是应用程序不需要知道您决定如何在您的服务中实现访问令牌。这意味着以后可以在不影响客户端的情况下更改您的实现。
访问令牌是应用程序用来代表用户发出 API 请求的东西。访问令牌代表特定应用程序访问用户数据的特定部分的授权。 访问令牌不必是任何特定格式，尽管对不同的选项有不同的考虑，这将在本章后面讨论。就客户端应用程序而言，访问令牌是一个不透明的字符串，它会接受任何字符串并在 HTTP 请求中使用它。资源服务器需要了解访问令牌的含义以及如何验证它，但应用程序永远不会关心理解访问令牌的含义。
重定向 URL 是 OAuth 流程的关键部分。用户授权应用成功后，授权服务器会将用户重定向回应用。由于重定向 URL 将包含敏感信息，因此服务不会将用户重定向到任意位置至关重要。
范围是一种限制应用程序访问用户数据的方法。与其授予对用户帐户的完全访问权限，不如让应用程序能够代表用户请求更有限范围内允许它们执行的操作，这通常很有用。
针对 OAuth 服务器的一种潜在Attack是网络钓鱼Attack。这是Attack者创建一个看起来与服务授权页面相同的网页的地方，该页面通常包含用户名和密码字段。然后，Accacker可以通过各种手段诱骗用户访问该页面。除非用户可以检查浏览器的地址栏，否则该页面可能看起来与真正的授权页面完全相同，并且用户可以输入他们的用户名和密码。
授权码必须在发出后不久过期。OAuth 2.0 规范建议最长生命周期为 10 分钟，但实际上，大多数服务将到期时间设置得更短，大约 30-60 秒。授权代码本身可以是任意长度，但应该记录代码的长度。 因为授权代码是短期的和一次性使用的，所以您可以将它们实现为自编码令牌。使用这种技术，您可以避免将授权代码存储在数据库中，而是将所有必要的信息编码到授权代码本身中。您可以使用服务器端环境的内置加密库，也可以使用 JSON Web 签名 (JWS) 等标准。但是，由于此授权代码仅供授权服务器使用，因此通常可以更简单地将它们实现为存储在授权端点和令牌端点可访问的服务器端缓存中的短字符串。
通常像 Twitter 或 Facebook 这样的网站希望他们的用户在大部分时间都登录，因此他们为他们的授权屏幕提供了一种方式，通过不要求他们每次都登录来为用户提供简化的体验。但是，根据您的服务以及第三方应用程序的安全要求，可能需要要求或允许开发人员选择要求用户在每次访问授权屏幕时都登录。
开发人员将需要一种方法来删除（或至少停用）他们的应用程序。为开发人员提供一种方法来为他们的应用程序撤销和生成新的客户端密码也是一个好主意。
当开发人员访问您的网站时，他们将需要一种方法来创建新的应用程序并获取凭据。通常，在他们可以创建应用程序之前，您会让他们创建一个开发者帐户，或代表他们的组织创建一个帐户。 虽然 OAuth 2.0 规范不要求您在授予凭据之前收集任何应用程序信息，但大多数服务会在发布client_id和client_secret. 但是，出于安全目的，您需要开发人员为应用程序注册一个或多个重定向 URL，这一点很重要。这在重定向 URL中有更详细的解释。
Authorization访问令牌在以文本为前缀的HTTP 标头中发送到服务Bearer。从历史上看，某些服务允许在 post 正文参数甚至 GET 查询字符串中发送令牌，但这些方法也有缺点，大多数现代实现将仅使用 HTTP 标头方法。
与单页应用程序一样，移动应用程序也无法维护客户机密。因此，移动应用程序还必须使用不需要客户端密码的 OAuth 流程。当前的最佳做法是将授权流程与 PKCE 一起使用，同时启动外部浏览器，以确保本机应用程序无法修改浏览器窗口或检查内容。
单页应用程序（也称为基于浏览器的应用程序）在从网页加载 JavaScript 和 HTML 源代码后完全在浏览器中运行。由于浏览器可以使用整个源代码，因此它们无法维护客户端机密的机密性，因此这些应用程序不使用机密。因为他们不能使用客户端密码，所以最好的选择是使用 PKCE 扩展来保护重定向中的授权代码。这类似于也不能使用客户端密码的移动应用程序的解决方案。
高级概述是这样的： - 使用应用程序的客户端 ID、重定向 URL、状态和 PKCE 代码查询参数创建登录链接 - 用户看到授权提示并批准请求 - 使用授权码将用户重定向回应用程序的服务器 - 该应用程序交换访问令牌的授权代码
服务器端应用程序是处理 OAuth 服务器时遇到的最常见的应用程序类型。这些应用程序在 Web 服务器上运行，其中应用程序的源代码不向公众开放，因此它们可以维护其客户端机密的机密性。 下图说明了一个典型示例，其中用户与正在与客户端通信的浏览器进行交互。客户端和 API 服务器之间有一个单独的安全通信通道。用户的浏览器从不直接向 API 服务器发出请求，一切都先通过客户端。
本节中我们将介绍如何在现有的 OAuth 2.0 服务器上访问您的数据。对于此示例，我们将使用 GitHub API 并构建一个简单的应用程序，该应用程序将列出登录用户的授权信息。本文中的代码实现是golang。
我们将介绍在构建与现有 OAuth 2.0 API 对话的应用程序时需要了解的事项。无论您是构建 Web 应用程序还是移动应用程序，在我们开始时都需要牢记一些事项。 每个 OAuth 2.0 服务都需要您首先注册一个新应用程序，这通常还需要您首先注册为该服务的开发人员。
JWT 的好处是能够在其中携带信息。有了可用于您的应用程序的此信息，您可以轻松强制执行令牌过期并减少 API 调用次数。此外，由于它们经过加密，您可以验证它们是否未被篡改。
您从 OIDC 流返回的令牌和端点的内容/userinfo是请求的流类型和范围的函数。scope在这里，您可以为和设置不同的开关response_type，这决定了您应用程序的流类型。 您的用例将决定使用哪个流程。您是否正在构建需要直接与 OpenID 提供商 (OP) 交互的 SPA 或移动应用程序？您是否有将与 OP 交互的中间件，例如 Spring Boot 或 Node.js Express？下面，我们将深入探讨一些可用的流程以及何时适合使用它们。
OAuth 2.0 将很多细节留给了实施者。例如，它支持范围，但未指定范围名称。它支持访问令牌，但未指定这些令牌的格式。使用 OIDC，定义了许多特定的范围名称，每个名称都会产生不同的结果。OIDC 同时具有访问令牌和 ID 令牌。ID 令牌必须是 JSON Web 令牌 (JWT)。由于规范规定了令牌格式，因此可以更轻松地跨实现使用令牌。
您最近可能听说过一些关于 OAuth 2.0 隐式流程的讨论。OAuth 工作组发布了一些关于隐式流程和基于 JavaScript 的应用程序的新指南，特别指出不应再使用隐式流程。在本文中，我们将了解隐式流程发生了什么变化以及原因。
隐式授权类型是单页 JavaScript 应用程序无需中间代码交换步骤即可获取访问令牌的一种方式。它最初是为 JavaScript 应用程序（无法安全存储机密）而创建的，但仅在特定情况下才推荐使用。
OAuth 2.0 密码授权类型是一种在给定用户名和密码的情况下获取访问令牌的方法。它通常仅由服务自己的移动应用程序使用，通常不提供给第三方开发人员。 这篇文章是我们探索常用的 OAuth 2.0 授权类型系列文章的第三篇。之前我们介绍了授权代码和隐式授权类型。如果您想在我们开始之前稍微回顾一下并了解有关 OAuth 2.0 的更多信息，请查看OAuth 到底是什么？.
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
