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

什么是OAuth 2.0

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

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

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

客户证书授予

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

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

什么时候使用？

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

授权码授予

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

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

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

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

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

什么时候使用？

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

单页应用

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

原生移动应用

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

1. 客户端移动应用打开带有授权请求的浏览器。 授权请求包括客户端ID，请求的范围，重定向URI和代码质询。
2. 授权请求发送到身份验证服务器
3. 资源所有者授权客户。
4. 结果，授权码被返回给用户代理。
   
5. 授权码被传递给客户端。
6. 客户端应用程序将授权代码和代码验证程序以及重定向URI和客户端ID发送到授权服务器。
7. 授权服务器将代码验证程序的哈希值与先前发送的代码质询进行比较。 如果它们匹配，则将授权代码交换为访问令牌（以及可选的刷新令牌）
8. 客户端使用访问令牌代表资源所有者调用资源服务器。
   

另外， 当前的最佳实践是仅使用外部用户代理（而不是嵌入式Web视图）来发送对授权码的请求。

隐性补助金

它类似于“授权代码授予”，但是它完全跳过了“授权代码”步骤。 客户端直接请求访问令牌，而无需授权码。 此外，不涉及“客户机密”。 在隐式授予中，不使用刷新令牌。 重要的是要提到，访问令牌以散列片段的形式在3xx重定向中返回，并且永远不会从浏览器发送。

什么时候使用？

它最初设计为SPA的流程。 它依赖于浏览器，可能无法在其他环境中安全地实现。 但是，如前所述，对于SPA，近年来，越来越多的组织已经朝着没有客户机密而不是隐式流的授权代码流发展。

资源所有者密码凭证授予

在此流程中，资源所有者将其凭据直接提交到客户端应用程序。 客户端应用程序使用该凭据直接将它们交换为访问令牌（以及可选的刷新令牌）。 与客户端凭据类似，它不是基于重定向的流程。

1. 资源所有者将其凭据提交到客户端应用程序。
2. 客户端将凭据转发到授权服务器。
3. 授权服务器返回访问令牌（以及可选的刷新令牌）
4. 客户端使用访问令牌代表资源所有者调用资源服务器。
   

什么时候使用？

资源所有者和客户端应用程序之间是否高度信任。 建议仅在无法进行其他处理时才使用它。 现在，设备流扩展可以涵盖资源所有者密码凭证授予的大多数原始用例。

设备流程

这是OAuth 2.0中新增的扩展流，用于覆盖设备具有Internet连接但没有浏览器或输入文字输入能力受限（例如电视）的情况。
在此流程中，设备要求用户使用浏览器（例如智能手机）在设备上打开特定的URL以便进行授权。

摘要

以下是设计为在给定场景中使用的流程的快速摘要：

• 服务器到服务器：客户端凭据流
• 服务器端应用程序：授权代码流
• SPA：没有客户端机密或隐式流的授权代码流
• 移动设备：PKCE的授权码流
• 没有浏览器的设备：设备流
  

翻译自: https://www.javacodegeeks.com/2019/01/right-flow-job-oauth-2-0-flow-should-use.html