使用 oAuth 2.0，在“authorization-code”授权授予中，我首先调用“/authorize”，获取代码，然后在调用“/token”中使用此代码获取访问令牌。
我的问题：为什么这是流程？我想这是出于安全原因，但我无法弄清楚。为什么是这样实现的，而不是在第一次调用（“/authorize”）后立即获取访问令牌？
我们为什么需要这个代码？
【问题讨论】：
标签： oauth-2.0
是否也可以通过此中间步骤阻止客户端查看访问令牌？
来自 O'Reilly 的书：
授权码 此授权类型最适合服务器端 Web 应用程序。在资源所有者拥有之后 授权访问他们的数据，他们被重定向回网络 使用授权码作为查询参数的应用程序 网址。客户端必须将此代码交换为访问令牌 应用。这种交换是服务器到服务器完成的，需要 client_id 和 client_secret，甚至阻止资源 所有者获取访问令牌。这种授权类型还允许 使用刷新令牌对 API 进行长期访问。
基于浏览器的客户端应用程序的隐式授权 隐式授权是所有流程中最简单的，并且经过优化 用于在浏览器中运行的客户端 Web 应用程序。资源 所有者授予对应用程序的访问权限，并且新的访问令牌是 立即使用#hash 生成并传递回应用程序 URL 中的片段。该应用程序可以立即提取 从哈希片段访问令牌（使用 JavaScript）并制作 API 要求。这种授权类型不需要中介 “授权码”，但它也不能刷新 用于长期访问的令牌。
更新 - 确实是的：
什么时候应该使用授权码流？授权 应该使用代码流
需要长期访问。
OAuth 客户端是一个 Web 应用程序服务器。
API 调用的问责制非常重要，OAuth 令牌不应泄露给用户可能访问的浏览器 它。
更多：
也许最重要的是——因为永远不会发送访问令牌 通过浏览器 - 访问令牌的风险较小 通过浏览器历史记录、引用标头泄露给恶意代码， JavaScript 等。
【讨论】：
授权码流程适用于涉及 3 方的场景。
这些各方是：
客户
用户使用他的网络浏览器。他想使用你的应用程序。
提供者
有关于用户的信息。如果有人想访问这些数据，用户必须先同意。
您的（网络）应用程序
想要从提供者那里访问有关用户的信息。
现在你的应用告诉用户（将他的浏览器重定向到/authorize端点）：
嘿用户，这是我的客户 ID。请与提供者交谈并允许他直接与我交谈。
因此，用户与提供者对话（请求授权码并通过在他的浏览器中打开您的回调URL将其返回给您的应用程序):
您好提供商，我想使用这个应用程序，所以他们需要访问我的数据。给我一些代码，我将此代码提供给应用程序。
现在您的应用拥有授权码，客户端和提供者已经知道了。通过将其交给provider，您的应用现在可以证明client允许它访问他的数据。 provider 现在会向您的（网络）应用发出一个访问令牌，因此您的（网络）应用不必每次都重做这些步骤（至少在一段时间内） .
如果您的应用程序直接在客户端运行的其他应用程序类型（例如 iPhone/Android 应用程序或 Javascript 客户端），则中间步骤是多余的。
【讨论】：
client/user <-> server/web app 背景且希望将其应用与数据提供商（例如 Google）连接起来的人。
客户端的数据通常被认为是不安全的。在初始步骤本身授予令牌的隐式调用的情况下，任何拥有 access_token 的人都可以请求数据，API 不知道谁在调用该 API。
但是，对于应用程序想要标识自己的 Web 服务器应用程序，带有 client_secret 的 client_id 与 authentication_code 一起发送以获取 access_token，以后可以单独发送。
假设，如果 access_token 最初被授予本身，那么作为 client_id 和 access_token 仍将被视为已公开，因此应用程序必须每次发送 client_secret 和 access_token 以确保请求确实来自它。
而在当前场景下，获取access_token后，可以独立进行进一步的请求，不需要client_secret。
【讨论】：
我觉得是这样的；
当我们使用授权码时，我们有2个验证部分；
因此，如果我们在用户进行身份验证时返回访问令牌而不是授权码，我们知道是用户请求它，但我们不知道它将用于注册的客户端。比如你的 webapp。
当我们使用“隐式授权”时；（或返回访问令牌而不是授权码）
【讨论】：
很重要的一点是
也许最重要的是——因为访问令牌永远不会通过浏览器发送——访问令牌通过浏览器历史记录、引用标头、JavaScript 等泄露给恶意代码的风险较小。
【讨论】：
@ksht 的回答基本上是正确的。对于那些寻求简单、简短答案的人来说，它是这样的：
因为客户端应用程序（浏览器或本机应用程序）可以拦截传递的令牌。 oauth implicit 流程确实 允许这样做，但仅在非常特定的情况下。在所有其他情况下，浏览器可能会泄漏信息（操作系统中的黑客攻击、浏览器错误、插件），或者对于本机应用程序，您可以拦截将重定向 url 映射到应用程序的自定义 url 方案。所以解决方法是发回代码而不是令牌（通过 tls）并使用 PKCE 确保代码可以安全地交换为令牌。
【讨论】：