OAuth是一個關於受權（authorization）的開放網絡標準，在全世界獲得普遍應用，目前的版本是2.0版。git
本文對OAuth 2.0的設計思路和運行流程，作一個簡明通俗的解釋，主要參考材料爲RFC 6749。github
1、應用場景
爲了理解OAuth的適用場合，讓我舉一個假設的例子。web
有一個"雲沖印"的網站，能夠將用戶儲存在Google的照片，沖印出來。用戶爲了使用該服務，必須讓"雲沖印"讀取本身儲存在Google上的照片。spring
問題是隻有獲得用戶的受權，Google纔會贊成"雲沖印"讀取這些照片。那麼，"雲沖印"怎樣得到用戶的受權呢？數據庫
傳統方法是，用戶將本身的Google用戶名和密碼，告訴"雲沖印"，後者就能夠讀取用戶的照片了。這樣的作法有如下幾個嚴重的缺點。json
（1）"雲沖印"爲了後續的服務，會保存用戶的密碼，這樣很不安全。api
（2）Google不得不部署密碼登陸，而咱們知道，單純的密碼登陸並不安全。
（3）"雲沖印"擁有了獲取用戶儲存在Google全部資料的權力，用戶無法限制"雲沖印"得到受權的範圍和有效期。
（4）用戶只有修改密碼，才能收回賦予"雲沖印"的權力。可是這樣作，會使得其餘全部得到用戶受權的第三方應用程序所有失效。
（5）只要有一個第三方應用程序被破解，就會致使用戶密碼泄漏，以及全部被密碼保護的數據泄漏。
OAuth就是爲了解決上面這些問題而誕生的。
2、名詞定義
在詳細講解OAuth 2.0以前，須要瞭解幾個專用名詞。它們對讀懂後面的講解，尤爲是幾張圖，相當重要。
（1） Third-party application：第三方應用程序，本文中又稱"客戶端"（client），即上一節例子中的"雲沖印"。
（2）HTTP service：HTTP服務提供商，本文中簡稱"服務提供商"，即上一節例子中的Google。
（3）Resource Owner：資源全部者，本文中又稱"用戶"（user）。
（4）User Agent：用戶代理，本文中就是指瀏覽器。
（5）Authorization server：認證服務器，即服務提供商專門用來處理認證的服務器。
（6）Resource server：資源服務器，即服務提供商存放用戶生成的資源的服務器。它與認證服務器，能夠是同一臺服務器，也能夠是不一樣的服務器。
知道了上面這些名詞，就不難理解，OAuth的做用就是讓"客戶端"安全可控地獲取"用戶"的受權，與"服務商提供商"進行互動。
3、OAuth的思路
OAuth在"客戶端"與"服務提供商"之間，設置了一個受權層（authorization layer）。"客戶端"不能直接登陸"服務提供商"，只能登陸受權層，以此將用戶與客戶端區分開來。"客戶端"登陸受權層所用的令牌（token），與用戶的密碼不一樣。用戶能夠在登陸的時候，指定受權層令牌的權限範圍和有效期。
"客戶端"登陸受權層之後，"服務提供商"根據令牌的權限範圍和有效期，向"客戶端"開放用戶儲存的資料。
4、運行流程
OAuth 2.0的運行流程以下圖，摘自RFC 6749。
（A）用戶打開客戶端之後，客戶端要求用戶給予受權。
（B）用戶贊成給予客戶端受權。
（C）客戶端使用上一步得到的受權，向認證服務器申請令牌。
（D）認證服務器對客戶端進行認證之後，確認無誤，贊成發放令牌。
（E）客戶端使用令牌，向資源服務器申請獲取資源。
（F）資源服務器確認令牌無誤，贊成向客戶端開放資源。
不難看出來，上面六個步驟之中，B是關鍵，即用戶怎樣才能給於客戶端受權。有了這個受權之後，客戶端就能夠獲取令牌，進而憑令牌獲取資源。
下面一一講解客戶端獲取受權的四種模式。
5、客戶端的受權模式
客戶端必須獲得用戶的受權（authorization grant），才能得到令牌（access token）。OAuth 2.0定義了四種受權方式。
- 受權碼模式（authorization code）
- 簡化模式（implicit）
- 密碼模式（resource owner password credentials）
- 客戶端模式（client credentials）
6、受權碼模式
受權碼模式（authorization code）是功能最完整、流程最嚴密的受權模式。它的特色就是經過客戶端的後臺服務器，與"服務提供商"的認證服務器進行互動。
它的步驟以下：
（A）用戶訪問客戶端，後者將前者導向認證服務器。
（B）用戶選擇是否給予客戶端受權。
（C）假設用戶給予受權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個受權碼。
（D）客戶端收到受權碼，附上早先的"重定向URI"，向認證服務器申請令牌。這一步是在客戶端的後臺的服務器上完成的，對用戶不可見。
（E）認證服務器覈對了受權碼和重定向URI，確認無誤後，向客戶端發送訪問令牌（access token）和更新令牌（refresh token）。
下面是上面這些步驟所須要的參數。
A步驟中，客戶端申請認證的URI，包含如下參數：
- response_type：表示受權類型，必選項，此處的值固定爲"code"
- client_id：表示客戶端的ID，必選項
- redirect_uri：表示重定向URI，可選項
- scope：表示申請的權限範圍，可選項
- state：表示客戶端的當前狀態，能夠指定任意值，認證服務器會原封不動地返回這個值。
下面是一個例子。
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
C步驟中，服務器迴應客戶端的URI，包含如下參數：
- code：表示受權碼，必選項。該碼的有效期應該很短，一般設爲10分鐘，客戶端只能使用該碼一次，不然會被受權服務器拒絕。該碼與客戶端ID和重定向URI，是一一對應關係。
- state：若是客戶端的請求中包含這個參數，認證服務器的迴應也必須如出一轍包含這個參數。
下面是一個例子。
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA &state=xyz
D步驟中，客戶端向認證服務器申請令牌的HTTP請求，包含如下參數：
- grant_type：表示使用的受權模式，必選項，此處的值固定爲"authorization_code"。
- code：表示上一步得到的受權碼，必選項。
- redirect_uri：表示重定向URI，必選項，且必須與A步驟中的該參數值保持一致。
- client_id：表示客戶端ID，必選項。
下面是一個例子。
POST /token HTTP/1.1
Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
E步驟中，認證服務器發送的HTTP回覆，包含如下參數：
- access_token：表示訪問令牌，必選項。
- token_type：表示令牌類型，該值大小寫不敏感，必選項，能夠是bearer類型或mac類型。
- expires_in：表示過時時間，單位爲秒。若是省略該參數，必須其餘方式設置過時時間。
- refresh_token：表示更新令牌，用來獲取下一次的訪問令牌，可選項。
- scope：表示權限範圍，若是與客戶端申請的範圍一致，此項可省略。
下面是一個例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
從上面代碼能夠看到，相關參數使用JSON格式發送（Content-Type: application/json）。此外，HTTP頭信息中明確指定不得緩存。
7、簡化模式
簡化模式（implicit grant type）不經過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"受權碼"這個步驟，所以得名。全部步驟在瀏覽器中完成，令牌對訪問者是可見的，且客戶端不須要認證。
它的步驟以下：
（A）客戶端將用戶導向認證服務器。
（B）用戶決定是否給於客戶端受權。
（C）假設用戶給予受權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。
（E）資源服務器返回一個網頁，其中包含的代碼能夠獲取Hash值中的令牌。
（F）瀏覽器執行上一步得到的腳本，提取出令牌。
（G）瀏覽器將令牌發給客戶端。
下面是上面這些步驟所須要的參數。
A步驟中，客戶端發出的HTTP請求，包含如下參數：
- response_type：表示受權類型，此處的值固定爲"token"，必選項。
- client_id：表示客戶端的ID，必選項。
- redirect_uri：表示重定向的URI，可選項。
- scope：表示權限範圍，可選項。
- state：表示客戶端的當前狀態，能夠指定任意值，認證服務器會原封不動地返回這個值。
下面是一個例子。
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
C步驟中，認證服務器迴應客戶端的URI，包含如下參數：
- access_token：表示訪問令牌，必選項。
- token_type：表示令牌類型，該值大小寫不敏感，必選項。
- expires_in：表示過時時間，單位爲秒。若是省略該參數，必須其餘方式設置過時時間。
- scope：表示權限範圍，若是與客戶端申請的範圍一致，此項可省略。
- state：若是客戶端的請求中包含這個參數，認證服務器的迴應也必須如出一轍包含這個參數。
下面是一個例子。
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
在上面的例子中，認證服務器用HTTP頭信息的Location欄，指定瀏覽器重定向的網址。注意，在這個網址的Hash部分包含了令牌。
根據上面的D步驟，下一步瀏覽器會訪問Location指定的網址，可是Hash部分不會發送。接下來的E步驟，服務提供商的資源服務器發送過來的代碼，會提取出Hash中的令牌。
8、密碼模式
密碼模式（Resource Owner Password Credentials Grant）中，用戶向客戶端提供本身的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要受權。
在這種模式中，用戶必須把本身的密碼給客戶端，可是客戶端不得儲存密碼。這一般用在用戶對客戶端高度信任的狀況下，好比客戶端是操做系統的一部分，或者由一個著名公司出品。而認證服務器只有在其餘受權模式沒法執行的狀況下，才能考慮使用這種模式。
它的步驟以下：
（A）用戶向客戶端提供用戶名和密碼。
（B）客戶端將用戶名和密碼發給認證服務器，向後者請求令牌。
（C）認證服務器確認無誤後，向客戶端提供訪問令牌。
B步驟中，客戶端發出的HTTP請求，包含如下參數：
- grant_type：表示受權類型，此處的值固定爲"password"，必選項。
- username：表示用戶名，必選項。
- password：表示用戶的密碼，必選項。
- scope：表示權限範圍，可選項。
下面是一個例子。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
C步驟中，認證服務器向客戶端發送訪問令牌，下面是一個例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
上面代碼中，各個參數的含義參見《受權碼模式》一節。
整個過程當中，客戶端不得保存用戶的密碼。
9、客戶端模式
客戶端模式（Client Credentials Grant）指客戶端以本身的名義，而不是以用戶的名義，向"服務提供商"進行認證。嚴格地說，客戶端模式並不屬於OAuth框架所要解決的問題。在這種模式中，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務，其實不存在受權問題。
它的步驟以下：
（A）客戶端向認證服務器進行身份認證，並要求一個訪問令牌。
（B）認證服務器確認無誤後，向客戶端提供訪問令牌。
A步驟中，客戶端發出的HTTP請求，包含如下參數：
- granttype：表示受權類型，此處的值固定爲"clientcredentials"，必選項。
- scope：表示權限範圍，可選項。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
認證服務器必須以某種方式，驗證客戶端身份。
B步驟中，認證服務器向客戶端發送訪問令牌，下面是一個例子。
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "example_parameter":"example_value" }
上面代碼中，各個參數的含義參見《受權碼模式》一節。
10、更新令牌
若是用戶訪問的時候，客戶端的"訪問令牌"已通過期，則須要使用"更新令牌"申請一個新的訪問令牌。
客戶端發出更新令牌的HTTP請求，包含如下參數：
- granttype：表示使用的受權模式，此處的值固定爲"refreshtoken"，必選項。
- refresh_token：表示早前收到的更新令牌，必選項。
- scope：表示申請的受權範圍，不能夠超出上一次申請的範圍，若是省略該參數，則表示與上一次一致。
下面是一個例子。
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
（完）
周夢康 說：
阮老師的文章都是精品，真正作到深刻淺出。
2014年5月12日 22:10 | # | 引用
hutusi 說：
留名，慢慢看~
2014年5月12日 22:58 | # | 引用
chility 說：
今天培訓老師講了這部分，剛好阮老師寫了這篇文章介紹，加深理解。
2014年5月13日 00:31 | # | 引用
phi 說：
那什麼，沒看懂。能不能用位圖。ASCII圖看的很不習慣。謝謝
2014年5月13日 01:24 | # | 引用
WhatDoesTheFoxSay 說：
受權碼模式這部分中的「E步驟中，客戶端發送的HTTP回覆，包含如下參數「這句話，是否應爲」認證服務器發送的HTTP回覆「？
2014年5月13日 05:00 | # | 引用
Charles 說：
本文關於state參數的解釋，是語焉不詳的。事實上，絕大多數的互聯網中文文檔對這個參數都語焉不詳。我想，對於形成近期互聯網上危害普遍的OAuth漏洞來講，衆多中文技術資料對這個參數解釋不到位，對這個參數的實現沒有給出清晰的指導，也是成因的一部分。原文是這麼說的：RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12.若是阮老師只是翻譯爲何「客戶端狀態」之類的話，還有什麼「能夠隨便填」，這算不上一種到位的解釋。首先，這個參數是「RECOMMENDED」，並不是什麼無關緊要的東西，事實是不少廠商都實現成了無關緊要，其次，這個參數是「SHOULD」，爲啥「SHOULD」呢，由於會引起「CSRF」。
2014年5月13日 07:41 | # | 引用
阮一峯 說：
謝謝指出，已經改過來了。
2014年5月13日 08:44 | # | 引用
Tonni 說：
阮兄的博客又更新了，前幾天買的《黑客與畫家》昨天到了，很不錯的書。
2014年5月13日 09:05 | # | 引用
YG 說：
看了這麼多OAuth的文章，阮老師的這篇是最好懂的，拜讀了
2014年5月14日 08:19 | # | 引用
M16 說：
說白了oauth就是一個網絡版的usbkey
2014年5月17日 13:50 | # | 引用
洋子 說：
支付寶連接已失效
2014年5月18日 22:56 | # | 引用
Nicole 說：
很是感謝老師的分享，收益了。。
2014年5月20日 09:13 | # | 引用
匆匆過客 說：
仔細一看，確實，若是state項不用動態數據的話會存在CSRF漏洞
2014年5月20日 09:39 | # | 引用
smilexu 說：
（E）客戶端使用令牌，向資源服務器申請獲取資源。
令牌就能夠？整個過程都沒有用戶名和密碼的得到，那資源服務器又是如何確認用戶的？
2014年5月21日 12:01 | # | 引用
萬文婷 說：
我是比較文學與世界文學的碩士生，但願您能聯繫我，探討一下卡爾維諾。
2014年5月21日 16:19 | # | 引用
niannian 說：
受權碼模式中，D步驟，文中說client_id是必選項，可是隨後的例子中沒有這項
2014年5月23日 14:12 | # | 引用
spojus 說：
收款主頁下線啦
2014年5月24日 23:01 | # | 引用
loddit 說：
同ls的niannian
另外 granttype authorizationcode 都沒加 _ 下劃線
2014年5月24日 23:20 | # | 引用
Ike 說：
話說，RFC本來就是純文字檔案，這樣的圖其實看了很親切。。。
2014年5月25日 16:14 | # | 引用
rhgb 說：
2014年6月 7日 16:47 | # | 引用
king 說：
若是客戶端作一個假的驗證受權頁面，來套取用戶，用戶名和密碼，是有可能的吧？
2014年6月12日 11:30 | # | 引用
jucelin 說：
我也有此疑問。weibo.com提供的都提示"請認準本頁URL地址必須以 api.weibo.com 開頭"，這提示基本上沒用。
2014年6月16日 20:41 | # | 引用
mll 說：
協議中的 SHOULD，應該等同於 MUST 來對待。
2014年6月19日 17:25 | # | 引用
sjh 說：
工商銀行的網銀在開通時要求用戶本身說一句話，每次使用網銀付款時網站會向用戶出示這句話以證實網站的合法性。這個感受要好些吧~
2014年7月18日 17:27 | # | 引用
lvqiuyi 說：
有兩點不太明白
1.受權碼受權裏，爲何要兩次傳遞重定向url呢？有什麼好處？
2.D步驟裏，傳遞的參數有Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW，什麼做用呢？
2014年8月 5日 11:24 | # | 引用
lvqiuyi 說：
懂了，Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW，應該是對於應用client的受權認證，這樣就至關於有兩層保護，一層是認證客戶端，一層是認證用戶，不過basic的加密方式，是否是不太安全呢？
2014年8月 5日 14:44 | # | 引用
suolaiwo 說：
請問一下，受權碼code，其做用是什麼？
2014年9月 8日 14:29 | # | 引用
guest 說：
本質的做用是避免Access Token經過URL返回，有篇視頻講這個比較詳細《[開放平臺]一步一步理解OAuth2協議-全網首發》
http://edu.51cto.com/index.php?do=course&m=addlession&course_id=2035
2014年9月16日 14:30 | # | 引用
zhiwen 說：
請問你這個是使用什麼框架實現的OAuth的相關服務器端的？
2014年9月18日 13:55 | # | 引用
陳偉 說：
正在學習OAuth2，寫得太好了！很是容易理解！
2014年10月21日 16:57 | # | 引用
hebidu 說：
我想知道 如何 生成access_token ，refresh_token 。
2014年10月22日 12:45 | # | 引用
James 說：
生成access_token ，refresh_token 很簡單,取一惟一的隨機信息再作BASE64編碼便可,它自己不包含任何有效信息的;服務端把它和用戶授權關聯以校驗其授權的有效性.
2014年10月29日 10:45 | # | 引用
惜今草 說：
請問，OAuth2.0客戶端認證模式怎麼限制客戶端到認證服務器申請權限的範圍(Scope)？
2014年11月12日 16:11 | # | 引用
yxwoods 說：
通俗易懂！感受如等到風來吹開京都霧霾，重見藍天白雲！
2014年11月13日 09:25 | # | 引用
jinlong 說：
引導用戶到受權界面，用戶會先登陸後受權，整個受權過程當中沒有提到到底是爲「誰」受權的啊？ 那token是怎麼和userid進行映射的呢？
我開始理解的是，用戶贊成受權後，會告訴受權服務器client_id等參數外還會有userid。
2014年11月21日 16:12 | # | 引用
HM 說：
阮老師爲啥只發文而不答覆上面技術性的探討呢？
2014年12月 9日 12:47 | # | 引用
feiniu5566 說：
你要知道這個受權的目的是給第三方應用受權，讓他有權利去獲取用戶放在服務器上的資源，因此你應該站在第三方應用的角度來看待這篇文章，你的目的就是獲取用戶
QQ空間裏的圖片，就這麼理解吧，差不想爲那個什麼訊發廣告
2014年12月 9日 16:31 | # | 引用
yuandghn 說：
確實是這樣的，不少時候你們都忽略了這個state參數存在的意義。企鵝家的OAuth2.0文檔裏卻是把這個參數說的很詳細(非廣告，實話實說)。
2015年1月25日 18:00 | # | 引用
smithfox 說：
密碼模式的例子中Request Header 中的 Authorization 是怎麼來的？
2015年1月28日 12:39 | # | 引用
xiaozi0lei 說：
文章寫的不錯，深刻淺出，正好在找Oauth 2.0相關的介紹文章，有幫助，多謝！
2015年3月 3日 15:49 | # | 引用
alleme 說：
確實,剛查了騰訊文檔 "state 可選 client端的狀態值。用於第三方應用防止CSRF攻擊，成功受權後回調時會原樣帶回。"
2015年3月11日 11:05 | # | 引用
Shion 說：
拿到訪問令牌（access token）後，是否是每次請求資源都必須附上訪問令牌？OAuth2是否是隻適合Http，基於OAuth2的都只能經過客戶端輪詢來獲取最新狀態而不能由服務端進行推送？
2015年4月10日 16:38 | # | 引用
test 說：
簡化模式中：
C）假設用戶給予受權，認證服務器將用戶導向客戶端指定的"重定向URI"，並在URI的Hash部分包含了訪問令牌。
（D）瀏覽器向資源服務器發出請求，其中不包括上一步收到的Hash值。
（E）資源服務器返回一個網頁，其中包含的代碼能夠獲取Hash值中的令牌。
c處的hash有沒有多餘呢？謝謝
2015年4月14日 08:21 | # | 引用
許廣輝 說：
每次看到你這兒，東西就看明白了，簡單清晰
2015年4月16日 15:52 | # | 引用
shengzhao 說：
具體的參考實現: http://git.oschina.net/shengzhao/spring-oauth-server
整合Spring Security與Oauth2 的完整代碼.
2015年4月20日 15:00 | # | 引用
song 說：
描述的很好，不錯。多謝了！
2015年5月13日 17:46 | # | 引用
小正 說：
首先謝謝阮老師，學習了，我想問下token存在數據庫仍是session裏好呢
存數據庫是否是存一個過時時間(或者之類的)，還有若是用戶操做了，這個token就延長時間仍是固定死的(幾個小時就幾小時幾天就幾天)以後過時再用refresh取
2015年6月 3日 15:18 | # | 引用
小正 說：
我查了一些資料，基本捋順了
2015年6月 4日 09:37 | # | 引用
楊鵬 說：
感謝分享！
2015年7月18日 09:49 | # | 引用
小超人 說：
受權碼模式,爲何不能經過一次請求獲取訪問令牌?爲何非要加上一次受權碼請求呢?如今受權碼的做用是指定訪問範圍,那爲何不能夠把訪問範圍做爲參數傳給認證服務器經過一次請求獲取訪問令牌呢?
2015年7月20日 10:09 | # | 引用
小超人 說：
受權碼模式比簡化模式好在哪裏呢?求路過大神指點
2015年7月20日 10:19 | # | 引用
小超人 說：
2015年7月20日 10:23 | # | 引用
卡薩布蘭卡 說：
有一處clientcredentials，應該改成：client_credentials
2015年8月 3日 16:58 | # | 引用
newnius 說：
這個token能夠是唯一的，也就是說，token惟一肯定一個用戶，像@feiniu5566 說的，客戶端能夠經過令牌請求用戶信息，包括userid，因此沒有必要額外發送。
2015年8月13日 17:35 | # | 引用
williamwue 說：
寫得十分清楚明白，多謝博主！
2015年8月19日 16:20 | # | 引用
helm 說：
阮老師，受權碼模式中A步驟中的redirect_uri寫的是可選項，D步驟說的是必選項，這裏是否是有矛盾
2015年8月22日 12:15 | # | 引用
damon 說：
大學的時候接觸淘寶API，也碰到：受權碼模式， 可是知道看了這篇文章才系統的理解。。
謝了！
2015年9月15日 18:01 | # | 引用
xiaoC 說：
最近在搞第三方登入，雖然已經按文檔弄好了，可是並不懂OAuth爲什麼物，看了樓主介紹總結，非常詳細，多謝樓主
2015年9月20日 01:27 | # | 引用
我愛demo 說：
最近要弄這個， 雖然幾天了仍是沒什麼進度，不過看了這篇文章感受很詳細，雖然並不懂。
2015年10月 6日 16:35 | # | 引用
aehyok 說：
灰常好，學到了不少，謝謝大拿
2015年10月10日 15:22 | # | 引用
分崩離析 說：
令牌就能夠表明用戶，資源服務器只負責提供資源
2015年11月 4日 10:39 | # | 引用
陳柏成 說：
（C）假設用戶給予受權，認證服務器將用戶導向客戶端事先指定的"重定向URI"（redirection URI），同時附上一個受權碼。
我不明白這個URI是用來跳轉到認證服務器的url 仍是指向前面例子說的雲沖印的圖片 謝謝了^^
2015年11月16日 11:40 | # | 引用
h 說：
這個令牌是一個字符串，資源服務器如何鑑別這個字符串不是僞造的呢？須要資源服務器到認證服務器上去鑑別嗎，仍是兩邊約定一種鑑別機制(好比鑑別RMB同樣)
2015年12月16日 10:08 | # | 引用
h 說：
看了 RFC 文檔
http://tools.ietf.org/html/rfc6749
明白了，仍是須要在 AS 和 RS 之間有個交互。
7. Accessing Protected Resources
The client accesses protected resources by presenting the access
token to the resource server. The resource server MUST validate the
access token and ensure that it has not expired and that its scope
covers the requested resource. The methods used by the resource
server to validate the access token (as well as any error responses)
are beyond the scope of this specification but generally involve an
interaction or coordination between the resource server and the
authorization server.
2015年12月16日 11:42 | # | 引用
h 說：
http://tools.ietf.org/html/rfc6749
Accessing Protected Resources
The client accesses protected resources by presenting the access
token to the resource server. The resource server MUST validate the
access token and ensure that it has not expired and that its scope
covers the requested resource. The methods used by the resource
server to validate the access token (as well as any error responses)
are beyond the scope of this specification but generally involve an
interaction or coordination between the resource server and the
authorization server.
少不了 RS 到 AS 之間交互認證 access_token，這個 Oauth 沒有規定啊,能夠隨意發揮啊。
2015年12月16日 11:45 | # | 引用
興傑 說：
看了好幾回，今天終於明白第一種模式了，謝謝老師 ^^
2015年12月18日 19:00 | # | 引用
Ans 說：
不錯，好文章！
2015年12月23日 11:01 | # | 引用
Laughing_Lz 說：
restful一頭霧水，老師太深奧，仍是不懂，淚奔啊
2015年12月23日 17:56 | # | 引用
喵喵 說：
AS完成受權以後 把受權碼和state附在重定向URI以後 再把瀏覽器重定向回這個地址 redirection URI是client提供的一個地址 作這一步是爲了讓Client可以得到受權碼
2015年12月24日 10:25 | # | 引用
喵喵 說：
請教阮老師和路過大神：
我一直對implicit grant中的web-hosted client resource的做用感到疑惑
爲何須要先向web-hosted client resource請求一個包含JS代碼html 而後再用JS來讀取access_token in Fragment(Hash)最後得到access_token 爲何不直接在本地用JS代碼來讀取呢？ 我在stackoverflow上看到人說這是重定向的經常使用作法 並無涉及到安全性的考慮 可是爲何要這樣作呢？
2015年12月24日 10:36 | # | 引用
喵喵 說：
恩 先說爲何implicit grant不須要Authorization code吧 首先由於Authorization code和client secret是不會暴露給用戶的 這個是服務器與服務器之間通訊才須要的 因此implicit grant是經過user-agent（web browser）來與AS交互 你加上這兩個東西以後 仍是會暴露給用戶看到的 因此沒有必要在簡化模式中增長他的複雜性
如今回到你問的 爲何受權碼模式須要這個受權碼 固然是爲了安全性 首先在OAuth體系中access_token是做爲訪問獲取資源的惟一憑據 若是在AS受權完成以後 直接經過重定向傳回access_token 那麼HTTP 302不是安全的 Attacker有可能會獲取到access_token 可是若是隻返回Authorization code 就算別人得到了也沒什麼卵用 由於Authorization code不能獲取到資源 在client向AS請求access_token的過程當中 是經過HTTPS來保證安全的 並且得到access_token是須要client secret與Authorization code一塊兒的 Attacker知道了Authorization code但並不知道client secret 一樣也不能得到到access_token 因此client與AS是有責任保護好client secret的
得到了access_token以後 向RS發起請求 RS其實會與AS交互 來校驗access_token 因此你想直接僞造一個access_token 那也是不ok的
2015年12月24日 11:03 | # | 引用
存在感爲零的人 說：
很透徹
2015年12月24日 11:59 | # | 引用
喵喵 說：
忽然想到漏說了一塊 關於爲何不直接用HTTPS重定向回client
是由於不是全部client server都支持HTTPS~因此爲了通用性 和安全性 才衍生出來這麼一個Auth code
可是AS確定是實現HTTPS的 因此在client向AS提起request 是木有問題的~
2015年12月24日 14:54 | # | 引用
李先森 說：
不太明白 爲何使用auth_code換取access_token的時候 還要傳redirect_uri
2016年1月10日 13:39 | # | 引用
北言 說：
最近在學習oauth2,看了阮老師的文章,很透徹,明白了.
2016年2月17日 11:33 | # | 引用
見解 說：
寫的很好，有參考價值
2016年2月22日 17:37 | # | 引用
雅愛 說：
您好，想談論下，在更新資源令牌的時候爲何要使用專門的更新令牌來更新資源令牌？爲什麼不直接用資源令牌來更新資源令牌？
2016年3月25日 08:51 | # | 引用
popwar 說：
有些解釋不夠詳細，看看這個tutorial更容易理解http://tutorials.jenkov.com/oauth2/index.html
2016年4月 1日 13:40 | # | 引用
zsxkarl 說：
最近在瞭解oauth，多謝詳細講解！
2016年4月26日 21:11 | # | 引用