發(fā)展史

1柜候、很久很久以前搞动，Web 基本上就是文檔的瀏覽而已， 既然是瀏覽渣刷，作為服務(wù)器鹦肿， 不需要記錄誰(shuí)在某一段時(shí)間里都瀏覽了什么文檔，每次請(qǐng)求都是一個(gè)新的HTTP協(xié)議辅柴， 就是請(qǐng)求加響應(yīng)箩溃， 尤其是我不用記住是誰(shuí)剛剛發(fā)了HTTP請(qǐng)求， 每個(gè)請(qǐng)求對(duì)我來(lái)說(shuō)都是全新的碌嘀。這段時(shí)間很嗨皮涣旨。
2、但是隨著交互式Web應(yīng)用的興起筏餐，像在線購(gòu)物網(wǎng)站开泽，需要登錄的網(wǎng)站等等，馬上就面臨一個(gè)問(wèn)題魁瞪，那就是要管理會(huì)話穆律，必須記住哪些人登錄系統(tǒng)惠呼， 哪些人往自己的購(gòu)物車中放商品， 也就是說(shuō)我必須把每個(gè)人區(qū)分開(kāi)峦耘，這就是一個(gè)不小的挑戰(zhàn)剔蹋，因?yàn)镠TTP請(qǐng)求是無(wú)狀態(tài)的，所以想出的辦法就是給大家發(fā)一個(gè)會(huì)話標(biāo)識(shí)(session id), 說(shuō)白了就是一個(gè)隨機(jī)的字串辅髓，每個(gè)人收到的都不一樣泣崩， 每次大家向我發(fā)起HTTP請(qǐng)求的時(shí)候，把這個(gè)字符串給一并捎過(guò)來(lái)洛口， 這樣我就能區(qū)分開(kāi)誰(shuí)是誰(shuí)了
3矫付、這樣大家很嗨皮了，可是服務(wù)器就不嗨皮了第焰，每個(gè)人只需要保存自己的session id买优，而服務(wù)器要保存所有人的session id ！如果訪問(wèn)服務(wù)器多了挺举， 就得有成千上萬(wàn)杀赢，甚至幾十萬(wàn)個(gè)。
這對(duì)服務(wù)器說(shuō)是一個(gè)巨大的開(kāi)銷 湘纵， 嚴(yán)重的限制了服務(wù)器擴(kuò)展能力脂崔， 比如說(shuō)我用兩個(gè)機(jī)器組成了一個(gè)集群， 小F通過(guò)機(jī)器A登錄了系統(tǒng)梧喷， 那session id會(huì)保存在機(jī)器A上砌左， 假設(shè)小F的下一次請(qǐng)求被轉(zhuǎn)發(fā)到機(jī)器B怎么辦？機(jī)器B可沒(méi)有小F的 session id啊伤柄。
有時(shí)候會(huì)采用一點(diǎn)小伎倆： session sticky 绊困， 就是讓小F的請(qǐng)求一直粘連在機(jī)器A上文搂， 但是這也不管用适刀， 要是機(jī)器A掛掉了， 還得轉(zhuǎn)到機(jī)器B去煤蹭。
那只好做session 的復(fù)制了笔喉， 把session id 在兩個(gè)機(jī)器之間搬來(lái)搬去， 快累死了硝皂。

image.png

后來(lái)有個(gè)叫Memcached的支了招：把session id 集中存儲(chǔ)到一個(gè)地方常挚， 所有的機(jī)器都來(lái)訪問(wèn)這個(gè)地方的數(shù)據(jù)， 這樣一來(lái)稽物，就不用復(fù)制了奄毡， 但是增加了單點(diǎn)失敗的可能性， 要是那個(gè)負(fù)責(zé)session 的機(jī)器掛了贝或， 所有人都得重新登錄一遍吼过， 估計(jì)得被人罵死锐秦。

image.png

image.png

這個(gè)token 我不保存台囱， 當(dāng)小F把這個(gè)token 給我發(fā)過(guò)來(lái)的時(shí)候，我再用同樣的HMAC-SHA256 算法和同樣的密鑰读整，對(duì)數(shù)據(jù)再計(jì)算一次簽名簿训， 和token 中的簽名做個(gè)比較， 如果相同， 我就知道小F已經(jīng)登錄過(guò)了强品，并且可以直接取到小F的user id , 如果不相同豺总， 數(shù)據(jù)部分肯定被人篡改過(guò)， 我就告訴發(fā)送者：對(duì)不起择懂，沒(méi)有認(rèn)證喻喳。

image.png

Cookie

cookie 是一個(gè)非常具體的東西苇经，指的就是瀏覽器里面能永久存儲(chǔ)的一種數(shù)據(jù)赘理，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能。
cookie由服務(wù)器生成扇单，發(fā)送給瀏覽器商模，瀏覽器把cookie以kv形式保存到某個(gè)目錄下的文本文件內(nèi)，下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該cookie發(fā)送給服務(wù)器令花。由于cookie是存在客戶端上的阻桅，所以瀏覽器加入了一些限制確保cookie不會(huì)被惡意使用，同時(shí)不會(huì)占據(jù)太多磁盤(pán)空間兼都，所以每個(gè)域的cookie數(shù)量是有限的。

