image

發(fā)展史

1椒楣、很久很久以前，Web 基本上就是文檔的瀏覽而已牡肉，既然是瀏覽捧灰，作為服務(wù)器， 不需要記錄誰在某一段時(shí)間里都瀏覽了什么文檔统锤，每次請求都是一個(gè)新的 HTTP 協(xié)議毛俏，就是請求加響應(yīng)，尤其是我不用記住是誰剛剛發(fā)了 HTTP 請求饲窿，每個(gè)請求對我來說都是全新的煌寇。這段時(shí)間很嗨皮

2、但是隨著交互式 Web 應(yīng)用的興起逾雄，像在線購物網(wǎng)站阀溶，需要登錄的網(wǎng)站等等，馬上就面臨一個(gè)問題嘲驾，那就是要管理會(huì)話淌哟，必須記住哪些人登錄系統(tǒng)迹卢， 哪些人往自己的購物車中放商品辽故， 也就是說我必須把每個(gè)人區(qū)分開，這就是一個(gè)不小的挑戰(zhàn)腐碱，因?yàn)?HTTP 請求是無狀態(tài)的誊垢，所以想出的辦法就是給大家發(fā)一個(gè)會(huì)話標(biāo)識(session id)掉弛，說白了就是一個(gè)隨機(jī)的字串，每個(gè)人收到的都不一樣喂走， 每次大家向我發(fā)起 HTTP 請求的時(shí)候殃饿，把這個(gè)字符串給一并捎過來，這樣我就能區(qū)分開誰是誰了芋肠。

3乎芳、這樣大家很嗨皮了，可是服務(wù)器就不嗨皮了帖池，每個(gè)人只需要保存自己的 session id奈惑，而服務(wù)器要保存所有人的 session id！如果訪問服務(wù)器多了睡汹，就得由成千上萬肴甸，甚至幾十萬個(gè)。

這對服務(wù)器說是一個(gè)巨大的開銷囚巴，嚴(yán)重的限制了服務(wù)器擴(kuò)展能力原在，比如說我用兩個(gè)機(jī)器組成了一個(gè)集群，小F通過機(jī)器 A 登錄了系統(tǒng)彤叉， 那 session id 會(huì)保存在機(jī)器A上庶柿， 假設(shè)小 F 的下一次請求被轉(zhuǎn)發(fā)到機(jī)器 B 怎么辦？機(jī)器 B 可沒有小 F 的 session id 啊姆坚。

有時(shí)候會(huì)采用一點(diǎn)小伎倆：session sticky澳泵， 就是讓小 F 的請求一直粘連在機(jī)器 A 上，但是這也不管用兼呵，要是機(jī)器 A 掛掉了兔辅， 還得轉(zhuǎn)到機(jī)器 B 去。

那只好做 session 的復(fù)制了击喂， 把 session id 在兩個(gè)機(jī)器之間搬來搬去维苔，快累死了。

image

后來有個(gè)叫 Memcached 的支了招：把 session id 集中存儲到一個(gè)地方懂昂，所有的機(jī)器都來訪問這個(gè)地方的數(shù)據(jù)介时，這樣一來，就不用復(fù)制了凌彬， 但是增加了單點(diǎn)失敗的可能性沸柔，要是那個(gè)負(fù)責(zé) session 的機(jī)器掛了， 所有人都得重新登錄一遍铲敛，估計(jì)得被人罵死褐澎。

image

也嘗試把這個(gè)單點(diǎn)的機(jī)器也搞出集群，增加可靠性伐蒋，但不管如何工三，這小小的 session 對我來說是一個(gè)沉重的負(fù)擔(dān)迁酸。

4、于是有人就一直在思考俭正，我為什么要保存這可惡的 session 呢奸鬓，只讓每個(gè)客戶端去保存該多好？

可是如果不保存這些 session id掸读， 怎么驗(yàn)證客戶端發(fā)給我的 session id 的確是我生成的呢串远？如果不去驗(yàn)證，我們都不知道他們是不是合法登錄的用戶儿惫， 那些不懷好意的家伙們就可以偽造 session id抑淫， 為所欲為了。

嗯姥闪，對了始苇，關(guān)鍵點(diǎn)就是驗(yàn)證！

比如說筐喳，小 F 已經(jīng)登錄了系統(tǒng)催式， 我給他發(fā)一個(gè)令牌(token)， 里邊包含了小 F 的 user id避归， 下一次小 F 再次通過 Http 請求訪問我的時(shí)候荣月， 把這個(gè) token 通過 Http header 帶過來不就可以了。

