在前後端分離開發時為什麼需要使用者認證呢？原因是由于HTTP協定是不儲存狀态的(stateless)，這意味着當我們透過帳号密碼驗證一個使用者時，當下一個request請求時它就把剛剛的資料忘了。于是我們的程式就不知道誰是誰，就要再驗證一次。是以為了保證系統安全，我們就需要驗證使用者否處于登入狀态。
傳統方式
前後端分離通過Restful API進行資料互動時，如何驗證使用者的登入資訊及權限。在原來的項目中，使用的是最傳統也是最簡單的方式，前端登入，後端根據使用者資訊生成一個
token
，并儲存這個
token
和對應的使用者id到資料庫或Session中，接着把
token
傳給使用者，存入浏覽器 cookie，之後浏覽器請求帶上這個cookie，後端根據這個cookie值來查詢使用者，驗證是否過期。
但這樣做問題就很多，如果我們的頁面出現了 XSS 漏洞，由于 cookie 可以被 JavaScript 讀取，XSS 漏洞會導緻使用者 token 洩露，而作為後端識别使用者的辨別，cookie 的洩露意味着使用者資訊不再安全。盡管我們通過轉義輸出内容，使用 CDN 等可以盡量避免 XSS 注入，但誰也不能保證在大型的項目中不會出現這個問題。
在設定 cookie 的時候，其實你還可以設定 httpOnly 以及 secure 項。設定 httpOnly 後 cookie 将不能被 JS 讀取，浏覽器會自動的把它加在請求的 header 當中，設定 secure 的話，cookie 就隻允許通過 HTTPS 傳輸。secure 選項可以過濾掉一些使用 HTTP 協定的 XSS 注入，但并不能完全阻止。
httpOnly 選項使得 JS 不能讀取到 cookie，那麼 XSS 注入的問題也基本不用擔心了。但設定 httpOnly 就帶來了另一個問題，就是很容易的被 XSRF，即跨站請求僞造。當你浏覽器開着這個頁面的時候，另一個頁面可以很容易的跨站請求這個頁面的内容。因為 cookie 預設被發了出去。
另外，如果将驗證資訊儲存在資料庫中，後端每次都需要根據
token
查出使用者
id
，這就增加了資料庫的查詢和存儲開銷。若把驗證資訊儲存在session中，有加大了伺服器端的存儲壓力。那我們可不可以不要伺服器去查詢呢？如果我們生成
token
遵循一定的規律，比如我們使用對稱加密算法來加密使用者
id
形成
token
，那麼服務端以後其實隻要解密該
token
就可以知道使用者的
id
是什麼了。不過呢，我隻是舉個例子而已，要是真這麼做，隻要你的對稱加密算法洩露了，其他人可以通過這種加密方式進行僞造
token
，那麼所有使用者資訊都不再安全了。恩，那用非對稱加密算法來做呢，其實作在有個規範就是這樣做的，就是我們接下來要介紹的 JWT。
Json Web Token（JWT）
JWT 是一個開放标準(RFC 7519)，它定義了一種用于簡潔，自包含的用于通信雙方之間以 JSON 對象的形式安全傳遞資訊的方法。JWT 可以使用 HMAC 算法或者是 RSA 的公鑰密鑰對進行簽名。它具備兩個特點：
-
簡潔(Compact)
可以通過URL, POST 參數或者在 HTTP header 發送，因為資料量小，傳輸速度快
-
自包含(Self-contained)
負載中包含了所有使用者所需要的資訊，避免了多次查詢資料庫
JWT 組成
- Header 頭部
頭部包含了兩部分，token 類型和采用的加密算法
{
"alg": "HS256",
"typ": "JWT"
}
它會使用 Base64 編碼組成 JWT 結構的第一部分,如果你使用Node.js，可以用Node.js的包base64url來得到這個字元串。
Base64是一種編碼，也就是說，它是可以被翻譯回原來的樣子來的。它并不是一種加密過程。
- Payload 負載
這部分就是我們存放資訊的地方了，你可以把使用者 ID 等資訊放在這裡，JWT 規範裡面對這部分有進行了比較詳細的介紹，常用的由 iss（簽發者），exp（過期時間），sub（面向的使用者），aud（接收方），iat（簽發時間）。
{
"iss": "lion1ou JWT",
"iat": ,
"exp": ,
"aud": "www.example.com",
"sub": "[email protected]"
}
同樣的，它會使用 Base64 編碼組成 JWT 結構的第二部分
- Signature 簽名
前面兩部分都是使用 Base64 進行編碼的，即前端可以解開知道裡面的資訊。Signature 需要使用編碼後的 header 和 payload 以及我們提供的一個密鑰，然後使用 header 中指定的簽名算法（HS256）進行簽名。簽名的作用是保證 JWT 沒有被篡改過。
三個部分通過
.
連接配接在一起就是我們的 JWT 了，它可能長這個樣子，長度貌似和你的加密算法和私鑰有關系。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJpZCI6IjU3ZmVmMTY0ZTU0YWY2NGZmYzUzZGJkNSIsInhzcmYiOiI0ZWE1YzUwOGE2NTY2ZTc2MjQwNTQzZjhmZWIwNmZkNDU3Nzc3YmUzOTU0OWM0MDE2NDM2YWZkYTY1ZDIzMzBlIiwiaWF0IjoxNDc2NDI3OTMzfQ
.
PA3QjeyZSUh7H0GfE0vJaKW4LjKJuC3dVLQiY4hii8s
其實到這一步可能就有人會想了，HTTP 請求總會帶上 token，這樣這個 token 傳來傳去占用不必要的帶寬啊。如果你這麼想了，那你可以去了解下 HTTP2，HTTP2 對頭部進行了壓縮，相信也解決了這個問題。
- 簽名的目的
最後一步簽名的過程，實際上是對頭部以及負載内容進行簽名，防止内容被竄改。如果有人對頭部以及負載的内容解碼之後進行修改，再進行編碼，最後加上之前的簽名組合形成新的JWT的話，那麼伺服器端會判斷出新的頭部和負載形成的簽名和JWT附帶上的簽名是不一樣的。如果要對新的頭部和負載進行簽名，在不知道伺服器加密時用的密鑰的話，得出來的簽名也是不一樣的。
- 資訊暴露
在這裡大家一定會問一個問題：Base64是一種編碼，是可逆的，那麼我的資訊不就被暴露了嗎？
是的。是以，在JWT中，不應該在負載裡面加入任何敏感的資料。在上面的例子中，我們傳輸的是使用者的User ID。這個值實際上不是什麼敏感内容，一般情況下被知道也是安全的。但是像密碼這樣的内容就不能被放在JWT中了。如果将使用者的密碼放在了JWT中，那麼懷有惡意的第三方通過Base64解碼就能很快地知道你的密碼了。
是以JWT适合用于向Web應用傳遞一些非敏感資訊。JWT還經常用于設計使用者認證和授權系統，甚至實作Web應用的單點登入。
JWT 使用
- 首先，前端通過Web表單将自己的使用者名和密碼發送到後端的接口。這一過程一般是一個HTTP POST請求。建議的方式是通過SSL加密的傳輸（https協定），進而避免敏感資訊被嗅探。
- 後端核對使用者名和密碼成功後，将使用者的id等其他資訊作為JWT Payload（負載），将其與頭部分别進行Base64編碼拼接後簽名，形成一個JWT。形成的JWT就是一個形同lll.zzz.xxx的字元串。
- 後端将JWT字元串作為登入成功的傳回結果傳回給前端。前端可以将傳回的結果儲存在localStorage或sessionStorage上，登出時前端删除儲存的JWT即可。
- 前端在每次請求時将JWT放入HTTP Header中的Authorization位。(解決XSS和XSRF問題)
- 後端檢查是否存在，如存在驗證JWT的有效性。例如，檢查簽名是否正确；檢查Token是否過期；檢查Token的接收方是否是自己（可選）。
- 驗證通過後後端使用JWT中包含的使用者資訊進行其他邏輯操作，傳回相應結果。
和Session方式存儲id的差異
Session方式存儲使用者id的最大弊病在于Session是存儲在伺服器端的，是以需要占用大量伺服器記憶體，對于較大型應用而言可能還要儲存許多的狀态。一般而言，大型應用還需要借助一些KV資料庫和一系列緩存機制來實作Session的存儲。
而JWT方式将使用者狀态分散到了用戶端中，可以明顯減輕服務端的記憶體壓力。除了使用者id之外，還可以存儲其他的和使用者相關的資訊，例如該使用者是否是管理者、使用者所在的分組等。雖說JWT方式讓伺服器有一些計算壓力（例如加密、編碼和解碼），但是這些壓力相比磁盤存儲而言可能就不算什麼了。具體是否采用，需要在不同場景下用資料說話。
- 單點登入
Session方式來存儲使用者id，一開始使用者的Session隻會存儲在一台伺服器上。對于有多個子域名的站點，每個子域名至少會對應一台不同的伺服器，例如：
www.taobao.com
，
nv.taobao.com
，
nz.taobao.com
，
login.taobao.com
。是以如果要實作在
login.taobao.com
登入後，在其他的子域名下依然可以取到Session，這要求我們在多台伺服器上同步Session。使用JWT的方式則沒有這個問題的存在，因為使用者的狀态已經被傳送到了用戶端。
總結
JWT的主要作用在于（一）可附帶使用者資訊，後端直接通過JWT擷取相關資訊。（二）使用本地儲存，通過HTTP Header中的Authorization位送出驗證。但其實關于JWT存放到哪裡一直有很多讨論，有人說存放到本地存儲，有人說存 cookie。個人偏向于放在本地存儲，如果你有什麼意見和看法歡迎提出。