为什么我们必须在 OAuth 中“更改令牌凭据的临时凭据”？

服务器不能只是将临时凭证“升级”为令牌凭证并保留相同的密钥和秘密吗？

然后，客户端可以在收到服务器的回调（表明临时凭证已“升级”）后立即开始进行经过身份验证的调用。

当然，如果临时凭证尚未升级（即客户端不等待回调），则经过身份验证的调用将失败。

所以问题是为什么在回调之后要对服务器进行额外的调用以将临时凭证“交换”为令牌凭证？

You could以这种方式实现 OAuth，但据我了解，将请求令牌与访问令牌分开确实提供了额外的安全层。

来自初学者指南 http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iii-security-architecture/:

OAuth包括两种Token： 请求令牌和访问令牌。每个 代币在以下方面具有非常特殊的作用： OAuth 委托工作流程。尽管 主要是 OAuth 如何进行的工件 规范的演变，两个令牌 设计提供了一些可用性和 安全功能使其成为 值得入住 规格。 OAuth 运行在两个 通道：前置通道 用于吸引用户并请求 授权，并使用反向通道 由消费者直接交互 与服务提供商。通过限制 反向通道的访问令牌， 令牌本身仍然是隐藏的 来自用户。这允许访问 具有特殊意义的代币 尺寸大于 前通道请求令牌是 请求时向用户公开 授权，并且在某些情况下需要 手动输入（移动设备 或机顶盒）。

因此，据我了解，通过将访问令牌限制为直接在消费者（您的服务）和提供者（您要访问的服务）之间的通道，您可以获得安全的访问令牌（即，攻击者没有）即使用户的计算机或用户与您的服务的网络连接受到损害。如果请求令牌只是升级，那么任何嗅探用户网络连接的人都可以轻松获取请求/访问令牌，我们希望对其保密，因为它可以用于（当然，与您的消费者令牌一起），可能用于很长一段时间，访问用户的数据。服务器到服务器的连接通常更安全。

此外，正如上面指出的，这可以让您在请求令牌实际上必须由用户输入的情况下拥有更长的密钥（因此可能非常短）。