爲什麼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連接到某個服務的服務請求令牌，並且它們會接收訪問令牌。這使得服務不會看到/使用用戶名和密碼。