不過這和 session id 沒有本質(zhì)區(qū)別啊梳毙，任何人都可以可以偽造哺窄，所以我得想點(diǎn)兒辦法，讓別人偽造不了账锹。

那就對數(shù)據(jù)做一個(gè)簽名吧萌业，比如說我用 HMAC-SHA256 算法，加上一個(gè)只有我才知道的密鑰奸柬，對數(shù)據(jù)做一個(gè)簽名生年，把這個(gè)簽名和數(shù)據(jù)一起作為 token，由于密鑰別人不知道廓奕，就無法偽造 token 了抱婉。

image

這個(gè) token 我不保存， 當(dāng)小 F 把這個(gè) token 給我發(fā)過來的時(shí)候桌粉，我再用同樣的 HMAC-SHA256 算法和同樣的密鑰蒸绩，對數(shù)據(jù)再計(jì)算一次簽名， 和 token 中的簽名做個(gè)比較铃肯，如果相同患亿，我就知道小F已經(jīng)登錄過了，并且可以直接取到小F的user id, 如果不相同缘薛， 數(shù)據(jù)部分肯定被人篡改過窍育， 我就告訴發(fā)送者：對不起，沒有認(rèn)證宴胧。

image

Token 中的數(shù)據(jù)是明文保存的（雖然我會(huì)用Base64做下編碼漱抓， 但那不是加密）， 還是可以被別人看到的恕齐， 所以我不能在其中保存像密碼這樣的敏感信息乞娄。

當(dāng)然，如果一個(gè)人的 token 被別人偷走了显歧，那我也沒辦法仪或，我也會(huì)認(rèn)為小偷就是合法用戶， 這其實(shí)和一個(gè)人的 session id 被別人偷走是一樣的士骤。

這樣一來范删，我就不保存 session id了， 我只是生成 token, 然后驗(yàn)證 token拷肌，我用我的 CPU 計(jì)算時(shí)間獲取了我的 session 存儲空間到旦！

解除了 session id 這個(gè)負(fù)擔(dān)，可以說是無事一身輕巨缘，我的機(jī)器集群現(xiàn)在可以輕松地做水平擴(kuò)展添忘，用戶訪問量增大，直接加機(jī)器就行若锁。這種無狀態(tài)的感覺實(shí)在是太好了搁骑！

Cookie

cookie 是一個(gè)非常具體的東西，指的就是瀏覽器里面能永久存儲的一種數(shù)據(jù)又固，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲功能仲器。

cookie 由服務(wù)器生成，發(fā)送給瀏覽器仰冠，瀏覽器把 cookie 以 kv 形式保存到某個(gè)目錄下的文本文件內(nèi)娄周，下一次請求同一網(wǎng)站時(shí)會(huì)把該 cookie 發(fā)送給服務(wù)器。由于 cookie 是存在客戶端上的沪停，所以瀏覽器加入了一些限制確保 cookie 不會(huì)被惡意使用煤辨，同時(shí)不會(huì)占據(jù)太多磁盤空間，所以每個(gè)域的 cookie 數(shù)量是有限的木张。

Session

session 從字面上講众辨，就是會(huì)話。這個(gè)就類似于你和一個(gè)人交談舷礼，你怎么知道當(dāng)前和你交談的是張三而不是李四呢鹃彻？對方肯定有某種特征（長相等）表明他就是張三。

session 也是類似的道理妻献，服務(wù)器要知道當(dāng)前發(fā)請求給自己的是誰蛛株。為了做這種區(qū)分团赁，服務(wù)器就要給每個(gè)客戶端分配不同的“身份標(biāo)識”，然后客戶端每次向服務(wù)器發(fā)請求的時(shí)候谨履，都帶上這個(gè)“身份標(biāo)識”欢摄，服務(wù)器就知道這個(gè)請求來自于誰了。至于客戶端怎么保存這個(gè)“身份標(biāo)識”笋粟，可以有很多種方式怀挠，對于瀏覽器客戶端，大家都默認(rèn)采用 cookie 的方式害捕。

服務(wù)器使用 session 把用戶的信息臨時(shí)保存在了服務(wù)器上绿淋，用戶離開網(wǎng)站后 session 會(huì)被銷毀。這種用戶信息存儲方式相對 cookie 來說更安全尝盼，可是 session 有一個(gè)缺陷：如果 web 服務(wù)器做了負(fù)載均衡吞滞，那么下一個(gè)操作請求到了另一臺服務(wù)器的時(shí)候 session 會(huì)丟失。

