这是隐式流和 AuthCode 流之间的区别：

隐式流

注意：自 2019 年 4 月起，Oauth 工作组不再建议在大多数情况下使用隐式流，因为有更好、更安全的方法来完成相同的事情。

1. 用户导航到 SPA，它将用户重定向到 IdP 以登录。
2. 用户登录（并授权应用程序，如果需要）。
3. IdP 使用访问令牌和 ID 令牌将用户返回到 SPA。
4. SPA 中的 JavaScript 代码将访问令牌和 ID 令牌存储在浏览器中localStorage，并针对它发出的每个请求（通常作为标头）将访问令牌发送到 REST API 服务器。Authorization: Bearer <access token>
5. 如果需要，REST API 服务器通过与 IdP 交谈来检查访问令牌的有效性。（通常，在 IdP 中签署令牌并验证签名就足够了，实际上不需要通信。）

授权码流程

1. 用户导航到 SPA，它将用户重定向到 IdP 以登录。
2. 用户登录（并授权应用程序，如果需要）。
3. IdP 使用授权码将用户返回到 SPA。
4. SPA 中的 JavaScript 代码将授权代码发送到loginREST API 服务器上的端点。
5. REST API 服务器向 IdP 服务器发送一个请求，其中包含授权代码（通常还有一个客户端 ID 和客户端密码，用于向 IdP 服务器标识 REST API 服务器）。
6. IdP 验证授权代码并将访问令牌和 ID 令牌发送到 REST API 服务器。
7. REST API Server 将 Access Token 和 ID Token 存储在其内存中，并将其自己的 Session Token 发送回 SPA。
8. 对于 SPA 向 REST API 服务器发出的每个请求，它都包含 REST API 服务器给它的会话令牌。如果 REST API 服务器需要从另一个服务器请求资源，它会使用存储的访问令牌来发出请求。

您可以从这里看到，AuthCode 流程比隐式流程复杂得多，但好处是访问令牌永远不会存储在用户的控件中。

但是，在这种情况下存储令牌的主要目的不是为了您自己的身份验证，而是为了 REST API Server 需要与其他服务对话的情况，例如 Google、Facebook、Twitter 等。

如果您只使用 OpenID Connect 登录到您自己的 REST API 服务器，但服务器本身不需要使用凭据，那么实现隐式流程要容易得多，而实现 AuthCode 流程实际上并没有为您带来任何好处。