1
美好的舊時光
我經常懷念三十年前那美好的舊時光， 工作很輕松， 生活很悠閑。
上班的時候偶爾有些HTTP的請求發到我這里， 我簡單的看一下， 取出相對應的html文檔，圖片，發回去就可以了， 然后就可以繼續喝茶聊天。
我的創造者們對我很好， 他們制定的一個簡單HTTP協議， 就是請求加響應， 尤其是我不用記住是誰剛剛發了HTTP請求， 每個請求對我來說都是全新的！
郵件服務器很羡慕我， 他說：老弟，你的生活太愜意了， 哪像我， 每次有人從客戶端訪問郵箱， 我都得專門給他建立一個會話， 來處理他發的消息， 你倒好， 完全不用管理會話。
這是由應用的特性決定的， 如果郵件服務器不管理會話， 那多個人之間的郵件消息就會完全混到一起了， 亂作一團了。
而30年前的Web 基本上就是文檔的瀏覽而已， 既然是瀏覽，我作為一個服務器， 為什么要記住誰在一段時間里都瀏覽了什么文檔呢？
2
Session
但是好日子沒持續多久， 很快大家就不滿足於靜態的Html 文檔了， 交互式的Web應用開始興起， 尤其是論壇， 在線購物等網站。
我馬上就遇到了和郵件服務器一樣的問題， 那就是必須管理會話，必須記住哪些人登錄系統， 哪些人往自己的購物車中放了商品， 也就是說我必須把每個人區分開。
這對我來說是個不小的挑戰， 由於HTTP協議的無狀態特性， 我必須加點小手段，才能完成會話管理。
我想出的辦法就是給大家發一個會話標識(session id), 說白了就是一個隨機的字符串，每個人收到的都不一樣， 每次大家向我發起HTTP請求的時候，把這個字符串給一並捎過來， 這樣我就能區分開誰是誰了。
3
沉重的負擔
大家都很高興， 可是我就不爽了。
每個人只需要保存自己的session id，而我需要保存所有人的session id ！ 如果訪問我的人多了， 就得由成千上萬，甚至幾十萬個。
這對我來說是一個巨大的開銷 ， 嚴重的限制了我的擴展能力， 比如說我用兩個機器組成了一個集群， 小F通過機器A登錄了系統， 那session id會保存在機器A上， 假設小F的下一次請求被轉發到機器B怎么辦？ 機器B可沒有小F的 session id啊。
有時候我會采用一點小伎倆： session sticky ， 就是讓小F的請求一直粘連在機器A上， 但是這也不管用， 要是機器A掛掉了， 還得轉到機器B去。
那我只好做session 的復制了， 把session id 在兩個機器之間搬來搬去， 快累死了。
后來有個叫Memcached的給我支了招： 把session id 集中存儲到一個地方， 所有的機器都來訪問這個地方的數據， 這樣一來，就不用復制了， 但是增加了單點失敗的可能性， 要是那個負責session 的機器掛了， 所有人都得重新登錄一遍， 估計得被人罵死。
我也嘗試把這個單點的機器也搞出集群，增加可靠性， 但不管如何， 這小小的session 對我來說是一個沉重的負擔。
4
時間換空間
這幾天的晚上我一直在思考， 我為什么要保存這可惡的session呢， 只讓每個客戶端去保存該多好？
可是如果我不保存這些session id , 我怎么驗證客戶端發給我的session id 的確是我生成的呢？ 如果我不去驗證，我都不知道他們是不是合法登錄的用戶， 那些不懷好意的家伙們就可以偽造session id , 為所欲為了。
嗯，對了，關鍵點就是驗證 ！
比如說， 小F已經登錄了系統， 我給他發一個令牌(token)， 里邊包含了小F的 user id， 下一次小F 再次通過Http 請求訪問我的時候， 把這個token 通過Http header 帶過來不就可以了。
不過這和session id沒有本質區別啊， 任何人都可以可以偽造， 所以我得想點兒辦法， 讓別人偽造不了。
那就對數據做一個簽名吧， 比如說我用HMAC-SHA256 算法，加上一個只有我才知道的密鑰， 對數據做一個簽名， 把這個簽名和數據一起作為token ， 由於密鑰別人不知道， 就無法偽造token了。
這個token 我不保存， 當小F把這個token 給我發過來的時候，我再用同樣的HMAC-SHA256 算法和同樣的密鑰，對數據再計算一次簽名， 和token 中的簽名做個比較， 如果相同， 我就知道小F已經登錄過了，並且可以直接取到小F的user id , 如果不相同， 數據部分肯定被人篡改過， 我就告訴發送者： 對不起，沒有認證。
Token 中的數據是明文保存的（雖然我會用Base64做下編碼， 但那不是加密）， 還是可以被別人看到的， 所以我不能在其中保存像密碼這樣的敏感信息。
當然， 如果一個人的token 被別人偷走了， 那我也沒辦法， 我也會認為小偷就是合法用戶， 這其實和一個人的session id 被別人偷走是一樣的。
這樣一來， 我就不保存session id 了， 我只是生成token , 然后驗證token ， 我用我的CPU計算時間獲取了我的session 存儲空間 ！
解除了session id這個負擔， 可以說是無事一身輕， 我的機器集群現在可以輕松地做水平擴展， 用戶訪問量增大， 直接加機器就行。 這種無狀態的感覺實在是太好了！
1. 我把密碼獻給你
小梁開發了一個“信用卡管家”的程序 ， 可以自動從郵箱中讀取信用卡相關郵件，分析、匯總，形成一個報表。
小梁找到信用卡達人張大胖試用 ： “你的信用卡那么多，看看我這個程序吧， 保准你會愛死它。”
張大胖嘗試了幾下說： “咦，你這個程序要讀取我的網易郵箱啊，那需要用戶名/密碼吧”
“是啊 ， 你把密碼告訴輸入程序不就行了， 我的程序替你加密保存，保證不會泄露。”
“得了吧你， 我可不會告訴你我的密碼， 為了方便記憶， 我的密碼都是通用的， 萬一泄露了就完蛋了”
小梁說：“這樣吧，我不保存，我就訪問郵箱的時候使用一次， 用完就扔！”
“你以為你是阿里巴巴啊， 有信用背書， 你只是個小網站， 我把密碼獻給你，總是覺得不安全。就是我信任你，別人能信任你嗎？”
小梁想想也是， 這是一個巨大的心理障礙， 每個人都要誓死捍衛自己的密碼啊。
2. Token
過了一周， 小梁興致勃勃地把張大胖拉來看“信用卡管家”的升級版。
“升級為2.0了啊， 這次不用問你要網易郵箱的用戶名和密碼了”
“那你怎么訪問我的郵箱？”
“很簡單，我提供了一個新的入口，使用網易賬號登錄， 你點了以后，其實就會重定向到網易的認證系統去登錄， 網易的認證系統會讓你輸入用戶名和密碼，並且詢問你是否允許信用卡管家訪問網易郵箱， 你確認了以后，就再次重定向到我的‘信用卡管家’網站， 同時捎帶一個‘token’ 過來， 我用這個token 就可以通過API來訪問網易郵箱了。 在這個過程中， 我根本不會接觸到你的用戶名和密碼，怎么樣， 這下滿意了吧？”
“你說得輕松， 你這個信用卡管家是個小網站，還沒有什么名氣， 網易怎么會相信你這個網站呢？”
“我當然要先在網易注冊一下啊， 他們會給我發個app_id 和app_secret， 我重定向到網易的時候需要把這個東西發過去， 這樣網易就知道是‘信用卡管家’這個應用在申請授權了。”
（點擊看大圖）
張大胖說： “ 你這重定向來重定向去的， 實際上不就是為了拿到一個token 嗎？”
“對啊，因為你不信任我的信用卡管家， 不讓它保存你的密碼，只好用token的方法了 , 它是網易認證中心頒發的，實際上就代表了你對信用卡管家訪問郵箱的授權，所以有了這個token 就可以訪問你的郵箱了”
"對了" 張大胖問題， “你為什么用Javascript的方式來讀取token啊”
“這樣我的后端服務器就不用參與了，工作都在前端搞定， 你注意到那個URL中的#號了嗎？ www.a.com/callback#token=<網易返回的token>”
張大胖說： “我知道啊，這個東西叫做hash fragment, 只會停留在瀏覽器端， 只有Javascript 能訪問它，並且它不會再次通過http request 發到別的服務器器， 我想這是為了提高安全性吧。”
小梁說： “沒錯， 那個token非常非常重要，得妥善保存，不能泄露！”
“可是在第6步通過重定向，這個token 以明文的方式發送給了我的瀏覽器， 雖然是https ，不會被別人竊取，可是瀏覽器的歷史記錄或者訪問日志中就能找到， 豈不暴露了？”
小梁說： “這個.... ， 我說你這個家伙，安全意識很強烈嘛， 讓我想想，有沒有更安全的方式。"
3. Authorization Code + Token
又過了一周，小梁成功地把信用卡管家升級為3.0.
他對張大胖說： “這次我成功地把那個非常重要的、表示授權的token 給隱藏起來了， 你要不要看看？”
“你先說說你是怎么隱藏的？”
“其實整體思路和之前的類似，只是我引入了一個叫做Authorization Code 的中間層。 當你用網易賬號登錄的時候， 網易認證中心這一次不給我直接發token,而是發一個授權碼(authorization code) , 我的信用卡管家服務器端取到這個code以后，在后台再次訪問網易認證中心， 這一次他才發給我真正的token 。 還是直接上圖吧：”
（點擊看大圖）
張大胖說： “還比較容易理解， 本質上就是你拿着這個返回的授權碼在服務器后台‘偷偷地’完成申請token 的過程， 所以token 瀏覽器端根本就接觸不到，對吧？”
“什么叫偷偷地申請token ？ 這是我信用卡管家服務器和網易之間的正常交流， 只是你看不到而已。”
“開個玩笑了， 你雖然隱藏了token,但是這個授權碼確是暴露了啊，你看第7步，我在瀏覽器中都能明文看到， 要是被誰取到， 不也是照樣能取到token嗎？”
小梁說： “我們肯定有防御措施， 比如這個授權碼和我的信用卡管家申請的app_id，app_secret關聯， 只有信用卡管家發出的token請求， 網易認證中心才認為合法； 還可以讓授權碼有時間限制，比如5分鍾失效，還有可以讓授權碼只能換一次token, 第二次就不行了。 ”
“聽起來似乎不錯， 好吧， 這次我可以放心地使用了！”
4. 后記
本文講的其實就是就是OAuth 中的三種認證方式，依次是：
1. Resource Owner Password Credentials Grant(資源所有者密碼憑據許可)
2. Implicit Grant(隱式許可)
3. Authorization Code Grant(授權碼許可)
還有一種叫做Client credentials ,用的較少，文章沒有涉及。
這些名稱有些古怪， 但是本質沒那么復雜。 在OAuth中，還有幾個術語大家可以理解下：
資源所有者 : 就是我們上文的張大胖
資源服務器 ： 即網易郵箱
客戶端: 就是上文的信用卡管家
授權服務器 ： 即上文的網易認證中心
想查看完整的OAuth 2.0協議， 可以點擊閱讀原文
https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513566&idx=1&sn=a2688cadbe9c8042ff1abbdf04a8bd5e&chksm=80d67a1db7a1f30b28b93ed2ab29edfbf982b780433e4bfd178e3cc52cb1f9100cc8f923db4f&scene=21#wechat_redirect