Token 是在服務(wù)端產(chǎn)生的，如果前端使用用戶名/密碼向服務(wù)端請(qǐng)求認(rèn)證，服務(wù)端認(rèn)證成功，那么在服務(wù)端會(huì)返回 Token 給前端。前端可以在每次請(qǐng)求的時(shí)候帶上 Token 證明自己的合法地位。

不久前，我在前后端分離實(shí)踐中提到了基于 Token 的認(rèn)證，現(xiàn)在我們稍稍深入一些。

通常情況下，我們?cè)谟懻撃硞€(gè)技術(shù)的時(shí)候，都是從問(wèn)題開(kāi)始。那么第一個(gè)問(wèn)題：

為什么要用 Token？

要回答這個(gè)問(wèn)題很簡(jiǎn)單，因?yàn)樗芙鉀Q問(wèn)題！

Token 能解決哪些問(wèn)題呢？有如下幾點(diǎn)：

• Token 完全由應(yīng)用管理，所以它可以避開(kāi)同源策略。
• Token 可以避免 CSRF 攻擊(http://dwz.cn/7joLzx)。
• Token 可以是無(wú)狀態(tài)的，可以在多個(gè)服務(wù)間共享。

Token 是在服務(wù)端產(chǎn)生的，如果前端使用用戶名/密碼向服務(wù)端請(qǐng)求認(rèn)證，服務(wù)端認(rèn)證成功，那么在服務(wù)端會(huì)返回 Token 給前端。

前端可以在每次請(qǐng)求的時(shí)候帶上 Token 證明自己的合法地位。如果這個(gè) Token 在服務(wù)端持久化（比如存入數(shù)據(jù)庫(kù)），那它就是一個(gè)永久的身份令牌。

于是，又一個(gè)問(wèn)題產(chǎn)生了：需要為 Token 設(shè)置有效期嗎？

需要設(shè)置有效期嗎？

對(duì)于這個(gè)問(wèn)題，我們不妨先看兩個(gè)例子：

• 登錄密碼，一般要求定期改變密碼，以防止泄漏，所以密碼是有有效期的。
• 安全證書，SSL 安全證書都有有效期，目的是為了解決吊銷的問(wèn)題，對(duì)于這個(gè)問(wèn)題的詳細(xì)情況，來(lái)看看知乎的回答(http://dwz.cn/7joMhq)。

所以無(wú)論是從安全的角度考慮，還是從吊銷的角度考慮，Token 都需要設(shè)有效期。

那么有效期多長(zhǎng)合適呢？只能說(shuō)，根據(jù)系統(tǒng)的安全需要，盡可能的短，但也不能短得離譜。

想像一下手機(jī)的自動(dòng)熄屏?xí)r間，如果設(shè)置為 10 秒鐘無(wú)操作自動(dòng)熄屏，再次點(diǎn)亮需要輸入密碼，會(huì)不會(huì)瘋？

如果你覺(jué)得不會(huì)，那就親自試一試，設(shè)置成可以設(shè)置的最短時(shí)間，堅(jiān)持一周就好（不排除有人適應(yīng)這個(gè)時(shí)間，畢竟手機(jī)廠商也是有用戶體驗(yàn)研究的）。

然后新問(wèn)題產(chǎn)生了，如果用戶在正常操作的過(guò)程中，Token 過(guò)期失效了，要求用戶重新登錄……用戶體驗(yàn)豈不是很糟糕？

為了解決在操作過(guò)程不能讓用戶感到 Token 失效這個(gè)問(wèn)題，有一種方案是在服務(wù)器端保存 Token 狀態(tài)，用戶每次操作都會(huì)自動(dòng)刷新（推遲） Token 的過(guò)期時(shí)間——Session 就是采用這種策略來(lái)保持用戶登錄狀態(tài)的。

然而仍然存在這樣一個(gè)問(wèn)題，在前后端分離、單頁(yè) App 這些情況下，每秒種可能發(fā)起很多次請(qǐng)求，每次都去刷新過(guò)期時(shí)間會(huì)產(chǎn)生非常大的代價(jià)。

如果 Token 的過(guò)期時(shí)間被持久化到數(shù)據(jù)庫(kù)或文件，代價(jià)就更大了。所以通常為了提升效率，減少消耗，會(huì)把 Token 的過(guò)期時(shí)保存在緩存或者內(nèi)存中。

還有另一種方案，使用 Refresh Token，它可以避免頻繁的讀寫操作。這種方案中，服務(wù)端不需要刷新 Token 的過(guò)期時(shí)間，一旦 Token 過(guò)期，就反饋給前端，前端使用 Refresh Token 申請(qǐng)一個(gè)全新 Token 繼續(xù)使用。

這種方案中，服務(wù)端只需要在客戶端請(qǐng)求更新 Token 的時(shí)候?qū)?Refresh Token 的有效性進(jìn)行一次檢查，大大減少了更新有效期的操作，也就避免了頻繁讀寫。

