開放_OAuth2.0_cn.doc

目 錄OAuth的2.0授權(quán)協(xié)議11簡介11.1角色21.2協(xié)議流31.3權(quán)限授予（AuthorizationGrant）41.3.1授權(quán)碼51.3.2隱式51.3.3資源所有者密碼憑據(jù)51.3.4ClientCredentials61.4訪問令牌61.5刷新令牌622. ClientRegistration客戶注冊82.1客戶端類型82.2客戶端標識符92.3客戶端身份驗證102.3.1客戶端的密碼102.3.2其他身份驗證方法112.4未注冊的客戶端123協(xié)議的端點123.1授權(quán)端點123.1.1響應類型133.1.2重定向向端點133.2令牌端點153.2.1客戶端身份驗證153.3Access Token Scope164Obtaining Authorization164.1授權(quán)碼164.1.1授權(quán)申請174.1.2授權(quán)應答194.1.3訪問令牌請求214.1.4訪問令牌應答224.2隱式授權(quán)234.2.1授權(quán)請求254.2.2訪問令牌應答264.3資源所有者密碼憑據(jù)284.3.1授權(quán)請求和應答294.3.2訪問令牌請求294.3.3訪問令牌應答314.4客戶端憑證324.4.1授權(quán)請求和應答324.4.2訪問令牌請求324.4.3訪問令牌響應334.5擴展345分發(fā)訪問令牌355.1成功的響應355.2錯誤響應366刷新訪問令牌387訪問受保護資源407.1訪問令牌類型408可擴展性418.1定義訪問令牌類型418.2定義新端點參數(shù)418.3定義新的權(quán)限授予類型428.4定義新的授權(quán)端點響應類型428.5定義額外的錯誤碼429本地應用4310安全注意事項4410.1客戶端認證4410.2客戶端模擬4510.3訪問令牌4510.4刷新令牌4510.5授權(quán)碼4610.6授權(quán)碼重定向URI的操作4610.7資源所有者密碼保密4710.8請求保密4710.9端點授權(quán)4710.10憑證猜測攻擊4710.11釣魚攻擊4710.12夸站點請求偽造4810.13Clickjacking（跨瀏覽器攻擊）4810.14代碼注入和輸入驗證4911IANA事項4911.1OAuth訪問令牌類型注冊表4911.1.1注冊模板4911.2The OAuth Parameters Registry5011.2.1注冊模板5011.2.2初始登記冊的類容5111.3OAuth授權(quán)端點響應類型注冊表5411.3.1注冊模板5511.3.2初始注冊表內(nèi)容5511.4OAuth擴展錯誤注冊表5611.4.1注冊模板5612CSRF(cross-site request forgery)5712.1示例和特性5712.2防范措施5712.3影響CSRF的因素5713共享session5813.1問題5813.1.1網(wǎng)站存在多個子域名的情況下如何共享session5813.1.2同一個主域名不同服務器之間如何共享session5813.2方案5813.2.1創(chuàng)建數(shù)據(jù)庫表5813.2.2Session數(shù)據(jù)庫操作58 OAuth的2.0授權(quán)協(xié)議草案-IETF-OAuth - V2 22摘要：OAuth的2.0授權(quán)協(xié)議允許第三方應用程序獲取機會有限的HTTP服務，無論是以資源所有者的名義通過協(xié)調(diào)的批準資源所有者和HTTP服務互動，或通過允許第三方應用程序，以自己的名義獲得的訪問。1 簡介在傳統(tǒng)的客戶端 - 服務器的身份驗證模型中，客戶端使用資源所有者服務器上憑據(jù)（credentials） 進行身份驗證來申請訪問受限資源（受保護的資源）。 為了提供第三方應用程序訪問受限制的資源，資源的所有者分享其憑據(jù)給第三方。 這將產(chǎn)生幾個問題和限制：a. 第三方的應用程序需要存儲資源業(yè)主的憑據(jù)，以備將來使用，通常是一個明確的密碼文本。b. 服務器都必須支持密碼認證，盡管創(chuàng)建密碼是安全薄弱環(huán)節(jié)。c. 第三方應用程序獲得對資源所有者的受保護的資源過大的權(quán)限，讓資源所有者沒有能力限制周期或訪問一個有限子集資源。d. 資源所有者不能在沒有撤銷所有的第三方訪問的情況下，撤銷個別第三方的訪問，而且必須改變自己的密碼來做這樣的事。e. 折中的任何第三方的應用程序?qū)е抡壑械淖罱K用戶的密碼和所有的數(shù)據(jù)被該密碼保護。OAuth 定位這些問題是通過引入授權(quán)層和從資源所有者那里分離客戶端的角色。 在OAuth中，客戶端請求訪問被資源所有者控制和資源服務器托管的資源，并發(fā)出了跟資源所有者不同的憑據(jù)集合?？蛻舳双@得一個訪問令牌，即一個一個字符串，表示一個具體范圍，壽命和其他訪問屬性，而不是使用資源所有者的憑據(jù)來訪問受保護資源。訪問令牌被授權(quán)服務器批準資源的所有者頒發(fā)給第三方客戶端。 客戶端使用訪問令牌訪問資源服務器托管的受保護資源。例如，最終用戶（資源所有者）可以授予一個打印服務（客戶端）訪問她的存儲在共享服務（資源服務器）里受保護相片，而不共享與打印服務相關(guān)的用戶名和密碼。相反，她直接用照片共享服務（授權(quán)服務器）驗證信任的服務器，這些照片共享服務產(chǎn)生打印服務的特定代表的憑據(jù)（訪問令牌）。本規(guī)范是專為使用HTTP設計的。使用HTTP之外的其他任何傳輸協(xié)議的OAuth的是不確定的。1.1 角色OAuth的定義四個角色：resource owner資源的所有者：可以獲得授權(quán)去訪問受保護的資源的實體。這句很繞口，簡單來說就是資源的所有者，這個所有者是指當初上傳或生成的那個所有者，并不是指服務器的所有者。resource server資源服務器：承載受保護資源的服務器，可以接收和響應使用access token（訪問令牌）請求受保護資源。cilent客戶端：一個產(chǎn)生受保護資源請求的應用，該應用代表resource owner，并且已經(jīng)獲得其授權(quán)。所以其實客戶就是指前面說道的這種特性的應用，是種application。authorization server授權(quán)服務器：在成功驗證資源所有者和獲得授權(quán)后，服務器發(fā)行訪問令牌給客戶端。授權(quán)服務器和資源服務器之間的相互作用超出本規(guī)范的范圍。 授權(quán)服務器可能是同一臺服務器作為資源的服務器或一個獨立的實體。單一授權(quán)服務器發(fā)出訪問令牌可能被多個資源服務器接受。1.2 協(xié)議流如圖1所示的抽象流描述的四種角色之間的互動還包括了一下步驟:(A)client（就是application）向resource owner請求授權(quán)。可以直接向resource owner請求，但更好的是通過authorization server作為中間物間接獲得。（比如新浪微博的是否允許授權(quán)的頁面）(B)client獲得了resource owner的授權(quán)認可（authorization grant），此授權(quán)認可是四種標準授權(quán)認可類型中的一種，也可以是其中一種的擴展類型。獲得的授權(quán)認可的類型由client請求授權(quán)所使用的函數(shù)和authorization server支持的類型決定。（比如采用特定的請求授權(quán)的url，但是傳入不同的參數(shù)，或者使用的method不同，當然一切都至少服務器要支持）(C)client提供授權(quán)認可，以請求一個access token，該token是可以被authorization server驗證的。(D)authorization server驗證client，并且核實授權(quán)認可，如果是有效，就發(fā)放access token。注意這里是兩個驗證，1驗證client是不是被承認的，2驗證resource owner是不是真的授權(quán)了。(E) clent提供access token給resource server驗證，判斷此client是否可以獲取受保護的資源。(F) resource server核實access token，如果有效則響應請求1.3 權(quán)限授予（AuthorizationGrant）權(quán)限授予是一個憑證，代表著資源所有者的授權(quán)（訪問它的受保護資源），它被客戶端用來獲得一個訪問令牌。此規(guī)范定義了四種授予類型：的授權(quán)金是代表資源的憑據(jù)由所有者的授權(quán)（訪問受保護的資源）客戶端獲得一個訪問令牌。 此規(guī)范定義了四種授予類型：授權(quán)碼，隱式，資源所有者密碼憑據(jù)，客戶端憑據(jù)，以及一個擴展定義其他類型的機制。1.3.1 授權(quán)碼授權(quán)碼是通過使用授權(quán)服務器作為客戶端和資源所有者之間的中介被獲取的。客戶端請求授權(quán)指示資源所有者的授權(quán)服務器，這樣服務器反過來又指導資源所有者將授權(quán)碼返回客戶端。而不是直接向資源的所有者申請授權(quán)。在引導資源所有者將授權(quán)碼返回客戶端之前，授權(quán)服務器驗證資源的所有者并獲得授權(quán)。由于資源的所有者只跟授權(quán)服務器認證，資源所有者的憑證不會與客戶端分享。授權(quán)碼提供了一些重要的安全優(yōu)勢如驗證客戶端的能力，和不通過資源所有者的用戶代理而直接給客戶端的訪問令牌傳輸，可能暴露給他人，包括資源的所有者。1.3.2 隱式隱式授予是一個簡化的授權(quán)碼流，為了優(yōu)化客戶端實現(xiàn)在瀏覽器中使用例如JAVAScript的腳本語言。在隱流中，客戶端直接發(fā)出一個訪問令牌（作為資源的所有者授權(quán)的結(jié)果），而不是給客戶端發(fā)出一個授權(quán)碼。授予類型是隱式的就像沒有中間的憑據(jù)（如授權(quán)碼）被發(fā)出（后來被用來獲得一個訪問令牌）。 當發(fā)出一個隱含的授予，授權(quán)服務器不驗證客戶端。在某些情況下，可以通過用來給客戶端提供的訪問令牌的重定向URI，來驗證客戶端的身份。訪問令牌可能會被暴露給資源的所有者或者其它要訪問資源所有者的用戶代理的應用程序。隱式授權(quán)提高了某些客戶端的響應速度和效率（如實現(xiàn)在瀏覽器應用程序的客戶端），因為它降低了獲得所需的往返訪問令牌的數(shù)量。然而，這種便利應權(quán)衡使用隱式授權(quán)的安全隱患，尤其是當授權(quán)碼授予類型是可用的。1.3.3 資源所有者密碼憑據(jù)資源所有者密碼憑據(jù)（即用戶名和密碼）可直接作為一個權(quán)限授予獲得訪問令牌。憑證只有在資源所有者和客戶端之間存在一個高等級的信任的時候使用（如設備的操作系統(tǒng)或一個高特權(quán)的應用程序），或者當其它權(quán)限授予類型不可用時（如授權(quán)碼）憑據(jù)才被使用。盡管這種授權(quán)類型需要引導客戶端訪問資源所有者憑證，資源所有者憑證被用于一個單一的請求，并交換一個訪問令牌。這種授予類型用持久的訪問令牌或刷新令牌來交換憑據(jù)，這樣可以消除客戶端必須存儲以供將來使用的資源所有者憑證的需要。1.3.4 ClientCredentials客戶憑證（或其他形式的客戶端身份驗證）可被用作一個權(quán)限授予當授權(quán)范圍被限制在保護資源在客戶端控制下，或者 授權(quán)資源先前被安排給授權(quán)服務器。當客戶端正以自己的名義行事（客戶端也是資源所有者），或者客戶端正在請求訪問根據(jù)一個授權(quán)先前安排的授權(quán)服務器的受保護資源時，客戶端憑證被典型被用來作為一種權(quán)限授予。1.4 訪問令牌訪問令牌是用于訪問受保護的資源的憑據(jù)。 一個訪問令牌是一個字符串，代表發(fā)送給客戶端的授權(quán)。字符串通常是對客戶端不透明的。令牌代表訪問的具體范圍和持續(xù)時間，由資源所有者授予，被資源的服務器和授權(quán)執(zhí)行服務器強行執(zhí)行。令牌可以表示用于檢索授權(quán)信息的標識符，或用一種可核查的方式自我包含在授權(quán)信息中（即一個令牌字符串的一些數(shù)據(jù)組成和簽名）。 超過了本規(guī)范范圍的額外的身份驗證憑據(jù)，可能為了客戶端使用令牌而被需要。訪問令牌提供了一個抽象層，用一個簡單的被資源服務器理解的令牌來更換不同單一授權(quán)結(jié)構(gòu)（如用戶名和密碼）。 這種抽象使發(fā)出的訪問令牌比用來接收他們的權(quán)限授予更具有限制性，以及刪除資源服務器的需要去了解一個廣泛的驗證方法。訪問令牌可以有不同的格式，結(jié)構(gòu)和基于資源服務安全性需求的方法利用率（如加密屬性）。訪問令牌的屬性和用于訪問受保護資源的方法超出了本規(guī)范和同伴規(guī)范定義的范圍。1.5 刷新令牌刷新令牌是用來獲取訪問令牌的憑據(jù)。在當前的訪問令牌變成無效或過期，或獲得額外的訪問令牌具有相同或更窄的范圍（訪問令牌可能有較短期少于資源授權(quán)的權(quán)限所有者）時，刷新令牌被授權(quán)服務器發(fā)送給客戶端用于獲取一個新的訪問令牌。分發(fā)刷新標記是可選的。如果authorization server分發(fā)可刷新令牌，那么當分發(fā)access token的時候就會將可刷新令牌包括進去。刷新令牌是一個字符串，代表權(quán)限被資源所有者授予給客戶端。字符串通常對客戶端是透明的。令牌表示用于檢索授權(quán)信息的標示符。與訪問令牌不同的是，可刷新令牌只被用于授權(quán)服務器，而不會發(fā)送給資源服務器。發(fā)送給資源服務器的始終是訪問令牌。下面看一個關(guān)于可刷新令牌的處理流程圖。該流程圖包括以下步驟：（A）客戶端訪問授權(quán)服務器進行驗證，通過提供授權(quán)認可，以請求訪問令牌。（B）授權(quán)服務器驗證客戶端并且驗證授權(quán)認可（四種類型中的一種），如果有效則分發(fā)一個訪問令牌和一個可刷新令牌（C）通過提供訪問令牌，客戶端可向資源服務器請求受保護資源。（D）資源服務器驗證驗證訪問令牌，如果有效，就響應請求。（E）步驟（C）和（D）重復進行，直到訪問令牌過期。如果client知道訪問令牌過期，就直接跳到步驟（G），否則它還會請求受保護資源。（F）由于訪問令牌失效，資源服務器返回無效令牌錯誤。（G）client請求一個新的訪問令牌，通過向授權(quán)服務器提供可刷新令牌并進行驗證。對client的驗證條件是基于client的類型和authorization server的策略。（H）authorization server驗證client和可刷新令牌，如果有效就分發(fā)一個新的訪問令牌（你也可以再發(fā)送一個新的可刷新令牌）2 2. ClientRegistration客戶注冊發(fā)起協(xié)議之前，客戶端注冊授權(quán)服務器。在客戶端注冊透過何種途徑與授服務器超出此范圍規(guī)范，但通常涉及與最終用戶互動HTML登記表?？蛻舳俗圆恍枰蛻舳撕褪跈?quán)服務器之間的直接互動。當支持授權(quán)服務器時，注冊可以依靠其他手段建立信任和獲取所需的客戶端屬性（例如：重定向的URI，客戶端類型）。例如，可以注冊使用自發(fā)行或第三方發(fā)行的主張來實現(xiàn)，或授權(quán)服務器執(zhí)行客戶端發(fā)現(xiàn)使用信任的渠道。2.1 客戶端類型OAuth的定義了兩種客戶端類型，在授權(quán)服務器下根據(jù)自己的能力驗證安全性（即保持他們的客戶端憑據(jù)的保密的能力）：保密性：客戶能夠保持其憑據(jù)機密性（如客戶端一個安全的服務器與實施限制訪問的客戶端憑據(jù)），或使用其他手段保證客戶端身份驗證安全的能力。公開性：客戶無法維持其保密憑據(jù)（如客戶資源所有者的設備上執(zhí)行如安裝本地應用程序或基于Web瀏覽器應用程序），無法通過任何其他手段確?？蛻舳松矸蒡炞C安全?？蛻纛愋偷闹贫ㄊ腔谑跈?quán)服務器安全認證的定義和它可接受的風險級別的客戶端憑據(jù)。此規(guī)范已經(jīng)圍繞以下客戶端設計配置文件：Web應用程序Web應用程序是一個網(wǎng)絡服務器上運行的機密的客戶端。資源所有者通過一個HTML用戶界面呈現(xiàn)在資源所有者的設備上的用戶代理來訪問客戶端。客戶端憑據(jù)，以及任何分發(fā)給客戶端的訪問令牌被存儲在Web服務器上，并沒有暴露或由資源的所有者訪問。用戶代理為基礎的應用用戶代理為基礎的應用是一個公共的客戶端，客戶端代碼是從Web服務器下載，并在資源所有者的設備（如Web瀏覽器）上的用戶代理執(zhí)行?！皡f(xié)議”的相關(guān)數(shù)據(jù)和憑證能方便（而且往往可見）資源的所有者訪問。 由于這些應用程序駐留在用戶代理上，他們可以在請求權(quán)限時無縫使用用戶代理能力。本機應用程序本機應用程序是在公共的客戶端上安裝和資源所有者的設備上執(zhí)行的?！皡f(xié)議”的相關(guān)數(shù)據(jù)和憑據(jù)可被資源的所有者訪問。據(jù)推測，任何包含在應用程序內(nèi)的客戶端身份驗證憑據(jù)可以被提取。另一方面，動態(tài)分發(fā)的憑據(jù)，例如訪問令牌或刷新令牌可以得到一個可接受的水平保護。在最低限度，隔離這些憑據(jù)與該應用程序可能交互的敵對服務器之外。在某些平臺，這些憑據(jù)可能被保護，使之與駐留在同一設備上的其它應用程序隔離。2.2 客戶端標識符授權(quán)服務器分發(fā)給登記客戶端一個客戶標識符一個唯一的字符串代表由客戶提供的登記信息。客戶端標識符是不是公開的秘密，它暴露給資源所有者，絕不能單獨適用于客戶端身份驗證。2.3 客戶端身份驗證如果客戶端類型是保密的，客戶端和授權(quán)服務器建立適合授權(quán)服務器的安全需求的一個客戶端驗證方法。授權(quán)服務器可以接受任何形式的客戶端認證，滿足其安全要求。保密客戶通常使用授權(quán)服務器發(fā)出（或建立）一套用于授權(quán)的客戶憑證（如密碼，公鑰/私鑰對）的客戶端憑據(jù)。授權(quán)服務器不應該對客戶端的類型做假設，或者接受沒有與客戶或者開發(fā)者建立信任所提供的類型信息。授權(quán)服務器可能用公共客戶建立一個客戶授權(quán)方法。但是，授權(quán)服務器決不能為了認證客戶的目的而依靠公共客戶端認證?？蛻舳瞬坏檬褂枚鄠€驗證方法在每個請求。2.3.1 客戶端的密碼私有一個客戶端密碼的客戶端可以使用HTTP基本驗證計劃?？蛻舳藰俗R符用作用戶名，客戶端的密碼是用來作為密碼。例如（額外的換行符僅用于顯示目的）：授權(quán)：基本czZCaGRSa3F0MzpnWDFmQmF0M2JW另外，授權(quán)服務器可能允許客戶端憑證包括在請求體使用如下的參數(shù)：Client_id REQUIRED. 在登記過程中客戶端標示符分發(fā)給客戶端 Client-secret REQUIRED. 客戶 secret?？蛻舳丝梢允÷詤?shù)如果客戶secret是空字符串?？蛻舳藨{證包括在請求正文中使用兩個客參數(shù)不被推薦，并應限于客戶端無法直接利用HTTP基本身份驗證計劃（或其他基于密碼的HTTP認證方案）。例如，請求刷新一個訪問令牌（第6章）使用正文參數(shù)（額外的換行符僅用于顯示目的）： POST /token HTTP/1.1 Host: Content-Type:application/x-www-form-urlencoded;charset=UTF-8grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw當將請求發(fā)送到令牌端點時，授權(quán)服務器必須要求使用傳輸層安全機制，這樣請求使用此認證方法的導致明文憑據(jù)的傳輸。由于這個客戶端的身份驗證方法包括密碼，授權(quán)服務器必須保護任何終端利用它對抗端點蠻力攻擊。2.3.2 其他身份驗證方法授權(quán)服務器可能支持任何合適的HTTP認證計劃匹配其安全性要求。當用其他的身份驗證方法，授權(quán)服務器必須在客戶端標識符（登記備案）和身份驗證方案之間定義一個映射。2.4 未注冊的客戶端本規(guī)范不排除使用未經(jīng)注冊的客戶。但是，這樣的客戶使用超出此范圍規(guī)范，并且需要額外的安全分析和審查其互操作性的影響。3 協(xié)議的端點授權(quán)過程中利用兩個端點（HTTP資源）：授權(quán)端點-用于向通過用戶代理重定向的資源所有者獲取授權(quán)。令牌終點 -用來交換權(quán)限授予訪問令牌，通常隨著客戶端身份驗證。并非每個授權(quán)授予類型采用兩個端點。如有需要，擴展授予類型可以定義額外的端點。3.1 授權(quán)端點授權(quán)端點用來與資源所有者交互,獲得權(quán)限的授予。授權(quán)服務器必須首先驗證資源的所有者的身份。方式授權(quán)服務器驗證資源所有者（如用戶名和密碼登錄，會話cookies）超出范圍本規(guī)范?？蛻舳送高^何種途徑獲得授權(quán)端點的位置超出本規(guī)范的范圍，但位置通常在服務文檔里被提供。端點URI可能包括一個“application/x-www-form-urlencoded”格式化的查詢組件，加入額外的查詢參數(shù)時，必須保留。端點URI不能包含片段組件。由于請求授權(quán)端點導致用戶身份驗證和明文憑據(jù)（HTTP響應）的傳輸，授權(quán)服務器必須要求在授權(quán)端點發(fā)送請求時使用的傳輸層安全機制。授權(quán)服務器必須支持TLS 1.0,應該支持TLS 1.2和它的以后的版本，可以支持額外的傳輸層機制以滿足它的安全性需要。授權(quán)服務器必須支持對授權(quán)斷點的HTTP “GET” 方法的使用，也可以支持“POST”方法的使用。沒有賦值的參數(shù)必須當做它們是從請求中被忽略的。授權(quán)服務器必須忽視無法識別的請求參數(shù)。請求和回應參數(shù)必須不能被包含超過一次。3.1.1 響應類型 是被授權(quán)碼授權(quán)類型和隱式授權(quán)類型流使用的。客戶端通知需要授權(quán)類型的授權(quán)端點使用以下參數(shù)。response_typeREQUIRED. 它的值必須是請求授權(quán)碼中一個碼就像4.1.1結(jié)所描述，令牌就如4.2.1結(jié)描述的請求一個訪問令牌（隱式授予），或者一個如8.4結(jié)描述的注冊擴展值。如果響應類型包括一個或者更多空格字符（%x20）, 它被解釋為一個空格分隔列表值，值的順序沒有關(guān)系（例如“a b”跟“b a”是一樣的） 如果一個授權(quán)響應丟失了“response_type”參數(shù)，授權(quán)服務器必須返回一個錯誤回復，就如結(jié)所述。3.1.2 重定向向端點與資源的所有者完成互動后，授權(quán)服務器指示資源所有者的用戶代理返回客戶端。授權(quán)服務器重定向用戶代理到客戶端的重定向終點，重定向終點是先前客戶端注冊進程或者發(fā)出授權(quán)請求時由授權(quán)服務器建立的。 重定向端點URI必須是一個絕對的URI，如4.3所述。終點 URI可能包含anapplication/x-www-form-urlencoded格式化查詢組件，加入額外的查詢參數(shù)時，必須保留。端點URI不能包含片段組件。 端點要求保密如果一個重定向請求將導致授權(quán)碼的傳輸或者訪問令牌通過一個開放網(wǎng)絡（在資源所有者的用戶代理和客戶端之間），客戶端應需要使用傳輸層安全機制。 傳輸層安全性的缺乏可能對客戶端的安全和受保護資源授權(quán)訪問造成嚴重影響。當客戶端將授權(quán)過程當做一種委派最終用戶身份驗證時，傳輸層安全機制的使用變得尤為關(guān)鍵。 注冊要求授權(quán)服務器應要求所有client用授權(quán)終端登記他們先前的重定向URI，并且必須要求以下的client登記他們的重定向URI：a) public clientsb) 安全的clients 使用隱式的授權(quán)類型授權(quán)服務器應要求客戶端提供完整的重定向URI（客戶端可以使用“state”的請求參數(shù)來實現(xiàn)每個請求定制）。授權(quán)服務器允許客戶端注冊多個重定向URI. 如果要求完成重定向的URI注冊登記是不可能的，授權(quán)服務器應要求URI方案，權(quán)限和路徑（請求授權(quán)時，許客戶端動態(tài)改變注冊重定向URI的查詢組件）的注冊。 動態(tài)配置如果已注冊多個重定向的URI，如果只有部分重定向URI已被注冊，或如果沒有重定向URI已注冊，客戶端必須包括重定向URI，在授權(quán)請求時使用“redirect_uri”請求參數(shù)。 當一個重定向URI 被包含在授權(quán)請求中時，授權(quán)服務器必須比較和匹配最少一個接受到的已注冊的重定向URI（或者URI組件）就如第6章定義的，如果任何重定向URI被注冊了，授權(quán)服務器必須使用簡單的字符串比較對比兩個URI，就如6.2.1結(jié)所述。 如果授權(quán)服務器準許client動態(tài)的改變重定向URI的查詢組件，client 必須確保操作查詢組件時不被攻擊者濫用重定向終點，就如10.15結(jié)所述。.1 無效端點如果授權(quán)請求驗證失敗是由于丟失，無效，或者重定向URI不匹配，授權(quán)服務器必須通知資源所有者錯誤信息，必須不能自動重定向用戶代理到無效的重定向URI。授權(quán)服務器不應該重定向用戶代理到未注冊或者不信任的URI ，以防止授權(quán)終端被公開的重定向者利用。.2 端點內(nèi)容到客戶端點的重定向請求通常結(jié)果是一個HTML的文檔響應，被用戶代理所有。如果HTML響應被直接服務為重定向響應的結(jié)果，任何腳本包括HTML文檔會帶著全部重定向URI訪問和它自帶的憑證執(zhí)行。Client 必須不能包含任何不受信任第三方腳本在重定向端點響應中（比如 第三方分析器，社區(qū)插件，網(wǎng)絡服務），第三方腳本沒有第一次保證 它自己被用來提取和刪除在URI的憑證的腳本將首次執(zhí)行。Client 不應該包含任何第三方腳本在重定向端點響應中。相反的，它應該從URI和重定向用戶代理中提取憑證，并在沒有憑證的URI里重定向用戶代理到另外的端點。3.2 令牌端點令牌端點被client用來接受一個介紹他權(quán)限授予或者刷新令牌的訪問令牌。令牌端點被每一個權(quán)限授予使用，除了隱式授予類型（應為訪問令牌被直接分發(fā)）?？蛻舳送高^何種途徑獲得令牌的位置端點超出本規(guī)范的范圍，但通常在服務文檔里提供。沒有賦值的參數(shù)必須當做它們是從請求中被忽略的。授權(quán)服務器必須忽視無法識別的請求參數(shù)。請求和回應參數(shù)必須不能被包含超過一次。3.2.1 客戶端身份驗證保密的客戶，分發(fā)客戶憑證的客戶，或者交辦其它授權(quán)請求的客戶必須被授權(quán)服務器驗證身份在產(chǎn)生對令牌端點的請求時，就如2.3所述?？蛻舳松矸蒡炞C被用來：(a) 執(zhí)行客戶端分發(fā)的刷新令牌和授權(quán)碼到客戶端的綁定。當一個授權(quán)碼通過不安全的通道或者當重定向URI還沒有被全部注冊時，授權(quán)碼傳送到重定向端點的關(guān)鍵是客戶端驗證。(b) 通過禁用客戶端或改變其憑據(jù)來從受影響的客戶端恢復，從而防止攻擊者濫用被盜刷新令牌。改變一個單一的客戶端憑據(jù)集合顯然比撤銷整套刷新令牌的更快。(c) 實施認證管理的最佳做法，需要定期憑據(jù)輪換。整套刷新令牌的輪換可能是具有挑戰(zhàn)性，而一個單一的客戶端憑據(jù)的輪換顯然比較容易。在給令牌端點傳送請求時，一個沒有被分發(fā)客戶密碼的公共客戶可能使用“client_id”請求參數(shù)來認證它自己。準許公共客戶到令牌端點的未認證訪問的安全后果，如同到公共客戶的不安全的刷新令牌必須被考慮。3.3 Access Token Scope身份認真和令牌端點準許客戶使用“scope”請求參數(shù)指定訪問請求的范圍。反過來，授權(quán)服務器使用的“范圍”的響應參數(shù)通知客戶端發(fā)出的訪問令牌的范圍。范圍參數(shù)值表示為空間分隔，大小寫敏感的字符串列表。這個字符串被授權(quán)服務器定義。如果值包含過個空間分隔字符串，他們的順序沒關(guān)系，每個字符增加一個額外的訪問邊界給請求邊界。授權(quán)服務器可能全部或者部分忽視客戶端請求的邊界，該客戶請求時根據(jù)授權(quán)服務器政策或資源所有者的指。如果分發(fā)訪問令牌邊界與客戶端請求的不同，授權(quán)服務器應該包括“scope”響應參數(shù)去通知客戶端實際被授予的邊界。4 Obtaining Authorization 4.1 授權(quán)碼授權(quán)碼授予類型被用來獲得訪問令牌和刷新令牌，還被用來優(yōu)化機密性客戶端。作為一個基于重定向的流，客戶必須具有與資源所有者的用戶代理（通常是是web 瀏覽器）交互的能力和接受來自授權(quán)服務器進入請求（通過重定向）的能力。上面的流程圖包括了如下3個步驟：（a） 客戶端開始流程，引導資源所有者的用戶代理到授權(quán)端點?？蛻舳税ㄆ淇蛻舳藰俗R符，請求的范圍，本地狀態(tài)和重定向URI，重定向URI是當訪問被授權(quán)后授權(quán)服務器發(fā)送回的用戶代理的。（b） 授權(quán)服務器認證資源所有者（通過用戶代理）然后建立客戶端的訪問請求，不論資源所有者授權(quán)或者拒絕。（c） 假如資源所有者授權(quán)訪問，授權(quán)服務器使用先前重定向URI（在請求時或者客戶注冊期間）將用戶代理重定向回客戶。重定向URI包括一個授權(quán)碼和任何早起客戶端提供的本地狀態(tài)。（d） 客戶從授權(quán)服務器的令牌端點請求一個訪問令牌，包括在上一步中收到的授權(quán)碼。在做出請求時，客戶與授權(quán)服務器驗證。包括重定向URI 的客戶用于獲得驗證授權(quán)碼。（e） 授權(quán)服務器驗證客戶端身份，驗證授權(quán)碼，保證接收到的重定向URI與步驟（c）中用于重定向客戶端的URI向匹配。如果有效，授權(quán)服務器回復一個訪問令牌和和可選擇的刷新令牌。4.1.1 授權(quán)申請客戶端通過增加下面參數(shù)到授權(quán)端點URI的查詢組件構(gòu)造請求URI，使用application/x-www-form-urlencoded格式來構(gòu)造。Response_typeREQUIRED. 必須被賦值。Client_idREQUIRED. 客戶身份，2.2結(jié)介紹Redirect_uriOPTIONAL , 3.1.2結(jié)介紹。ScopeOPTIONAL, 訪問請求的范圍，如3.3結(jié)描述。StateRECOMMENDED, 一個不透明的值，由客戶端用來維持請求和回調(diào)狀態(tài)。當重定向用戶代理給客戶端時，授權(quán)服務器包括此值。參數(shù)應當用于防止跨站點請求偽造，如10.12結(jié)所述。Client使用一個HTTP重定向回答，或者用其它通過用戶代理的方法將資源所有者引導到構(gòu)造好的URI.例如，客戶端引導用戶代理去做如下HTTP請求，使用傳輸層安全機制：GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/1.1Host: 授權(quán)服務器驗證請求以確保所有必需的參數(shù)存在且有效。如果請求是有效的，授權(quán)服務器驗證資源的所有者，并獲得一個授權(quán)決定（通過要求資源所有者或通過其他手段建立審批）。當一個決定建立時，使用一個HTTP重定向回答，或者用其它通過用戶代理的方法將資源所有者引導到構(gòu)造好的URI.4.1.2 授權(quán)應答如果資源所有者授權(quán)給訪問請求，授權(quán)服務器發(fā)布一個授權(quán)碼然后傳送它給客戶端，授權(quán)碼是增加下面的參數(shù)到重定向URI查詢組件，使用application/x-www-form-urlencoded格式。CodeREQUIRED. 授權(quán)服務器產(chǎn)生授權(quán)碼，授權(quán)碼必須在分發(fā)后不久就到期，以減輕泄露的風險。推薦一個授權(quán)碼最大的壽命是10分鐘。Client必須不能使用授權(quán)碼超過一次。日過一個授權(quán)碼被使用超過一次，授權(quán)服務器必須拒絕請求，然后嘗試撤銷前面所有基于那個授權(quán)碼分發(fā)的令牌。授權(quán)碼是綁定到客戶標示符和重定向URI。StateREQUIRED 如果“state“參數(shù)存在于客戶端授權(quán)請求中。從客戶端收到確切的值。比如，授權(quán)服務器通過發(fā)送下面的HTTP應答來重定向用戶代理。HTTP/1.1 302 FoundLocation: /cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyzClient應該忽視不認識應答參數(shù)。授權(quán)碼字符串的大小在本規(guī)范是未定義的。Client應該避免對碼值的大小做假設。授權(quán)服務器應該將任何它發(fā)布值的大小歸檔。 錯誤應答如果由于丟失，失效，或者重定向URI不匹配而請求失敗，或者如果所提供的客戶端標示符是無效的，授權(quán)服務器應該通知資源服務器錯誤信息，一定不能自動的重定向用戶代理到無效的重定向URI。如果資源所有者拒絕訪問請求，或者如果請求失敗是有別于丟失或者無效重定向URI的原因，授權(quán)服務器通過增加下面的參數(shù)到重定向URI參訓組件，來通知client,使用application/x-www-form-urlencoded格式：errorREQUIRED 來自以下的簡單錯誤碼： invalid_request : 請求丟失了必要的參數(shù)，包括一個不被支持的參數(shù)值，或者格式不正確unauthorized_client : client 沒有用這種方法被授權(quán)去請求授權(quán)碼。access_denied ：資源所有者或者授權(quán)服務器拒絕請求。Unsupported_response_type ：資源服務器不支持用這種方法獲得一個授權(quán)碼。Invalid_scope ：請求范圍無效，位置或者不符合格式。server_error : 授權(quán)服務器遇到意外情況無法履行請求。 Temporarily_unavailable: 授權(quán)服務器由于暫時過載或者服務器維護現(xiàn)在不能處理請求。error_description OPTIONAL. 一個提供更多信息的人類可讀的UTF-8 編碼文本，用于幫助客戶端開發(fā)，使我們了解所發(fā)生的錯誤error_uri OPTIONAL 提供識別有關(guān)錯誤信息，供人參閱的網(wǎng)頁URI。提供客戶端開發(fā)和有關(guān)錯誤的其他信息state REQUIRED 如果一個有效的“state“參數(shù)存在于客戶授權(quán)請求。從客戶端接收到一個確切的值例如：授權(quán)服務器通過發(fā)送下面HTTP應帶重定向用戶代理：HTTP/1.1 302 FoundLocation: /cb?error=access_denied&state=xyz4.1.3 訪問令牌請求Client發(fā)出通過在HTTP請求實體文本中增加下面參數(shù)來請求令牌端點，使用application/x-www-form-urlencoded格式。grand_type REQUIRED. “authorization_code”必須被賦值。code REQUIRED. 從授權(quán)服務器接受的授權(quán)碼。redirect_uri REQUIRED. 如果“redirect_uri“參數(shù)被包含在授權(quán)請求中，如4.1.1所述，它的值必須相同。如果client 類型是秘密的或者client 被分發(fā)了client 憑證（或者假設另外授權(quán)求）， client 必須和授權(quán)服務器驗證身份，如 3.2.1.節(jié)所述。 例如，client 按照傳輸層安全性做出如下HTTP 請求： POST /token HTTP/1.1 Host: Authorization: BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type:application/x-www-form-urlencoded;charset=UTF-8grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb授權(quán)服務器必須：（a）請求客戶驗證秘密客戶或者每個被分發(fā)了憑證（或者其它授權(quán)需求）的用戶（b）如果client 驗證被包括就去驗證客戶端，然后確保授權(quán)碼被分發(fā)給授權(quán)client（c）確認授權(quán)碼是有效的（d）確?！皉edirect_uri”參數(shù)是存在的，如果“redirect_uri”參數(shù)被包括在初始的授權(quán)請求（4.1.1所述），如果被包含，確保他們的值是相同的。4.1.4 訪問令牌應答如果訪問令牌請求是有效的和授權(quán)的，授權(quán)服務器分發(fā)一個訪問令牌和可選的刷新令牌（5.1所述）。如果請求客戶端授權(quán)失敗或者失效，授權(quán)服務器返回一個錯誤應答，如5.2所述一個成功應答的例子：HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cacheaccess_token:2YotnFZFEjr1zCsicMWpAA,token_type:example,expires_in:3600,refresh_token:tGzv3JOkF0XG5Qx2TlKWIA,example_parameter:example_value4.2 隱式授權(quán)隱式授權(quán)類型被用來獲得訪問令牌（它不支持刷新令牌的發(fā)行），隱式授權(quán)非常適合懂得操作特定重定向URI的公共客戶端。這些客戶端通常用一個例如JavaScript的腳本語言在瀏覽器中實現(xiàn)。作為一個基于重定向的流，client必須具有與資源所有者的用戶代理（通常是一個web瀏覽器）交互的能力，還要具有從授權(quán)服務器接受向內(nèi)請求（通過重定向）的能力。不像授權(quán)碼授權(quán)類型，授權(quán)碼授權(quán)類型中，客戶端為了授權(quán)和訪問令牌做出分隔的請求，但在隱式授權(quán)中，client接受訪問令牌作為授權(quán)請求的結(jié)果。隱式授權(quán)類型不包括客戶身份驗證，它依賴于資源所有者和注冊過的重定向URI的存在。因為訪問令牌被編碼到了重定向URI，它可能被曝光給資源所有者和駐留在磁盤的應用程序。上圖包括了以下步驟：（A）client啟動流程是從引導資源所有者的用戶代理到授權(quán)端點開始的。Client包括他的客戶端標示符，請求的范圍，本地的狀態(tài)和一個重定向RUI，一旦訪問被授權(quán)（或者決絕）授權(quán)服務器將把用戶代理送回。（B）授權(quán)服務器認證資源所有者（通過用戶代理）。無論資源所有者授權(quán)或者拒絕，授權(quán)服務器建立客戶端的訪問請求。（C）假設資源所有者授權(quán)訪問，授權(quán)服務器使用早起提供的重定向URI將用戶代理重定向回client。重定向URI包含在訪問令牌的URI片段里。（D）用戶代理通過做出對web托管的客戶端資源的請求，跟著重定向的指示。客戶端保留本地的片段信息。（E）Web托管客戶端資源返回一個web頁面（通常是一個嵌入了腳本的HTML文檔），能訪問全重定向URI包括保留在用戶代理的URI，提取片段中的訪問令牌（和其它參數(shù)）（F）用戶代理在本地執(zhí)行web托管客戶端資源的腳本，提取訪問指令然后提交給client。4.2.1 授權(quán)請求Client通過增加下面的參數(shù)到授權(quán)端點URI的查詢組件來構(gòu)造請求URI，并使用application/x-www-form-urlencoded格式：Response_typeREQUIRED. “token“必須被賦值。Client_idREQUIRED. 客戶端標示符，如2.2所述。Redirect_uriOPTIONAL, 如3.1.2所述。ScopeOPTIONAL, 訪問請求的范圍，3.3節(jié)所述。stateRECOMMENDED. 客戶端的一個不透明的值用來保留請求和回叫的狀態(tài)。授權(quán)服務器包括這個值當重定向用戶代理回client時。參數(shù)應該被用于防止夸站點訪問片段。如10.12所述。Client使用一個HTTP重定向應答來引導資源所有者到構(gòu)造URI，或者通過其他方式提供給他的用戶代理。例如,client引導用戶代理使用傳輸層安全性去做出如下HTTP請求：GET/authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1Host: 授權(quán)服務器驗證請求以確保所有的必須的參數(shù)是存在的且有效地。授權(quán)服務器必須驗證重定向URI，這個URI回重定向訪問令牌與一個客戶端注冊過的重定向URI匹配。如果請求有效，授權(quán)服務器認真資源所有者，獲得一個授權(quán)決定（通過請求資源所有者或者通過其他方法建立審批）。當一個決定建立時，授權(quán)服務器定向用戶代理到提供的客戶重定向URI，這是通過一個HTTP重定向應答或者用其他方法提供給他的用戶代理。4.2.2 訪問令牌應答如果資源所有者授權(quán)一個訪問請求，授權(quán)服務器分發(fā)一個訪問令牌然后傳送它給客戶端，通過增加以下參數(shù)到重定向URI的片段組