OAuth 2.0文檔翻譯（第一章）

                                       OAuth 2.0 受權框架

概要

OAuth 2.0受權框架使得第三方應用得到有限的http服務，也表明了用戶（資源擁有者）經過策劃一個批准通訊在用戶和http服務之間，或者運行第三方應用表明自身得到權限。這個說明文檔取代了在RFC 5849描述的過期的OAuth 1.0協議。

這份備忘錄的地位

這是一個互聯網標準跟蹤文檔。

這份文檔是IETF(Internet Engineering Task Force：互聯網工程任務小組)的做品。表明了IETF團隊的一致意見。接受了公共的審查而且被IESG(Internet Engineering Steering Group:互聯網工程指導小組)批准發佈。互聯網標準更加詳細信息可在Section 2 of RFC 5741獲取。

第一章：介紹

在傳統的client—server認證模型中，client在server端使用resource owner 的證書認證而後請求protected resource。爲了使得第三方應用能訪問protected resource，resource owner 和第三方分享了它的證書，可是這也產生了一些弊端：

1.第三方應用被要求存儲resource owner 的證書以便未來使用，（證書）一般是明文密碼。

2.服務器被要求不顧在密碼方面的固有的安全缺陷，而去支持密碼受權。

3.第三方應用得到過多的用戶權限，使得resource owner 沒法限制時長（證書有效時間）或訪問一個被限制的資源子集。

4.resource owner 沒辦法撤銷對某一個應用的訪問權限必須經過改變用戶帳號的密碼才能實現，但這樣也會撤銷對其餘應用的訪問權限。（大概的意思是第三方帳號和密碼對於全部的第三方應用都是通用的，不可能只限制某一個應用）

5.任何一個第三方應用被破解，用戶密碼以及相關的數據都會泄露。

OAuth 2.0 經過引入受權層和把客戶端角色從用戶中分離出來解決這個問題。在OAuth 2.0中，client請求訪問被source owner控制、寄管在resource server上的資源。而且本分配了一系列不一樣的證書。

代替使用resource owner的證書訪問protected resources，client獲取一個access token（任務令牌）——一個指明瞭特定的範圍，生命週期和其餘的訪問屬性的字符串。access token是經resource owner贊成，由authorization server分配給第三方client的。client使用access token訪問被resource server 託管的資源。

例如，一個終端用戶（resource owner）能夠受權一個printing service（client）訪問存於photo sharing service（resource server）上的protected photo，而不用把他的用戶名和密碼告訴printing service。相反，他能夠經過一個被photo sharing service(authorization server)信任的server直接認證，server 給printing service分配一個特定受權證書（access token）。

這份文檔是爲使用HTTP設計的。([RFC2616]).OAuth 協議的使用暫不支持HTTP協議以外的其餘協議。