當(dāng)然 Refresh Token 也是有有效期的，但是這個(gè)有效期就可以長(zhǎng)一點(diǎn)了，比如，以天為單位的時(shí)間。

時(shí)序圖表示

使用 Token 和 Refresh Token 的時(shí)序圖如下：

登錄

業(yè)務(wù)請(qǐng)求

Token 過(guò)期，刷新 Token

上面的時(shí)序圖中并未提到 Refresh Token 過(guò)期怎么辦。不過(guò)很顯然，Refresh Token 既然已經(jīng)過(guò)期，就該要求用戶重新登錄了。

當(dāng)然還可以把這個(gè)機(jī)制設(shè)計(jì)得更復(fù)雜一些，比如，Refresh Token 每次使用的時(shí)候，都更新它的過(guò)期時(shí)間，直到與它的創(chuàng)建時(shí)間相比，已經(jīng)超過(guò)了非常長(zhǎng)的一段時(shí)間（比如三個(gè)月），這等于是在相當(dāng)長(zhǎng)一段時(shí)間內(nèi)允許 Refresh Token 自動(dòng)續(xù)期。

到目前為止，Token 都是有狀態(tài)的，即在服務(wù)端需要保存并記錄相關(guān)屬性。那說(shuō)好的無(wú)狀態(tài)呢，怎么實(shí)現(xiàn)？

無(wú)狀態(tài) Token

如果我們把所有狀態(tài)信息都附加在 Token 上，服務(wù)器就可以不保存。但是服務(wù)端仍然需要認(rèn)證 Token 有效。

不過(guò)只要服務(wù)端能確認(rèn)是自己簽發(fā)的 Token，而且其信息未被改動(dòng)過(guò)，那就可以認(rèn)為 Token 有效——“簽名”可以作此保證。

平時(shí)常說(shuō)的簽名都存在一方簽發(fā)，另一方驗(yàn)證的情況，所以要使用非對(duì)稱加密算法。

但是在這里，簽發(fā)和驗(yàn)證都是同一方，所以對(duì)稱加密算法就能達(dá)到要求，而對(duì)稱算法比非對(duì)稱算法要快得多（可達(dá)數(shù)十倍差距）。

更進(jìn)一步思考，對(duì)稱加密算法除了加密，還帶有還原加密內(nèi)容的功能，而這一功能在對(duì) Token 簽名時(shí)并無(wú)必要——既然不需要解密，摘要（散列）算法就會(huì)更快。你可以指定密碼的散列算法，自然是 HMAC。

上面說(shuō)了這么多，還需要自己去實(shí)現(xiàn)嗎？不用！JWT 已經(jīng)定義了詳細(xì)的規(guī)范，而且有各種語(yǔ)言的若干實(shí)現(xiàn)。

不過(guò)在使用無(wú)狀態(tài) Token 的時(shí)候在服務(wù)端會(huì)有一些變化，服務(wù)端雖然不保存有效的 Token 了，卻需要保存未到期卻已注銷的 Token。

