为什么OAuth设计为具有请求令牌和访问令牌？

Question

在OAuth协议，服务消费者会询问用户授权的服务提供商领域请求令牌，则交流请求令牌从服务提供商访问令牌。

我想知道为什么OAuth被设计为在协议中有两个令牌。

为什么不在这个过程中使用一个令牌？也就是说，用户将授权代币，服务消费者将从代码中检索来自提供者的信息。

Answer 1

出于可用性和安全性原因。

从Beginner’s Guide to OAuth：

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

...虽然大部分的OAuth的规范是如何进化的神器，双令牌的设计提供了一些可用性和安全性功能这使得值得留在规范中。 OAuth在两个渠道上运行：用于吸引用户和请求授权的前台渠道，以及由用户直接与服务供应商互动的后台渠道。 通过将访问令牌限制为反向通道，令牌本身仍然保留在用户的隐藏位置。这允许访问令牌携带特殊含义并且具有比请求授权时暴露给用户的前置通道请求令牌更大的尺寸，并且在某些情况下需要手动输入（移动设备或机顶盒） 。

===

注意，这个问题是

Why must we "change temporary credentials for token credentials" in OAuth?

愚弄的人。如果从新手指南的解释不明确，然后再去读@npdoty's take on it。

Answer 2

从The Official OAuth 1.0 Guide

OAuth协议使网站或 应用（消费者），以从web服务 经由API（服务提供者），访问 受保护的资源，而不 要求用户公开其 服务提供商凭证给 消费者。更一般地说，OAuth 为API 认证创建了一个可自由实现和通用的方法。

一个例子使用的情况下是允许 打印服务printer.example.com （消费者），而不 访问存储在photos.example.net （服务提供商）的私人照片 要求用户提供其 photos.example.net凭证到 printer.example.com。

的OAuth不需要特定用户 接口或交互模式，也不 它指定如何服务提供商 验证用户身份，使得 协议非常适合用于例 其中认证证书 不可用于消费，如 与OpenID。

OAuth旨在将体验和 服务认证的实现统一到单个社区驱动的协议中。 OAuth 建立在现有协议和最佳 实践上，这些实践已经由各种网站独立实施。 开放标准由大型和小型供应商提供支持，为应用程序开发人员和 用户提供了一致且值得信赖的体验 这些应用程序的用户。

总结一下，基本上用户提供了一个OAuth请求令牌的用户名和密码。您向希望使用OAuth连接到某个服务的服务请求令牌，并且它们会接收访问令牌。这使得服务不会看到/使用用户名和密码。