OAuth 1.0協議，被做爲一份報告文檔發佈，是一個小且特殊的團隊努力的結果。這份標準追蹤說明文檔是創建在OAuth 1.0部署的經驗以及額外的使用案例和源於更普遍的IETF(Internet Engineering Task Force:互聯網工程任務小組）擴展性要求。

OAuth 2.0協議並不向後兼容OAuth 1.0協議。這兩個版本共存於互聯網上，並且實現可能會選擇兩者都支持。然而，這篇文檔意在代表新的實現支持OAuth 2.0，而OAuth 1.0僅支持已經存在的實現上。OAuth 2.0和OAuth 1.0在具體的實現細節上只有不多是相同的。熟悉OAuth 1.0實現的用戶無須設想OAuth 2.0是其結構和細節。

1.1 角色（roles）

OAuth定義了四種角色

用戶（resource owner）

一個能受權訪問protected resource的實體。當用戶是我的的時候，被歸爲終端用戶。

資源服務器（resource server）

託管protected resource資源的服務器，可以接受和使用access token（訪問令牌）迴應protected resource請求。

客戶端（client）

使用認證表明用戶發出請求protected resource的應用。關鍵詞「client」並不包含任何特殊的實現特性（不論這個應用執行在server，desktop，仍是devices上）

認證服務器（authorization server）

當成功認證用戶而且得到認證後給客戶端分配access token的服務器。

認證服務器和資源服務器之間的通訊超出本文檔的範圍，認證服務器多是資源服務器也多是一個獨立實體。一個單一的認證服務器分發access token可能會被多個資源服務器接受。

1.2 協議流（protocal flow）

　　　　　　　　　　Figure 1 抽象協議流

 

圖1中闡明的抽象協議流描述了四種角色之間的通訊而且包含了一下步驟：

A：客戶端（client）從用戶（Resource Owner）請求受權，受權請求能夠直接向用戶發出，也能夠更好的間接經由認證服務器做爲中間件。

B：客戶端（client）接收認證受權，認證受權是代表了用戶受權的證書，被在這篇文檔中定義了的四種受權類型之一的受權方式或者擴展的受權方式實現。受權認證的類型取決於客戶端請求受權使用的方法和被認證服務器支持的類型。

C：客戶端（client）經過驗證認證服務器和上傳受權認證（Autorization Grant）請求訪問令牌（access token）。

D：認證服務器認證客戶端而且判斷受權認證（Autorization Grant）是否有效，若是有效，分配一個access token。

E：客戶端從資源服務器請求protected resource並經過access token進行驗證。

F:資源服務器判斷access token是否有效，若是有效，響應請求。

客戶端從用戶獲取受權認證（Authorization Grant）的更好的方法是使用認證服務器（Authorization Server）做爲中間件，它在Section 4.1的表3中被闡明。

1.3 受權認證（Authorization Grant）

受權認證（Autorization Grant）是一種代表用戶受權的證書，被客戶端用來獲取訪問令牌（access token）。這篇文檔定義了四種認證類型——受權碼模式（Authorization Code），隱式受權模式（implicit），用戶密碼證書模式（Resource Owner Password Credentials），客戶端證書模式（Client Credentials），以及定義其餘類型的擴展性機制（Extensibility Mechanism）。

1.3.1: 受權碼模式（Authorization Code）

受權碼（Authorization Code）是使用認證服務器（Autorization Server）做爲客戶端(Cilent)和用戶（Resource Owner）之間的中間件得到的。代替從用戶（Resource Owner）直接請求受權（Autorization），客戶端指導用戶（Resource Owner）轉到認證服務器（Outhorization Server）（經過用戶代理（user-agent)（被定義在RFC2616）實現）。反過來認證服務器引導用戶攜帶受權碼（Authorization Code）返回到客戶端。

在指導用戶攜帶受權碼（Autorization Code）返回客戶端以前，認證服務器（Autorization Server）驗證用戶並得到受權。由於用戶僅和認證服務器認證，而用戶的受權證書並不和客戶端分享。

受權碼（Authorization Code）提供了一些安全好處。例如認證客戶端，以及訪問令牌和客戶端直接通訊而無須通過用戶代理且能避免信息暴露給其餘用戶，包括當前用戶（Resource Owner）。

流程圖以下：

　　　　　　　　　　Figure 2 此圖參考阮一峯的博客

 流程分析：

A:用戶訪問客戶端，客戶端將用戶導向認證服務器（Authorization Server）

B:用戶給客戶端受權

C：認證服務器驗證用戶的受權認證，若是認證成功的話，返回受權碼（Authorization Code）

D:客戶端攜帶受權碼和重定向地址向認證服務器發出請求。

E:認證服務器驗證受權碼和重定向地址成功，返回token（Access Token，Refresh Token）

1.3.2 隱式受權模式（implicit）

隱式受權模式（implicit grant)是被簡化的受權碼流，方便客戶端在瀏覽器使用腳本語言的實現，例如JavaScript。在隱式流（implicit flow）中，代替給客戶的分配一個受權碼，客戶端被直接分配了一個訪問令牌（access token）（用戶受權的結果）。受權類型是隱式的，沒有分配中間證書（例如受權碼）。

