认识 OAuth 2.0

理解 OAuth 2.0

阮一峰的这篇文章以通俗的语言介绍了 OAuth 2.0，而这篇文章更全面的介绍了 OAuth 2.0，我们来看看他是怎么说的。

OAuth 2.0 是一种授权协议，而不是身份验证协议。因此，它的主要设计用途是授予对一组资源（例如远程 API 或用户数据）的访问权限。

角色是 OAuth 2.0 授权框架核心规范的一部分。它定义了 OAuth 2.0 系统的基本组成部分，具体如下：

在 OAuth 2.0 中，**作用域（Scope）**是一个重要的概念。它用于精确指定授予资源访问权限的原因。可接受的作用域值及其关联的资源取决于资源服务器。

在使用 OAuth 2.0 之前，客户端必须从授权服务器获取自己的凭据（客户端 ID 和客户端密钥 ），以便在请求访问令牌时进行身份识别和身份验证。

• 客户端向授权服务器请求授权（authorization request），提供客户端 ID 和密钥作为标识；它还提供范围和端点 URI（endpoint URI / redirect URI），以便将访问令牌或授权码发送到该 URI。
• 授权服务器对客户端进行身份验证，并验证所请求的范围是否被允许。
• 资源所有者与授权服务器交互以授予访问权限。
• 授权服务器会根据授权类型将授权码或访问令牌重定向回客户端。此外，也可能返回刷新令牌。
• 客户端通过访问令牌向资源服务器请求访问资源。

OAuth 2.0 的授权类型

• **授权码（Authorization Code）**授权：授权服务器向客户端返回一个一次性使用的授权码，客户端随后用该授权码交换访问令牌。对于传统的 Web 应用来说，这是最佳选择，因为交换可以在服务器端安全地进行。单页应用 (SPA) 和移动/原生应用也可以使用授权码流程。但是，在这种情况下，客户端密钥无法安全存储，因此在交换过程中，身份验证仅限于使用客户端 ID 。更好的替代方案是下文所述的基于 PKCE 授权的授权码 。
• **隐式（Implicit）**授权：一种简化的流程，其中访问令牌直接返回给客户端。在隐式授权流程中，授权服务器可以将访问令牌作为回调 URI 中的参数返回，或者作为表单提交的响应返回。由于存在令牌泄露的风险，第一种方法（作为 URI 的参数）现已弃用。
• **使用密钥验证进行代码交换的授权码 （PKCE，Authorization Code Grant with Proof Key for Code Exchange）**授权 ：此授权流程与授权码授权类似，但增加了额外的步骤，使其对移动/原生应用程序和 SPA 更安全。
• **资源所有者凭证（Resource Owner Credentials）**授权：此授权类型要求客户端首先获取资源所有者的凭证，并将这些凭证传递给授权服务器。因此，它仅限于完全可信的客户端。其优势在于无需重定向到授权服务器，因此适用于无法进行重定向的场景。
• **客户端凭证（Client Credentials）**授权 ：用于非交互式应用程序，例如自动化流程、微服务等。在这种情况下，应用程序本身通过使用其客户端 ID 和密钥进行身份验证。
• 设备授权流程（Device Authorization Flow） ：允许应用程序在输入受限的设备（例如智能电视）上使用的一种授权。
• **刷新令牌（Refresh Token）**授权 ：涉及将刷新令牌交换为新的访问令牌（Access Token）的流程。

关于授权类型更多解释，可以参考《OAuth 2.0 的四种方式》（虽然不是很全）

如非特别说明，本专题后续章节将使用 OAuth 代替 OAuth 2.0