Token

在 Web 領(lǐng)域基于Token的身份驗(yàn)證隨處可見盾沫。在大多數(shù)使用Web API的互聯(lián)網(wǎng)公司中冯吓，tokens 是多用戶下處理認(rèn)證的最佳方式。

以下幾點(diǎn)特性會(huì)讓你在程序中使用基于Token的身份驗(yàn)證

1. 無狀態(tài)疮跑、可擴(kuò)展

2. 支持移動(dòng)設(shè)備

3. 跨程序調(diào)用

4. 安全

那些使用基于 Token 的身份驗(yàn)證的大佬們

大部分你見到過的 API 和 Web 應(yīng)用都使用 tokens组贺。例如 Facebook，Twitter祖娘， Google+失尖， GitHub 等。

Token 的起源

在介紹基于Token的身份驗(yàn)證的原理與優(yōu)勢之前渐苏，不妨先看看之前的認(rèn)證都是怎么做的掀潮。

基于服務(wù)器的驗(yàn)證

我們都是知道 HTTP 協(xié)議是無狀態(tài)的，這種無狀態(tài)意味著程序需要驗(yàn)證每一次請求琼富，從而辨別客戶端的身份仪吧。

在這之前，程序都是通過在服務(wù)端存儲的登錄信息來辨別請求的鞠眉。這種方式一般都是通過存儲 Session 來完成薯鼠。

下圖展示了基于服務(wù)器驗(yàn)證的原理

隨著 Web，應(yīng)用程序械蹋，已經(jīng)移動(dòng)端的興起出皇，這種驗(yàn)證的方式逐漸暴露出了問題。尤其是在可擴(kuò)展性方面哗戈。

基于服務(wù)器驗(yàn)證方式暴露的一些問題

1. Seesion：每次認(rèn)證用戶發(fā)起請求時(shí)郊艘，服務(wù)器需要去創(chuàng)建一個(gè)記錄來存儲信息。當(dāng)越來越多的用戶發(fā)請求時(shí)，內(nèi)存的開銷也會(huì)不斷增加纱注。

2. 可擴(kuò)展性：在服務(wù)端的內(nèi)存中使用 Seesion 存儲登錄信息畏浆，伴隨而來的是可擴(kuò)展性問題。

3. CORS（跨域資源共享）：當(dāng)我們需要讓數(shù)據(jù)跨多臺移動(dòng)設(shè)備上使用時(shí)狞贱，跨域資源的共享會(huì)是一個(gè)讓人頭疼的問題刻获。在使用Ajax抓取另一個(gè)域的資源，就可以會(huì)出現(xiàn)禁止請求的情況斥滤。

4. CSRF（跨站請求偽造）：用戶在訪問銀行網(wǎng)站時(shí)，他們很容易受到跨站請求偽造的攻擊勉盅，并且能夠被利用其訪問其他的網(wǎng)站佑颇。

在這些問題中，可擴(kuò)展行是最突出的草娜。因此我們有必要去尋求一種更有行之有效的方法挑胸。

基于 Token 的驗(yàn)證原理

基于 Token 的身份驗(yàn)證是無狀態(tài)的，我們不將用戶信息存在服務(wù)器或 Session 中宰闰。

這種概念解決了在服務(wù)端存儲信息時(shí)的許多問題

NoSession 意味著你的程序可以根據(jù)需要去增減機(jī)器茬贵，而不用去擔(dān)心用戶是否登錄。

基于 Token 的身份驗(yàn)證的過程如下:

1. 用戶通過用戶名和密碼發(fā)送請求移袍。

2. 程序驗(yàn)證解藻。

3. 程序返回一個(gè)簽名的token 給客戶端。

4. 客戶端儲存 token葡盗，并且每次用于每次發(fā)送請求螟左。

5. 服務(wù)端驗(yàn)證 token 并返回?cái)?shù)據(jù)。

每一次請求都需要 token觅够。token 應(yīng)該在HTTP的頭部發(fā)送從而保證了 Http 請求無狀態(tài)胶背。我們同樣通過設(shè)置服務(wù)器屬性 Access-Control-Allow-Origin: 讓服務(wù)器能接受到來自所有域的請求。需要主要的是喘先，在 ACAO 頭部標(biāo)明（designating）時(shí)钳吟，不得帶有像HTTP認(rèn)證，客戶端 SSL 證書和 cookies 的證書窘拯。

實(shí)現(xiàn)思路：

