为什么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连接到某些内容的服务提供给请求令牌，并且他们会收到访问令牌。这使得服务永远不会看到/使用用户名和密码。