如果一個(gè) Token 未到期就被用戶主動(dòng)注銷，那么服務(wù)器需要保存這個(gè)被注銷的 Token，以便下次收到使用這個(gè)仍在有效期內(nèi)的 Token 時(shí)判其無(wú)效。有沒(méi)有感到一點(diǎn)沮喪？

在前端可控的情況下（比如前端和服務(wù)端在同一個(gè)項(xiàng)目組內(nèi)），可以協(xié)商：前端一旦注銷成功，就丟掉本地保存（比如保存在內(nèi)存、Local Storage 等）的 Token 和 Refresh Token。

基于這樣的約定，服務(wù)器就可以假設(shè)收到的 Token 一定是沒(méi)注銷的（因?yàn)樽N之后前端就不會(huì)再使用了）。

如果前端不可控的情況，仍然可以進(jìn)行上面的假設(shè)，但是這種情況下，需要盡量縮短 Token 的有效期，而且必須在用戶主動(dòng)注銷的情況下讓 Refresh Token 無(wú)效。

這個(gè)操作存在一定的安全漏洞，因?yàn)橛脩魰?huì)認(rèn)為已經(jīng)注銷了，實(shí)際上在較短的一段時(shí)間內(nèi)并沒(méi)有注銷。如果應(yīng)用設(shè)計(jì)中，這點(diǎn)漏洞并不會(huì)造成什么損失，那采用這種策略就是可行的。

在使用無(wú)狀態(tài) Token 的時(shí)候，有兩點(diǎn)需要注意：

• Refresh Token 有效時(shí)間較長(zhǎng)，所以它應(yīng)該在服務(wù)器端有狀態(tài)，以增強(qiáng)安全性，確保用戶注銷時(shí)可控。
• 應(yīng)該考慮使用二次認(rèn)證來(lái)增強(qiáng)敏感操作的安全性。

到此，關(guān)于 Token 的話題似乎差不多了——然而并沒(méi)有，上面說(shuō)的只是認(rèn)證服務(wù)和業(yè)務(wù)服務(wù)集成在一起的情況，如果是分離的情況呢？

分離認(rèn)證服務(wù)

當(dāng) Token 無(wú)狀態(tài)之后，單點(diǎn)登錄就變得容易了。前端拿到一個(gè)有效的 Token，它就可以在任何同一體系的服務(wù)上認(rèn)證通過(guò)，只要它們使用同樣的密鑰和算法來(lái)認(rèn)證 Token 的有效性。就像這樣，如下圖：

當(dāng)然，如果 Token 過(guò)期了，前端仍然需要去認(rèn)證服務(wù)更新 Token：

可見(jiàn)，雖然認(rèn)證和業(yè)務(wù)分離了，實(shí)際卻并沒(méi)產(chǎn)生多大的差異。當(dāng)然，這是建立在認(rèn)證服務(wù)器信任業(yè)務(wù)服務(wù)器的前提下，因?yàn)檎J(rèn)證服務(wù)器產(chǎn)生 Token 的密鑰和業(yè)務(wù)服務(wù)器認(rèn)證 Token 的密鑰和算法相同。

換句話說(shuō)，業(yè)務(wù)服務(wù)器同樣可以創(chuàng)建有效的 Token。如果業(yè)務(wù)服務(wù)器不能被信任，該怎么辦？

不受信的業(yè)務(wù)服務(wù)器

遇到不受信的業(yè)務(wù)服務(wù)器時(shí)，很容易想到的辦法是使用不同的密鑰。認(rèn)證服務(wù)器使用密鑰 1 簽發(fā)，業(yè)務(wù)服務(wù)器使用密鑰 2 驗(yàn)證——這是典型非對(duì)稱加密簽名的應(yīng)用場(chǎng)景。

認(rèn)證服務(wù)器自己使用私鑰對(duì) Token 簽名，公開(kāi)公鑰。信任這個(gè)認(rèn)證服務(wù)器的業(yè)務(wù)服務(wù)器保存公鑰，用于驗(yàn)證簽名。

幸好，JWT 不僅可以使用 HMAC 簽名，也可以使用 RSA（一種非對(duì)稱加密算法）簽名。