在隱式流過程當中分配訪問令牌時，認證服務器並不驗證客戶端。一些狀況下，客戶端身份會經由重定向地址被識別，用於傳送訪問令牌給客戶端。訪問令牌可能會暴露於用戶和其餘有權訪問用戶代理的應用。

隱式受權提高了客戶端的響應能力和效率（例如客戶端做爲一個瀏覽器應用被實現）。由於他減小了爲獲取訪問令牌執行的循環執行的數量。然而，這種便利應該與使用隱式受權帶來的安全問題權衡。例如在Sections 10.3和10.16尤爲當受權碼受權類型是可獲取的。

 

　　　　　　　　Figure 3 此圖參考阮一峯的博客

流程分析：

A:用戶訪問客戶端，客戶端將用戶導向認證服務器

B:用戶受權客戶端登陸

C:認證服務器驗證用戶受權認證，返回重定 向地址和訪問令牌

D:客戶端使用重定向地址直接請求資源服務器

E:資源服務器返回javascript腳本語言文本

F:瀏覽器執行腳本，提早訪問令牌

 1.3.3用戶密碼證書模式（Resource Owner Password Credential）

用戶密碼證書模式能夠直接被用在受權認證（Authorization Grant）得到訪問令牌（Access Token），證書僅當用戶高度信任應用的時候被使用（應用是設備系統的一部分或具備高級權限的應用），並且當其餘受權認證類型（Authorization Grant Type）是不可實現時（例如受權碼模式）。

雖然認證類型要求客戶端直接訪問用戶證書，用戶證書被用來作獨立請求及交換訪問令牌。這種認證類型經過使用長生命週期的訪問令牌和更新令牌，能夠消除客戶端爲未來使用存儲用戶信息的需求。

流程圖以下：

　　　　　　　　Figure 4

流程分析：

A:用戶訪問應用，輸入用戶名和密碼

B:客戶端把密碼證書發給認證服務器

C:認證服務器驗證密碼證書有效，將訪問令牌和更新令牌發給客戶端。

1.3.4 客戶端證書模式（Client）

客戶端證書模式被用作受權認證當受權範圍是有限的受保護資源在客戶端的控制下，或受保護資源被認證服務器預先安排好。客戶端證書模式被應用典型的當客戶端做用自身（客戶端也是用戶）或者請求訪問在認證服務器預先安排好的受權基礎上的資源。

　　　　　　　　Figure 5 

流程分析：

A:客戶端直接向認證服務器發送身份驗證，請求訪問令牌

B:認證服務器返回訪問令牌

 

 1.4訪問令牌（Acess Token）

訪問令牌時訪問被保護資源的證書。訪問令牌是一段表示了給客戶端受權的字符串。這段字符串對客戶端通常是不透明的，令牌表明了訪問的範圍和時間，由用戶認證，被資源服務器和認證服務器執行。令牌表示被用來檢索受權信息或自身包含受權信息的標識符（一段令牌字符串自己包含一些數據和簽名）。額外的受權證書不在這篇文檔範圍以內，可能會被要求一致爲了方便用戶使用令牌。

訪問令牌提供一個抽象層，用一個被資源服務器理解的獨立令牌取代不一樣的受權設計（使用用戶名和密碼）。這種抽象使得分配訪問令牌更加受限比經過受權認證獲取他們，也取消了受權服務器理解普遍受權方法的需求。

訪問令牌在資源服務器安全需求上可有不一樣的格式，結構和應用方法。訪問令牌訪問被保護數據的屬性和方法超出了本文檔的範圍，具體可參照相關文檔如RFC6750.

1.5 更新令牌（refresh token）

