[導讀]我想用 QQ 賬號登陸豆瓣
低并發(fā)編程戰(zhàn)略上藐視技術，戰(zhàn)術上重視技術
今天，我想登陸豆瓣，看看電影評論，陶冶陶冶情操。
但是，我從來沒注冊過豆瓣賬號，而我又懶得再注冊一個，怎么辦呢？
我打開豆瓣的官網，笑了，原來豆瓣早就為我這種懶人想到了辦法。
懶人三步
第一步：在豆瓣官網點擊用 QQ 登陸。
第二步：跳轉到 qq 登錄頁面輸入用戶名密碼，然后點授權并登錄。
第三步：跳回到豆瓣頁面，成功登錄。
太方便了！
但這短短的幾秒鐘，可不簡單，我來給你說說。
但作為一群專業(yè)的程序員，我們還應該從上帝視角來看這個過程。
第一步：在豆瓣官網點擊用 qq 登錄當你點擊用 qq 登錄的小圖標時，實際上是向豆瓣的服務器發(fā)起了一個請求。
http:// www.douban.com/leadToAuthorize
豆瓣服務器會響應一個重定向地址，指向 qq 授權登錄的頁面地址。
http:// www.qq.com/authorize
當然，這個重定向地址還附帶了一個回調地址，這是在 QQ 那邊登陸成功后需要跳回的豆瓣地址。
http://www.qq.com/authorize?
callback=www.douban.com/callback
這跳回的地址是必然的嘛，不然 QQ 怎么知道在我這邊登陸成功后我要干嘛，上桿子找人家 QQ 授權的網站那么多。
這部分的流程是黃色的這部分。
第二步：跳轉到 qq 登錄頁面輸入用戶名密碼，然后點授權并登錄上一步，瀏覽器接到重定向地址
http://www.qq.com/authorize?
callback=www.douban.com/callback
自然沒什么好說的，乖乖訪問過去。
這回訪問的就是 QQ 的頁面了。
用戶輸入 QQ 號和密碼，點擊授權并登陸，這里走 QQ 服務器自己的校驗邏輯，與豆瓣毫無關系。
若校驗成功，會響應給瀏覽器一個重定向地址
www.douban.com/callback
沒錯，就是上一步傳給 QQ 服務器的 callback 參數！
但除了這個地址外，還附上了一個 code，我們叫它授權碼。
www.douban.com/callback?code=xxx
這個 code 是豆瓣服務唯一關心的事情，至于你那邊如何校驗用戶，無所謂，只要最終能給我一個 code 碼，我就認為這個用戶在你那里登陸成功了。
這部分的流程是黃色的這部分。
第三步：跳回到豆瓣頁面，成功登錄這一步背后的過程其實是最繁瑣的，但對于用戶來說是完全感知不到的。
用戶在 QQ 登錄頁面點擊授權登陸后，就直接跳轉到豆瓣首頁了，但其實經歷了很多隱藏的過程。
首先接上一步，QQ 服務器在判斷登錄成功后，使頁面重定向到之前豆瓣發(fā)來的 callback 并附上 code 授權碼。
www.douban.com/callback?code=xxx
瀏覽器接到重定向，乖乖發(fā)起請求，此時請求的是豆瓣服務器。
豆瓣服務器收到請求后，對 QQ 服務器發(fā)起了兩次請求：
1. 用拿到的 code 去換 token2. 再用拿到的 token 換取用戶信息這個 code 和 token 都是有失效時間的，也因此保證了只要不在短時間內泄漏出去，就不會有安全風險。
拿到用戶信息之后，就返回給了瀏覽器。注意此時的瀏覽器上是豆瓣的首頁，豆瓣也因此可以將你的個人信息展示出來。
這部分的流程是黃色的這部分。
至此，整個過程結束。
這個破玩意，就叫做 OAuth 2.0 協議。
這個流程目的是讓大家從全局了解 oauth2.0 協議實際上發(fā)生了什么，并僅僅以 oauth 的其中一種模式，授權碼模式進行講解。
如想了解更多模式，以及每次的請求和響應的標準齊全的參數，推薦讀一下阮一峰的文章。
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
為啥要這么跳來跳去?
為什么，要這么麻煩呢？跳來跳去的。
其實之所以有這個協議，我總結起來有兩點原因：
懶 不信任懶是指用戶懶。
如果用戶不那么懶，直接在豆瓣上新注冊一個賬號就好了。
不信任是什么意思呢？
如果用戶信任豆瓣網站，那完全可以讓用戶在豆瓣網站輸入 QQ 的用戶名和密碼，由豆瓣傳給 QQ 服務器做校驗，并返回用戶信息。
但這是不可能的，你愿意把你的 QQ 號和密碼給豆瓣看到？
更甚者，如果 QQ 信任豆瓣，用戶也信任豆瓣，那 QQ 也可以把自己的數據庫直接拷貝給豆瓣，然后豆瓣就可以完全自己擁有一套 QQ 用戶數據了，也就可以讓用戶使用 QQ 登錄。
當然，這也是不可能的。
所以就有了 OAuth 這種協議，你進行第三方授權時（文中的QQ），用戶名和密碼是不經過目標服務器的（文中的豆瓣），這保證了授權的安全性。
第三方授權服務器只給目標服務器返回有時效性的 code 和 token，目標服務器通過這個去第三方資源服務器，換取用戶信息，這達成了拿到用戶信息的目的。
所以總的來說，oauth 協議，就是由于三者（用戶、目標、第三方）相互不信任，又想使用第三方服務器的授權功能，以及獲取第三方服務器存儲的用戶信息，而產生的一個辦法。
這個破玩意，就叫做 OAuth 2.0 協議。
哦，上面好像說過了。
了解了上述過程后，代碼自然就不難寫了。
這里我實現了一個極簡版的 oauth2.0 用于體驗這個過程，大家可以參考下。
項目結構非常簡單，只有兩個模塊，分別是豆瓣和QQ，分別啟動即可。
最終效果也非常簡單清晰，下面請忍受 low 逼的顯示效果
第一步，登陸豆瓣頁面。
第二步，使用 QQ 頁面進行授權。
第三步，授權成功跳回豆瓣首頁。
好了，關于OAuth的知識就分享到這里，歡迎點贊哦~~
今天，我想登陸豆瓣，看看電影評論，陶冶陶冶情操。
但是，我從來沒注冊過豆瓣賬號，而我又懶得再注冊一個，怎么辦呢？
我打開豆瓣的官網，笑了，原來豆瓣早就為我這種懶人想到了辦法。
懶人三步
第一步：在豆瓣官網點擊用 QQ 登陸。
第二步：跳轉到 qq 登錄頁面輸入用戶名密碼，然后點授權并登錄。
第三步：跳回到豆瓣頁面，成功登錄。
太方便了！
但這短短的幾秒鐘，可不簡單，我來給你說說。
上帝視角看發(fā)生了什么
這幾秒鐘之內發(fā)生的事情，在外行的用戶視角看來，就是在豆瓣官網上輸了個 qq 號和密碼就登錄成功了。
但作為一群專業(yè)的程序員，我們還應該從上帝視角來看這個過程。
第一步：在豆瓣官網點擊用 qq 登錄當你點擊用 qq 登錄的小圖標時，實際上是向豆瓣的服務器發(fā)起了一個請求。
http:// www.douban.com/leadToAuthorize
豆瓣服務器會響應一個重定向地址，指向 qq 授權登錄的頁面地址。
http:// www.qq.com/authorize
當然，這個重定向地址還附帶了一個回調地址，這是在 QQ 那邊登陸成功后需要跳回的豆瓣地址。
http://www.qq.com/authorize?
callback=www.douban.com/callback
這跳回的地址是必然的嘛，不然 QQ 怎么知道在我這邊登陸成功后我要干嘛，上桿子找人家 QQ 授權的網站那么多。
這部分的流程是黃色的這部分。
第二步：跳轉到 qq 登錄頁面輸入用戶名密碼，然后點授權并登錄上一步，瀏覽器接到重定向地址
http://www.qq.com/authorize?
callback=www.douban.com/callback
自然沒什么好說的，乖乖訪問過去。
這回訪問的就是 QQ 的頁面了。
用戶輸入 QQ 號和密碼，點擊授權并登陸，這里走 QQ 服務器自己的校驗邏輯，與豆瓣毫無關系。
若校驗成功，會響應給瀏覽器一個重定向地址
www.douban.com/callback
沒錯，就是上一步傳給 QQ 服務器的 callback 參數！
但除了這個地址外，還附上了一個 code，我們叫它授權碼。
www.douban.com/callback?code=xxx
這個 code 是豆瓣服務唯一關心的事情，至于你那邊如何校驗用戶，無所謂，只要最終能給我一個 code 碼，我就認為這個用戶在你那里登陸成功了。
這部分的流程是黃色的這部分。
第三步：跳回到豆瓣頁面，成功登錄這一步背后的過程其實是最繁瑣的，但對于用戶來說是完全感知不到的。
用戶在 QQ 登錄頁面點擊授權登陸后，就直接跳轉到豆瓣首頁了，但其實經歷了很多隱藏的過程。
首先接上一步，QQ 服務器在判斷登錄成功后，使頁面重定向到之前豆瓣發(fā)來的 callback 并附上 code 授權碼。
www.douban.com/callback?code=xxx
瀏覽器接到重定向，乖乖發(fā)起請求，此時請求的是豆瓣服務器。
豆瓣服務器收到請求后，對 QQ 服務器發(fā)起了兩次請求：
1. 用拿到的 code 去換 token2. 再用拿到的 token 換取用戶信息這個 code 和 token 都是有失效時間的，也因此保證了只要不在短時間內泄漏出去，就不會有安全風險。
拿到用戶信息之后，就返回給了瀏覽器。注意此時的瀏覽器上是豆瓣的首頁，豆瓣也因此可以將你的個人信息展示出來。
這部分的流程是黃色的這部分。
至此，整個過程結束。
這個破玩意，就叫做 OAuth 2.0 協議。
這個流程目的是讓大家從全局了解 oauth2.0 協議實際上發(fā)生了什么，并僅僅以 oauth 的其中一種模式，授權碼模式進行講解。
如想了解更多模式，以及每次的請求和響應的標準齊全的參數，推薦讀一下阮一峰的文章。
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
為啥要這么跳來跳去?
為什么，要這么麻煩呢？跳來跳去的。
其實之所以有這個協議，我總結起來有兩點原因：
懶 不信任懶是指用戶懶。
如果用戶不那么懶，直接在豆瓣上新注冊一個賬號就好了。
不信任是什么意思呢？
如果用戶信任豆瓣網站，那完全可以讓用戶在豆瓣網站輸入 QQ 的用戶名和密碼，由豆瓣傳給 QQ 服務器做校驗，并返回用戶信息。
但這是不可能的，你愿意把你的 QQ 號和密碼給豆瓣看到？
更甚者，如果 QQ 信任豆瓣，用戶也信任豆瓣，那 QQ 也可以把自己的數據庫直接拷貝給豆瓣，然后豆瓣就可以完全自己擁有一套 QQ 用戶數據了，也就可以讓用戶使用 QQ 登錄。
當然，這也是不可能的。
所以就有了 OAuth 這種協議，你進行第三方授權時（文中的QQ），用戶名和密碼是不經過目標服務器的（文中的豆瓣），這保證了授權的安全性。
第三方授權服務器只給目標服務器返回有時效性的 code 和 token，目標服務器通過這個去第三方資源服務器，換取用戶信息，這達成了拿到用戶信息的目的。
所以總的來說，oauth 協議，就是由于三者（用戶、目標、第三方）相互不信任，又想使用第三方服務器的授權功能，以及獲取第三方服務器存儲的用戶信息，而產生的一個辦法。
這個破玩意，就叫做 OAuth 2.0 協議。
哦，上面好像說過了。
了解了上述過程后，代碼自然就不難寫了。
這里我實現了一個極簡版的 oauth2.0 用于體驗這個過程，大家可以參考下。
項目結構非常簡單，只有兩個模塊，分別是豆瓣和QQ，分別啟動即可。
最終效果也非常簡單清晰，下面請忍受 low 逼的顯示效果
第一步，登陸豆瓣頁面。
第二步，使用 QQ 頁面進行授權。
第三步，授權成功跳回豆瓣首頁。
好了，關于OAuth的知識就分享到這里，歡迎點贊哦~~
下載文檔
