正确的工作流程：我应该使用哪个OAuth 2.0流程？

什么是OAuth 2.0

OAuth 2.0是一个已被广泛采用的委托授权框架，已经存在了很多年，并且似乎已经存在。如果您不熟悉OAuth 2.0的基本概念，可以使用
川崎孝彦写的优秀文章。这只是OAuth 2.0各方的简要提醒：

资源所有者–受保护资源的所有者，例如用户
客户端–想要访问受保护资源的应用程序，例如服务器端Web应用程序或单页应用程序（SPA）
授权服务器–发行令牌的服务器
资源服务器–管理资源所有者的受保护数据的服务器

让我们浏览每个OAuth 2.0流程并讨论其用法。

客户证书授予

这是最简单的流程。它允许客户端使用其客户端ID和客户端密钥请求访问令牌。两者都安全地保存在客户端并在授权服务器中注册。

第一步，客户端将HTTP请求发送到授权服务器，包括其客户端ID和客户端密钥（例如，在Authorization标头中）。该请求也可以包括所请求的范围。
在响应中，授权服务器发送访问令牌。
客户端使用访问令牌来调用资源服务器。

什么时候使用？

如您所见，没有用户参与。建议使用“客户端凭据授予”来进行计算机到计算机的授权。通常，一个受信任的服务将调用另一个服务。

授权码授予

最常用的流程，专门为可以维护其客户端机密性的服务器端应用程序而设计。这是基于重定向的流之一。

客户端通过将资源所有者的用户代理重定向到授权服务器来启动流程。客户端包括其客户端ID，请求的范围和重定向URI。
资源所有者通过授予客户端请求的权限来授权客户端。
授权服务器将用户代理重定向回客户端（使用来自点1的重定向URI）。重定向URI包含一个临时授权码（作为查询参数）。
客户端从授权服务器请求访问令牌。该请求包括在上一步中收到的客户端ID，客户端密码和授权代码。
如果所有内容均有效，则授权服务器将返回访问令牌，并可选地返回刷新令牌。
客户端使用访问令牌代表资源所有者调用资源服务器。

为什么我们需要其他授权码？

为什么我们不能直接请求访问令牌？为什么首先要引入授权码？事实证明，主要目标是分离公开给客户和用户代理的信息。请注意，访问令牌根本不会通过浏览器。从客户端（服务器端应用程序）使用

通过用户代理转发的授权码。浏览器有什么问题？ OAuth 2.0不需要客户端服务器支持HTTPS。因此，从技术上讲，可能存在无法通过SSL重定向到客户端服务器的问题。如果发生这种情况，则通过明文发送授权码。如果有人拦截了它，那么没有Client Secret还是没有用。但是，如果您直接通过HTTP发送访问令牌，则可能会遭到破坏。

什么时候使用？

如前所述，建议对服务器端Web应用程序使用此流程。但是，近年来，这种流程的变体也已用于单页和移动应用程序。

单页应用

对于单页应用程序，唯一的区别是客户端（SPA）没有客户端密钥。由于SPA在浏览器中运行，并且其源代码是公开的，因此无法在浏览器端对客户端机密保密。这就是在上图的第4步中，将授权代码交换为访问令牌而不发送客户端密钥的原因。

原生移动应用

与SPA类似，本机移动应用程序被认为是公共的，而不是机密的客户端。这就是客户端机密不应该存储在移动设备中（因此在请求访问令牌时不发送的原因）。没有在移动设备中实现没有客户端密钥的授权代码流，可能会存在一些安全问题。这样的问题之一是，授权码可能会被攻击者拦截并交换为访问令牌。为了减轻这种风险，有一种称为代码交换证明密钥（PKCE）的技术。对于每个授权请求，客户端都必须创建一个称为Code Verifier的随机密钥。授权代码请求中包含其称为Code Challenge的哈希版本。授权服务器应将此代码质询与其生成的授权代码相关联。稍后，当为访问令牌交换授权码时，客户端会将代码验证程序作为查询参数。除了验证标准参数外，授权服务器还应使用先前收到的Code Challenge验证Code Verifier。