更新令牌時用來獲取訪問令牌的證書。更新令牌被認證服務器分配給客戶端，被用來獲取新的訪問令牌噹噹前的訪問令牌時無效或過時了的時候，或用徹底相同或更少的權限獲取其餘訪問令牌（訪問令牌可能比被用戶認證具備更短的生命週期和更少的權限）。分配更新令牌在認證服務器時可選的。若是認證服務器分配一個訪問令牌，它是被包括的當分配一個訪問令牌時（Figure 1 ，Step D)

 一段更新令牌字符串表明了用戶對客戶端的受權認證。這段字符串對客戶端通常都是不透明的。令牌表示被用來檢索受權信息的標識符。不像訪問令牌，更新令牌僅和認證服務器關聯而和資源服務器無干。

流程圖以下

　　　　　　　　　　Figure 6 Refresh Token & Expired Acess Token

流程分析：

A:客戶端使用受權認證向認證服務器請求訪問令牌。

B：認證服務器驗證客戶端且判斷受權認證是否有效，若是有效，分配訪問令牌和更新令牌。

C:客戶端使用訪問令牌向資源服務器發出資源請求。

D:資源服務器驗證訪問令牌是否有效，若是有效，響應請求。

E:重複步驟C和D,直至訪問令牌過時，若是客戶端知道訪問令牌過時，直接跳到步驟G,不然會繼續發出資源請求。

F:因爲訪問令牌過時，資源服務器返回訪問令牌過時錯誤。

G:客戶端使用更新令牌向認證服務器認證，得到新的訪問令牌。客戶端受權需求是基於客戶端類型和認證服務器的政策基礎上的。

H:認證服務器認證客戶端並判斷更新令牌是否有效，若是有效，分配一個新的訪問令牌。（可選擇一個新的更新令牌）

步驟C、D、E、F不在本文檔敘述範圍，詳情參考Section 7

1.6 運輸層安全（Transport Layer Security:TLS)版本

不管TLS被這篇文檔什麼時候使用，基於普遍的部署和安全缺陷的考慮上，TLS相應的版本也會因時而異。寫這篇文檔是，TLS最新版本是1.2，可是部署受限且實現起來並不簡易。TLS 1.0版本應用最爲普遍且互操做性最好。

實現可能支持其餘知足他們安全需求的運輸船安全機制。

1.7 HTTP 重定向（HTTP Redirections)

這篇文檔使用了大量的HTTP重定向，以便客戶端或認證服務器導向用戶到另外的目的地。雖然篇文檔中的事例代表HTTP 302狀態碼的使用，經由用戶代理可獲得的方法實現重定向是被容許的且被考慮成爲實現的細節。

1.8 互操做性（Interoperability）

OAuth 2.0 提供了豐富的、被很好的定義了安全性能的受權框架。然而，做爲一個擁有許多可選擇的組件且具備豐富和可擴展性的框架，就其自己而言，這篇文檔更多的介紹了非互操做性實現。

除此以外，這篇文檔還保留了一下還沒有定義或定義了部分的被要求的組件（例如：客戶端等級，認證服務器性能，端點發現），沒有這些組件，客戶端須要手動的，特定地與認證服務器和資源服務器配置，爲了可以互操做。

這個框架是帶有明確的指望（將來的工做將會定義規範的文檔和擴展性必須實現徹底網絡規模互操做性）被設計的。

1.9 符號常規（Notational Conventions）

關鍵詞「MUST","MUST NOT","REQUIRED","SHALL","SHALL NOT","SHOULD","SHOULD NOT","RECCOMENDED","MAY",以及」OPTIONAL"在這篇文檔中被解釋爲如RFC2119所描述。

這篇文檔使用RFC5324中的擴展巴克斯範式（Augmented Bacus-Naur Form:ABNF)符號。此外，URI-reference的規則是包含在URI：generic syntax(Uniform Resource Indentifier:統一資源標識符)RFC3986

某幾個與安全相關的術語是在RFC4949中被定義的意義上來理解，這些術語包括但不侷限於：「attack","authentation","authorization","certificate","confidentiality","credential","encryption","identify","sign","signature","trust","validate"和"verify".

除非另有說明，全部的協議參數名稱和值都是區分大小寫的。