Session

session 從字面上講稽寒，就是會(huì)話扮碧。這個(gè)就類似于你和一個(gè)人交談，你怎么知道當(dāng)前和你交談的是張三而不是李四呢？對(duì)方肯定有某種特征（長(zhǎng)相等）表明他就是張三慎王。
session 也是類似的道理蚓土，服務(wù)器要知道當(dāng)前發(fā)請(qǐng)求給自己的是誰(shuí)。為了做這種區(qū)分赖淤，服務(wù)器就要給每個(gè)客戶端分配不同的“身份標(biāo)識(shí)”蜀漆，然后客戶端每次向服務(wù)器發(fā)請(qǐng)求的時(shí)候，都帶上這個(gè)“身份標(biāo)識(shí)”咱旱，服務(wù)器就知道這個(gè)請(qǐng)求來(lái)自于誰(shuí)了确丢。至于客戶端怎么保存這個(gè)“身份標(biāo)識(shí)”，可以有很多種方式吐限，對(duì)于瀏覽器客戶端鲜侥，大家都默認(rèn)采用 cookie 的方式。
服務(wù)器使用session把用戶的信息臨時(shí)保存在了服務(wù)器上诸典，用戶離開(kāi)網(wǎng)站后session會(huì)被銷毀描函。這種用戶信息存儲(chǔ)方式相對(duì)cookie來(lái)說(shuō)更安全，可是session有一個(gè)缺陷：如果web服務(wù)器做了負(fù)載均衡狐粱，那么下一個(gè)操作請(qǐng)求到了另一臺(tái)服務(wù)器的時(shí)候session會(huì)丟失舀寓。

Token

在Web領(lǐng)域基于Token的身份驗(yàn)證隨處可見(jiàn)。在大多數(shù)使用Web API的互聯(lián)網(wǎng)公司中肌蜻，tokens 是多用戶下處理認(rèn)證的最佳方式基公。
以下幾點(diǎn)特性會(huì)讓你在程序中使用基于Token的身份驗(yàn)證：

1. 無(wú)狀態(tài)、可擴(kuò)展
2. 支持移動(dòng)設(shè)備
3. 跨程序調(diào)用
4. 安全
   那些使用基于Token的身份驗(yàn)證的大佬們
   大部分你見(jiàn)到過(guò)的API和Web應(yīng)用都使用tokens宋欺。例如Facebook, Twitter, Google+, GitHub等轰豆。

Token的起源

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

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

我們都是知道HTTP協(xié)議是無(wú)狀態(tài)的酸休，這種無(wú)狀態(tài)意味著程序需要驗(yàn)證每一次請(qǐng)求，從而辨別客戶端的身份祷杈。
在這之前斑司，程序都是通過(guò)在服務(wù)端存儲(chǔ)的登錄信息來(lái)辨別請(qǐng)求的。這種方式一般都是通過(guò)存儲(chǔ)Session來(lái)完成但汞。
隨著Web宿刮，應(yīng)用程序，已經(jīng)移動(dòng)端的興起私蕾，這種驗(yàn)證的方式逐漸暴露出了問(wèn)題僵缺。尤其是在可擴(kuò)展性方面。

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

1. Session：每次認(rèn)證用戶發(fā)起請(qǐng)求時(shí)踩叭，服務(wù)器需要去創(chuàng)建一個(gè)記錄來(lái)存儲(chǔ)信息磕潮。當(dāng)越來(lái)越多的用戶發(fā)請(qǐng)求時(shí)翠胰，內(nèi)存的開(kāi)銷也會(huì)不斷增加。
2. 可擴(kuò)展性：在服務(wù)端的內(nèi)存中使用Session存儲(chǔ)登錄信息自脯，伴隨而來(lái)的是可擴(kuò)展性問(wèn)題之景。
3. CORS(跨域資源共享)：當(dāng)我們需要讓數(shù)據(jù)跨多臺(tái)移動(dòng)設(shè)備上使用時(shí)，跨域資源的共享會(huì)是一個(gè)讓人頭疼的問(wèn)題膏潮。在使用Ajax抓取另一個(gè)域的資源锻狗，就可以會(huì)出現(xiàn)禁止請(qǐng)求的情況。
4. CSRF(跨站請(qǐng)求偽造)：用戶在訪問(wèn)銀行網(wǎng)站時(shí)焕参，他們很容易受到跨站請(qǐng)求偽造的攻擊轻纪，并且能夠被利用其訪問(wèn)其他的網(wǎng)站。
   在這些問(wèn)題中龟糕，可擴(kuò)展性是最突出的桐磁。因此我們有必要去尋求一種更有行之有效的方法。

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

