原帖：http://anykoro.sinaapp.com/?p=30
OAuth2.0中的關鍵性概念解釋
一、角色
OAuth定義了四種角色：
1、resource owner資源所有者
可以獲得授權去訪問受保護的資源的實體。這句很繞口，簡單來說就是資源的所有者，這個所有者是指當初上傳或生成的那個所有者，並不是指服務器的所有者。比如，anykoro在新浪微博中發了一篇微博，這個時候anykoro是resource owner，這篇微博就是resource
2、resource server資源服務器
承載受保護資源的服務器，可以接收和響應使用access token（訪問令牌）請求受保護資源。
我們繼續前面的例子，這裏新浪微博的服務器就是resource server，它提供了可以通過access token獲取anykoro所發微博的功能。如果不能提供這個功能，那麼當然也就稱不上resource server。
3、client客戶
一個產生受保護資源請求的應用，該應用代表resource owner，並且已經獲得其授權。所以其實客戶就是指前面說到的這種特性的應用，是種application。還是繼續前面的例子，現在anykoro在xxx網站，使用新浪微博賬號登陸。此時這個xxx網站就是client。anykoro是resource owner，請求資源的服務器就是resource server。這裏將這三個一起做總結，主要是因爲，爲了便於理解。
4、authorization server授權服務器
用來分發access token的服務器，主要分發給client，反過來說，就是client會向authorization server請求access token。當client獲得access token後，才能說已經驗證了resource owner，並且已經獲得其授權。
這個部分對應什麼？比如，anykoro使用新浪賬號登陸時，會出現類似下圖的情況，
點擊授權後，client就獲得了authorization code。
注意：現在來讓用戶做授權與否操作的，可不是authorization
server！！！
真正的authorization server是給client用的，anykoro是看不到的。
二、協議流
接下來讓我們看一張圖，來更好的理解四種角色間的交互作用
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
上圖代表了整個協議流程的抽象圖。它展示了整個流程，以及四個角色的作用，接下來我逐條解釋
在過程開始前，我們默認用戶已經點擊了使用OAuth登陸，比如點擊了新浪微博賬號登陸按鈕，
（A）過程：client（就是application）向resource owner請求授權。可以直接向resource owner請求，但更好的是通過authorization server作爲中間物間接獲得。
對應：client帶着owner前往sina微博的授權頁面，如果owner點擊授權，則表示允許授權，就會有下面的B過程。（如果owner沒有登錄，會有提示用戶輸入用戶名和密碼的過程）
（B）過程：client獲得了resource owner的授權認可（authorization grant），此授權認可是四種標準授權認可類型中的一種，也可以是其中一種的擴展類型（具體的可見下授權認可部分）。獲得的授權認可的類型由client請求授權所使用的函數和authorization
server支持的類型決定。
對應：跳轉回client所在的網站，這個地址往往是client設定的。比如新浪微博登陸，你點擊授權後，通常會回到登陸網站的某個特定頁面。此時網站會獲得authorization code。通常owner是不知道的。對owner來說，他只是同意授權給client，然後返回了client。
（C）過程：client提供授權認可，以請求一個access token，該token是可以被authorization server驗證的，當然，也是由authorization server提供的。
對應：這部分對owner來說也是不知道的。C過程往往是和B過程在同一處代碼中的。一般採用模擬的登錄的方式，client在後臺直接使用authorization code向authorization server請求access token。
（D）過程：authorization server驗證client，並且覈實授權認可，如果是有效，就發放access token。注意這裏是兩個驗證，1驗證client是不是被承認的（在新浪微博api中獲得的APPkey等就是用於這個的），2驗證resource owner是不是真的授權了（驗證authorization grant）。只有在都通過驗證後，纔會發放給client，access token。
對應：新浪微博的驗證服務器，當接收到client的請求後，驗證下，通過了就發放access token
（E）過程：clent提供access token給resource server驗證，判斷此client是否可以獲取受保護的資源。
對應：比如，owner在client上進行發佈新的微博，此時client就會攜帶owner要發的內容和access token等主要的信息，發送給新浪微博。又或者client獲取owner的最新微博，就直接攜帶access token，owner的用戶名等主要信息，向新浪微博請求。
（F）過程：resource server覈實access token，如果有效則響應請求。
對應：當新浪微博收到請求後，驗證這個access token是否有效，有效的話，就完成client請求的操作。
總結：
兩個驗證點：
1、authorization server：驗證client是否有資格（比如有sina微博appkey等）；驗證owner是否真授權，也即驗證authorization grant有效性
2、resource server：驗證client是否提供了有效的access token
授權認可是一種憑證，代表resource owner已授權你（client）可訪問其受保護的資源。將授權認可提供給authorization server，可以獲取access token，當然前提client本身有資格。這裏有四種基本的認可類型：
→授權碼（authorization code）
→隱式（implicit）
→用戶密碼（resource owner password credentials）
→應用憑證（client credentials）
你也可以給予以上的四種，自己擴展新的類型。
1、authorization code授權碼（主流的使用方式）
當使用authorization server作爲client和resource owne之間的中間物時，會用到授權碼。用來代替直接向resource owner直接請求授權，client會將resource owner指向一臺authorization server，在authorization server所提供的頁面上，完成相應操作後，authorization server會將resource owner指引回client，並且返回的還有authorization code。
在指引resource owner返回client並帶有authorization code之前，authorization server會驗證resource owner並獲得授權（注意這裏獲得授權的是authorization server）。因爲resource owner只是向authorization server進行授權，所以resource owner的憑證是不會共享給client的。
authorization code提供了一些重要的安全信息，比如授權給client的行爲，access token的傳輸。
這裏的access token傳輸是指，直接傳給client，而不通過resource owner的user-agent（比如瀏覽器）暴露給他人，包括resource owner本人。簡單說來就是直接給client，不會再給resource owner，access token。
實例場景：
接下來，我們模擬一個應用場景。現在你的應用，需要整合新浪微博API，現在假設已經整合完成了。對於用戶來說他的使用時如下流程，
點擊使用新浪微博賬號登陸-》跳轉到新浪微博的一個驗證頁面（authorization server）-》在登陸完成後直接返回client的頁面並傳給client相應的authorization code（HTTP header實現）-》client可以在此authorization code中獲取access token。
2、Implicit隱式
隱式授權是一個簡化了的authorization code處理流程，該流程是爲應用（client）能在瀏覽器中使用腳本語言（比如JavaScript）實現類似authorization code處理流程而特地優化的。在隱式處理流程中，authorization server不會向client發放authorization code，而是直接發放access token（以此作爲resource owner授權的結果）。此類型的授權是隱性的，不會分發中間物憑證（eg.authorization code），並且會用於獲取access token。
當分發一個隱式授權時，authorization server不會驗證client。在某些情況，client身份可以通過跳轉URI去驗證，該跳轉URI是用於向client傳遞access token。獲得的access token會暴露給resource owner或其他可以訪問resource owner的User-agent的應用。
隱式授權改進了響應性和一些client的效率（比如client是一個瀏覽器應用），這是由於其減少了爲獲得access token而進行的交互次數。但也會帶來安全性上的問題，所以可以使用authorization code的時候，是使用哪種要好好權衡。
3、Resource Owner Password Credentials用戶密碼憑證
用戶密碼憑證（比如用戶名和密碼）可以直接使用，作爲一種授權類型去獲得access token。只有在高度信任resource owner和client的時候，才應該採用憑證。（比如，設備操作系統或高特權應用），還有當其他授權認可類型（比如authorization code）不可用時才使用。
儘管此類授權類型會指引client訪問resource owner憑證，但resource owner憑證被用於一次請求並且用於交換access token。此授權類型可以消除因client希望以後使用而去保存resource owner憑證的需求，這是因爲通過使用一個長期有效的access token（或者刷新access token）就可以去交換憑證 。
4、Client Credentials應用憑證
當授權範圍限制在client控制下的受保護資源或是先前使用authorization server處理過的受保護資源時，client credentials應用憑證（或其他形式的client驗證）可以用作授權認證。應用憑證用作認證授權的典型情況是，當client代表自己的時候（即，client就是resource owner），或請求訪問基於（先前由authorization server處理過的）授權的受保護資源。
四、Access Token訪問令牌
access token是一種用於獲取受保護資源的憑證，它是一條字符串，該字符串代表authorization server分發給client的授權。對於client來說此字符串是透明的。訪問令牌根據resource owner的指示，指定了client訪問的範圍和時效，並可以被resource server和authorization server使用（也可以認爲是需要用到，幫助驗證）。
令牌將作爲一個標示符，用作獲取授權信息，或自己就以某種慣例或形式包含授權信息（比如，令牌字符串由一些數據和一個簽名組成）。
訪問令牌提供了一個抽象層，通過使用resource server可以理解的單個token去代替不同的授權結構（比如，用戶名和密碼）。此抽象使得分發訪問令牌比用於獲得令牌的授權認可有更大的限制，同時也不需要resource server理解不同的驗證方法。
根據resource server安全需要，訪問令牌可以有不同的格式，結構，和工具方法（比如加密屬性）。
五、Refresh Token可刷新令牌
可刷新令牌是用於獲得訪問令牌的憑證。可刷新令牌是由authorization server分發的，當前訪問令牌失效時，可刷新令牌可以用於獲得一個新的訪問令牌或得到一個相同使用範圍（或更小）的附加訪問令牌。（訪問令牌可能比resource owner的授權，有更少的生存時間和權限，可以認爲是小於等於關係）。分發可刷新令牌是可選的，如果authorization server分發可刷新令牌，那麼當分發access token的時候就會將可刷新令牌包括進去。
可刷新令牌是一個字符串，代表resource owner對client的授權。該字符串對client是透明的。令牌代表一個標示符，用於接收授權信息。與訪問令牌不同的是，可刷新令牌只被用於authorization server，而不會發送給resource server。發送給resource server的始終是access token。
下面看一個關於可刷新令牌的處理流程圖。
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+
Figure 2: Refreshing an Expired Access Token
該流程圖包括以下步驟：
（A）：client訪問authorization server進行驗證，通過提供提供授權認可，以請求access token。
（B）：authorization server驗證client，並且驗證授權認可（四種類型中的一種），如果有效則分發一個訪問令牌和一個可刷新令牌
（C）：通過提供access token，client可向resource server請求受保護資源
（D）：resource server驗證訪問令牌，如果有效，就響應請求
（E）: 步驟（C）和（D）重複進行，直到訪問令牌過期。如果client知道訪問令牌過期，就直接跳到步驟（G），否則它還會請求受保護資源。
（F）：由於訪問令牌失效，resource server返回無效令牌錯誤。
（G）：client請求一個新的訪問令牌，通過向authorization server提供可刷新令牌並進行驗證。對client的驗證條件是基於client的類型和authorization server的策略。
（H）：authorization server驗證client和可刷新令牌，如果有效就分發一個新的訪問令牌（你也可以再發送一個新的可刷新令牌）