JSON Web Tokens

在認(rèn)證的時(shí)候，當(dāng)用戶用他們的的憑證成功登錄以后，一個(gè)JSON Web Token將會(huì)被返回。

此后，用戶名和密碼就不再是用戶的憑證，而token是用戶用來(lái)訪問(wèn)資源的新憑證了。

你必須非常小新以防止出現(xiàn)安全問(wèn)題。一般而言，你保存令牌的時(shí)間不應(yīng)該超過(guò)你所需要它的時(shí)間。

無(wú)論何時(shí)用戶想要訪問(wèn)受保護(hù)的路由或資源的時(shí)候，用戶代理（通常是瀏覽器）都應(yīng)該帶上JWT，典型的，通常放在Authorization header中，用Bearer Schema。

header看起來(lái)應(yīng)該是這樣的：

Authorization: Bearer [token]

服務(wù)器上的受保護(hù)的路由將會(huì)檢查Authorization header中的JWT是否有效，如果有效則用戶可以訪問(wèn)受保護(hù)的資源。

如果JWT包含足夠多的必要數(shù)據(jù)，那么就可以減少對(duì)數(shù)據(jù)庫(kù)的某些查詢操作，盡管可能并不是如此。

如果token是在授權(quán)頭（Authorization header）中發(fā)送的，那么跨源資源共享（CORS）將不會(huì)成為問(wèn)題，因?yàn)樗皇褂胏ookie。

基于Token的身份認(rèn)證與基于服務(wù)器的身份認(rèn)證

基于服務(wù)器的身份認(rèn)證

在討論基于Token的身份認(rèn)證是如何工作的以及它的好處之前，我們先來(lái)看一下以前我們是怎么做的：

HTTP協(xié)議是無(wú)狀態(tài)的，也就是說(shuō)，如果我們已經(jīng)認(rèn)證了一個(gè)用戶，那么他下一次請(qǐng)求的時(shí)候，服務(wù)器不知道我是誰(shuí)，我們必須再次認(rèn)證。

傳統(tǒng)的做法是將已經(jīng)認(rèn)證過(guò)的用戶信息存儲(chǔ)在服務(wù)器上，比如Session。用戶下次請(qǐng)求的時(shí)候帶著JSessionID，然后服務(wù)器以此檢查用戶是否認(rèn)證過(guò)。

這種基于服務(wù)器的身份認(rèn)證方式存在一些問(wèn)題：

• Sessions：每次用戶認(rèn)證通過(guò)以后，服務(wù)器需要?jiǎng)?chuàng)建一條記錄保存用戶信息，通常是在內(nèi)存中，隨著認(rèn)證通過(guò)的用戶越來(lái)越多，服務(wù)器在這里的開銷就會(huì)越來(lái)越大。
• Scalability：由于Session是在內(nèi)存中的，這就帶來(lái)一些拓展性的問(wèn)題。
• CORS：當(dāng)我們想要拓展我們的應(yīng)用，讓我們的數(shù)據(jù)被多個(gè)移動(dòng)設(shè)備使用時(shí)，我們必須考慮資源共享問(wèn)題。當(dāng)時(shí)用異步請(qǐng)求調(diào)用另一個(gè)域名下的資源時(shí)，我們可能會(huì)遇到禁止請(qǐng)求的問(wèn)題和Session中保存的用戶數(shù)據(jù)不存在等問(wèn)題
• CSRF：用戶很容易收到CSRF攻擊。

基于Token的身份認(rèn)證

JWT與Session的差異/相同點(diǎn)是：它們都存儲(chǔ)用戶信息；然而Session是在服務(wù)端的，而JWT是在客戶端的。

Session存儲(chǔ)用戶信息的最大問(wèn)題在于要占用大量服務(wù)器內(nèi)存，增加服務(wù)器的開銷以及多個(gè)服務(wù)Session資源不共享問(wèn)題

而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力。

Session的狀態(tài)是存儲(chǔ)在服務(wù)端，客戶端只有JSessionId；而Token的狀態(tài)是存儲(chǔ)在客戶端。

基于Token的身份認(rèn)證是如何工作的

基于Token的身份認(rèn)證是無(wú)狀態(tài)的，服務(wù)器或者Session中不會(huì)存儲(chǔ)任何用戶信息。

沒有會(huì)話信息意味著應(yīng)用和層序可以根據(jù)需要拓展和添加更多的機(jī)器，而不必?fù)?dān)心用戶登錄的位置。

雖然這一實(shí)現(xiàn)可能會(huì)有所不同，但其主要流程如下：

• 用戶攜帶用戶名和密碼請(qǐng)求訪問(wèn)
• 服務(wù)器校驗(yàn)用戶憑據(jù)
• 應(yīng)用提供一個(gè)token給客戶端
• 客戶端存儲(chǔ)token
• 并且在隨后的每一次請(qǐng)求中都帶著它
• 服務(wù)器校驗(yàn)token并返回?cái)?shù)據(jù)

注意：

• 每一次請(qǐng)求都需要token
• token應(yīng)該放在請(qǐng)求header中
• 我們還需要將服務(wù)器設(shè)置為接受來(lái)自所有域的請(qǐng)求，用Access-Control-Allow-Origin: “*”

用Token的好處

無(wú)狀態(tài)和可拓展性

Tokens存儲(chǔ)在客戶端，完全無(wú)狀態(tài)，可拓展。我們的負(fù)載均衡器可以將用戶傳遞到任意服務(wù)器，因?yàn)樵谌魏蔚胤蕉紱]有狀態(tài)或會(huì)話信息。

安全

Token不是Cookie，每次請(qǐng)求的時(shí)候Token都會(huì)被發(fā)送。

而且，由于沒有Cookie被發(fā)送，還有助于防止CSRF攻擊。

即使在你的實(shí)現(xiàn)中將token存儲(chǔ)到客戶端的Cookie中，這個(gè)Cookie也只是一種存儲(chǔ)機(jī)制，而非身份認(rèn)證機(jī)制。

沒有基于會(huì)話的信息可以操作，因?yàn)槲覀儧]有會(huì)話。

還有一個(gè)點(diǎn)，token在一段時(shí)間以后會(huì)過(guò)期，這個(gè)時(shí)候用戶需要重新登錄。這有助于我們保持安全。

還有一個(gè)概念叫token撤銷，它允許我們根據(jù)相同的授權(quán)許可使特定的token甚至一組token無(wú)效。

JWT和OAuth的區(qū)別

OAuth2是一種授權(quán)框架，JWT是一種認(rèn)證協(xié)議。

無(wú)論使用哪種方式切記用HTTPS保證數(shù)據(jù)的安全性

OAuth2用在使用第三方賬號(hào)登錄的情況（比如weibo，qq，github登錄某個(gè)APP）。而JWT使用在前后端分離，需要將簡(jiǎn)單的對(duì)后臺(tái)的API進(jìn)行保護(hù)時(shí)使用。

到此這篇關(guān)于JWT令牌的工作原理詳解的文章就介紹到這了,更多相關(guān)JWT令牌原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論