image

1. 用戶登錄校驗(yàn)红且，校驗(yàn)成功后就返回 Token 給客戶端。

2. 客戶端收到數(shù)據(jù)后保存在客戶端

3. 客戶端每次訪問 API 是攜帶 Token 到服務(wù)器端涤姊。

4. 服務(wù)器端采用 filter 過濾器校驗(yàn)直焙。校驗(yàn)成功則返回請求數(shù)據(jù)，校驗(yàn)失敗則返回錯(cuò)誤碼

當(dāng)我們在程序中認(rèn)證了信息并取得 token 之后砂轻，我們便能通過這個(gè)Token做許多的事情奔誓。

我們甚至能基于創(chuàng)建一個(gè)基于權(quán)限的 token 傳給第三方應(yīng)用程序，這些第三方程序能夠獲取到我們的數(shù)據(jù)（當(dāng)然只有在我們允許的特定的 token）。

Tokens 的優(yōu)勢 無狀態(tài)厨喂、可擴(kuò)展

在客戶端存儲的 Tokens 是無狀態(tài)的和措，并且能夠被擴(kuò)展⊥苫停基于這種無狀態(tài)和不存儲 Session 信息派阱，負(fù)載負(fù)載均衡器能夠?qū)⒂脩粜畔囊粋€(gè)服務(wù)傳到其他服務(wù)器上。

如果我們將已驗(yàn)證的用戶的信息保存在 Session 中斜纪，則每次請求都需要用戶向已驗(yàn)證的服務(wù)器發(fā)送驗(yàn)證信息（稱為 Session 親和性）贫母。用戶量大時(shí)，可能會(huì)造成 一些擁堵盒刚。

但是不要著急腺劣。使用 tokens 之后這些問題都迎刃而解，因?yàn)?tokens 自己 hold 住了用戶的驗(yàn)證信息因块。

安全性

請求中發(fā)送 token 而不再是發(fā)送 cookie 能夠防止 CSRF（跨站請求偽造）橘原。即使在客戶端使用cookie 存儲 token，cookie 也僅僅是一個(gè)存儲機(jī)制而不是用于認(rèn)證涡上。不將信息存儲在 Session 中趾断，讓我們少了對 session 操作。

token 是有時(shí)效的吩愧，一段時(shí)間之后用戶需要重新驗(yàn)證芋酌。我們也不一定需要等到token自動(dòng)失效，token 有撤回的操作雁佳，通過 token revocataion可以使一個(gè)特定的token或是一組有相同認(rèn)證的 token 無效隔嫡。

可擴(kuò)展性

Tokens 能夠創(chuàng)建與其它程序共享權(quán)限的程序。例如甘穿，能將一個(gè)隨便的社交帳號和自己的大號（Fackbook 或是 Twitter）聯(lián)系起來腮恩。當(dāng)通過服務(wù)登錄 Twitter（我們將這個(gè)過程Buffer）時(shí)，我們可以將這些 Buffer 附到 Twitter 的數(shù)據(jù)流上（we are allowing Buffer to post to our Twitter stream）温兼。

使用 tokens 時(shí)秸滴，可以提供可選的權(quán)限給第三方應(yīng)用程序。當(dāng)用戶想讓另一個(gè)應(yīng)用程序訪問它們的數(shù)據(jù)募判，我們可以通過建立自己的API荡含，得出特殊權(quán)限的tokens。

多平臺跨域

我們提前先來談?wù)撘幌?CORS(跨域資源共享)届垫，對應(yīng)用程序和服務(wù)進(jìn)行擴(kuò)展的時(shí)候释液，需要介入各種各種的設(shè)備和應(yīng)用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用戶有一個(gè)通過了驗(yàn)證的 token装处，數(shù)據(jù)和資源就能夠在任何域上被請求到误债。

Access-Control-Allow-Origin: *

基于標(biāo)準(zhǔn)

創(chuàng)建 token 的時(shí)候，你可以設(shè)定一些選項(xiàng)。我們在后續(xù)的文章中會(huì)進(jìn)行更加詳盡的描述寝蹈，但是標(biāo)準(zhǔn)的用法會(huì)在 JSON Web Tokens 體現(xiàn)李命。

最近的程序和文檔是供給 JSON Web Tokens 的。它支持眾多的語言箫老。這意味在未來的使用中你可以真正的轉(zhuǎn)換你的認(rèn)證機(jī)制封字。

轉(zhuǎn)自：https://www.cnblogs.com/moyand/p/9047978.html