不過(guò)，當(dāng)業(yè)務(wù)服務(wù)器已經(jīng)不受信任的時(shí)候，多個(gè)業(yè)務(wù)服務(wù)器之間使用相同的 Token 對(duì)用戶來(lái)說(shuō)是不安全的。

因?yàn)槿魏我粋€(gè)服務(wù)器拿到 Token 都可以仿冒用戶去另一個(gè)服務(wù)器處理業(yè)務(wù)……悲劇隨時(shí)可能發(fā)生。

為了防止這種情況發(fā)生，就需要在認(rèn)證服務(wù)器產(chǎn)生 Token 的時(shí)候，把使用該 Token 的業(yè)務(wù)服務(wù)器的信息記錄在 Token 中。

這樣當(dāng)另一個(gè)業(yè)務(wù)服務(wù)器拿到這個(gè) Token 的時(shí)候，發(fā)現(xiàn)它并不是自己應(yīng)該驗(yàn)證的 Token，就可以直接拒絕。

現(xiàn)在，認(rèn)證服務(wù)器不信任業(yè)務(wù)服務(wù)器，業(yè)務(wù)服務(wù)器相互也不信任，但前端是信任這些服務(wù)器的——如果前端不信任，就不會(huì)拿 Token 去請(qǐng)求驗(yàn)證。

那么為什么會(huì)信任？可能是因?yàn)檫@些是同一家公司或者同一個(gè)項(xiàng)目中提供的若干服務(wù)構(gòu)成的服務(wù)體系。

但是，前端信任不代表用戶信任。如果 Token 不沒(méi)有攜帶用戶隱私（比如姓名），那么用戶不會(huì)關(guān)心信任問(wèn)題。

但如果 Token 含有用戶隱私的時(shí)候，用戶得關(guān)心信任問(wèn)題了。這時(shí)候認(rèn)證服務(wù)就不得不再啰嗦一些，當(dāng)用戶請(qǐng)求 Token 的時(shí)候，問(wèn)上一句，你真的要授權(quán)給某某某業(yè)務(wù)服務(wù)嗎？

而這個(gè)“某某某”，用戶怎么知道它是不是真的“某某某”呢？用戶當(dāng)然不知道，甚至認(rèn)證服務(wù)也不知道，因?yàn)楣€已經(jīng)公開(kāi)了，任何一個(gè)業(yè)務(wù)都可以聲明自己是“某某某”。

為了得到用戶的信任，認(rèn)證服務(wù)就不得不幫助用戶來(lái)甄別業(yè)務(wù)服務(wù)。所以，認(rèn)證服器決定不公開(kāi)公鑰，而是要求業(yè)務(wù)服務(wù)先申請(qǐng)注冊(cè)并通過(guò)審核。

只有通過(guò)審核的業(yè)務(wù)服務(wù)器才能得到認(rèn)證服務(wù)為它創(chuàng)建的，僅供它使用的公鑰。如果該業(yè)務(wù)服務(wù)泄漏公鑰帶來(lái)風(fēng)險(xiǎn)，由該業(yè)務(wù)服務(wù)自行承擔(dān)?，F(xiàn)在認(rèn)證服務(wù)可以清楚的告訴用戶，“某某某”服務(wù)是什么了。

如果用戶還是不夠信任，認(rèn)證服務(wù)甚至可以問(wèn)，某某某業(yè)務(wù)服務(wù)需要請(qǐng)求  A、B、C 三項(xiàng)個(gè)人數(shù)據(jù)，其中 A 是必須的，不然它不工作，是否允許授權(quán)？如果你授權(quán)，我就把你授權(quán)的幾項(xiàng)數(shù)據(jù)加密放在 Token 中……

廢話了這么多，有沒(méi)有似曾相識(shí)……對(duì)了，這類似開(kāi)放式 API 的認(rèn)證過(guò)程。開(kāi)發(fā)式 API 多采用 OAuth 認(rèn)證，而關(guān)于 OAuth 的探討資源非常豐富，這里就不深究了。