基于Token的身份驗(yàn)證是無(wú)狀態(tài)的讲岁，我們不將用戶信息存在服務(wù)器或Session中我擂。
這種概念解決了在服務(wù)端存儲(chǔ)信息時(shí)的許多問(wèn)題：

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

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

1. 用戶通過(guò)用戶名和密碼發(fā)送請(qǐng)求校摩。

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

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

4. 客戶端儲(chǔ)存token,并且每次用于每次發(fā)送請(qǐng)求衙吩。

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

   每一次請(qǐng)求都需要token溪窒。token應(yīng)該在HTTP的頭部發(fā)送從而保證了Http請(qǐng)求無(wú)狀態(tài)坤塞。我們同樣通過(guò)設(shè)置服務(wù)器屬性Access-Control-Allow-Origin:* ，讓服務(wù)器能接受到來(lái)自所有域的請(qǐng)求澈蚌。
   需要注意的是摹芙，在ACAO頭部標(biāo)明(designating)*時(shí)，不得帶有像HTTP認(rèn)證宛瞄，客戶端SSL證書(shū)和cookies的證書(shū)浮禾。

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

image.png

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

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

3. 客戶端每次訪問(wèn)API時(shí)攜帶Token到服務(wù)器端。

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

   當(dāng)我們?cè)诔绦蛑姓J(rèn)證了信息并取得token之后，我們便能通過(guò)這個(gè)Token做許多的事情轩猩。
   我們甚至能基于創(chuàng)建一個(gè)基于權(quán)限的token傳給第三方應(yīng)用程序卷扮，這些第三方程序能夠獲取到我們的數(shù)據(jù)（當(dāng)然只有在我們?cè)试S的特定的token）荡澎。

Tokens的優(yōu)勢(shì)

無(wú)狀態(tài)均践、可擴(kuò)展

在客戶端存儲(chǔ)的Tokens是無(wú)狀態(tài)的晤锹，并且能夠被擴(kuò)展⊥基于這種無(wú)狀態(tài)和不存儲(chǔ)Session信息鞭铆，負(fù)載負(fù)載均衡器能夠?qū)⒂脩粜畔囊粋€(gè)服務(wù)傳到其他服務(wù)器上。
如果我們將已驗(yàn)證的用戶的信息保存在Session中焦影，則每次請(qǐng)求都需要用戶向已驗(yàn)證的服務(wù)器發(fā)送驗(yàn)證信息(稱為Session親和性)车遂。用戶量大時(shí)，可能會(huì)造成一些擁堵斯辰。
但是不要著急舶担。使用tokens之后這些問(wèn)題都迎刃而解，因?yàn)閠okens自己hold住了用戶的驗(yàn)證信息彬呻。

安全性

請(qǐng)求中發(fā)送token而不再是發(fā)送cookie能夠防止CSRF(跨站請(qǐng)求偽造)衣陶。即使在客戶端使用cookie存儲(chǔ)token，cookie也僅僅是一個(gè)存儲(chǔ)機(jī)制而不是用于認(rèn)證闸氮。不將信息存儲(chǔ)在Session中剪况，讓我們少了對(duì)session操作。
token是有時(shí)效的蒲跨，一段時(shí)間之后用戶需要重新驗(yàn)證译断。我們也不一定需要等到token自動(dòng)失效，token有撤回的操作或悲，通過(guò)token revocataion可以使一個(gè)特定的token或是一組有相同認(rèn)證的token無(wú)效孙咪。

可擴(kuò)展性

tokens能夠創(chuàng)建與其它程序共享權(quán)限的程序。例如巡语，能將一個(gè)隨便的社交帳號(hào)和自己的大號(hào)(Fackbook或是Twitter)聯(lián)系起來(lái)翎蹈。當(dāng)通過(guò)服務(wù)登錄Twitter(我們將這個(gè)過(guò)程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)用程序訪問(wèn)它們的數(shù)據(jù)理澎，我們可以通過(guò)建立自己的API逞力，得出特殊權(quán)限的tokens。

多平臺(tái)跨域

我們提前先來(lái)談?wù)撘幌翪ORS(跨域資源共享)糠爬，對(duì)應(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è)通過(guò)了驗(yàn)證的token执隧，數(shù)據(jù)和資源就能夠在任何域上被請(qǐng)求到揩抡。

Access-Control-Allow-Origin: *      

基于標(biāo)準(zhǔn)創(chuàng)建token的時(shí)候户侥，你可以設(shè)定一些選項(xiàng)。我們?cè)诤罄m(xù)的文章中會(huì)進(jìn)行更加詳盡的描述峦嗤，但是標(biāo)準(zhǔn)的用法會(huì)在JSON Web Tokens體現(xiàn)蕊唐。
最近的程序和文檔是供給JSON Web Tokens的。它支持眾多的語(yǔ)言烁设。這意味在未來(lái)的使用中你可以真正的轉(zhuǎn)換你的認(rèn)證機(jī)制替梨。