JWT 说明
1. JSON Web Token是什么
JSON Web Token （JWT）是一個開放標準（RFC 7519），它定義了一種緊湊的、自包含的方式，用于作為 JSON 對象在各方之間安全地傳輸信息。該信息可以被驗證和信任，因為它是數(shù)字簽名的。
2. 什么時候你應該用JSON Web Token
下列場景中使用 JSON Web Token 是很有用的：
- Authorization （授權(quán)）：這是使用 JWT 的最常見場景。一旦用戶登錄，后續(xù)每個請求都將包含JWT，允許用戶訪問該令牌允許的路由、服務和資源。單點登錄是現(xiàn)在廣泛使用的JWT的一個特性，因為它的開銷很小，并且可以輕松地跨域使用。
- Information Exchange （信息交換）：對于安全的在各方之間傳輸信息而言，JSON Web Tokens 無疑是一種很好的方式。因為 JWT 可以被簽名。例如，用公鑰 / 私鑰對，你可以確定發(fā)送人就是它們所說的那個人。另外，由于簽名是使用頭和有效負載計算的，您還可以驗證內(nèi)容沒有被篡改。
3. JSON Web Token的結(jié)構(gòu)是什么樣的
JSON Web Token 由三部分組成，它們之間用圓點（.）連接。這三部分分別是：
- Header
- Payload
- Signature
因此，一個典型的JWT看起來是這個樣子的：
xxxxx.yyyyy.zzzzz
接下來，具體看一下每一部分：
- Header header 典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256 或者 RSA 等等）。
例如：
{'alg': "HS256",'typ': "JWT" }然后，用 Base64 對這個 JSON 編碼就得到 JWT 的第一部分
- Payload JWT 的第二部分是 payload，它包含聲明（要求）。聲明是關于實體(通常是用戶)和其他數(shù)據(jù)的聲明。聲明有三種類型: registered，public 和 private。
- Registered claims：這里有一組預定義的聲明，它們不是強制的，但是推薦。比如：iss (issuer)，exp (expiration time)，sub (subject)，aud (audience) 等。
- Public claims：可以隨意定義。
- Private claims：用于在同意使用它們的各方之間共享信息，并且不是注冊的或公開的聲明。 下面是一個例子：
對 payload 進行 Base64 編碼就得到 JWT 的第二部分。
注意，不要在 JWT 的 payload 或 header 中放置敏感信息，除非它們是加密的。
- Signature
為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個秘鑰，簽名算法是header中指定的那個，然對它們簽名即可。
例如：
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
簽名是用于驗證消息在傳遞過程中有沒有被更改，并且，對于使用私鑰簽名的 token，它還可以驗證 JWT 的發(fā)送方是否為它所稱的發(fā)送方。
看一張官網(wǎng)的圖就明白了：
4. JSON Web Tokens是如何工作的
在認證的時候，當用戶用他們的憑證成功登錄以后，一個 JSON Web Token 將會被返回。此后，token 就是用戶憑證了，你必須非常小心以防止出現(xiàn)安全問題。一般而言，你保存令牌的時候不應該超過你所需要它的時間。
無論何時用戶想要訪問受保護的路由或者資源的時候，用戶代理（通常是瀏覽器）都應該帶上 JWT典型的，通常放在 Authorization header 中，用 Bearer schema。
header應該看起來是這樣的：
Authorization: Bearer
服務器上的受保護的路由將會檢查 Authorization header 中的JWT是否有效，如果有效，則用戶可以訪問受保護的資源。如果 JWT 包含足夠多的必需的數(shù)據(jù)，那么就可以減少對某些操作的數(shù)據(jù)庫查詢的需要，盡管可能并不總是如此。
如果 token 是在授權(quán)頭（Authorization header）中發(fā)送的，那么跨源資源共享（CORS）將不會成為問題，因為它不使用 cookie。
5. 基于Token的身份認證 與 基于服務器的身份認證
5.1 基于服務器的身份認證
在討論基于Token的身份認證是如何工作的以及它的好處之前，我們先來看一下以前我們是怎么做的：
HTTP協(xié)議是無狀態(tài)的，也就是說，如果我們已經(jīng)認證了一個用戶，那么他下一次請求的時候，服務器不知道我是誰，我們必須再次認證
傳統(tǒng)的做法是將已經(jīng)認證過的用戶信息存儲在服務器上，比如 Session 。用戶下次請求的時候帶著 Session ID，然后服務器以此檢查用戶是否認證過。
這種基于服務器的身份認證方式存在一些問題：
- Sessions：每次用戶認證通過以后，服務器需要創(chuàng)建一條記錄保存用戶信息，通常是在內(nèi)存中，隨著認證通過的用戶越來越多，服務器的在這里的開銷就會越來越大。
- Scalability：由于 Session 是在內(nèi)存中的，這就帶來一些擴展性的問題。
- CORS：當我們想要擴展我們的應用，讓我們的數(shù)據(jù)被多個移動設備使用時，我們必須考慮跨資源共享問題。當使用 AJAX 調(diào)用從另一個域名下獲取資源時，我們可能會遇到禁止請求的問題。
- CSRF：用戶很容易受到 CSRF 攻擊。
5.2. JWT與Session的差異
相同點是，它們都是存儲用戶信息；然而，Session 是在服務器端的，而 JWT 是在客戶端的。
Session 方式存儲用戶信息的最大問題在于要占用大量服務器內(nèi)存，增加服務器的開銷。
而 JWT 方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務端的內(nèi)存壓力。
Session 的狀態(tài)是存儲在服務器端，客戶端只有session id；而 Token 的狀態(tài)是存儲在客戶端。
5.3. 基于Token的身份認證是如何工作的
基于 Token 的身份認證是無狀態(tài)的，服務器或者 Session 中不會存儲任何用戶信息。
沒有會話信息意味著應用程序可以根據(jù)需要擴展和添加更多的機器，而不必擔心用戶登錄的位置。
雖然這一實現(xiàn)可能會有所不同，但其主要流程如下：
-
用戶攜帶用戶名和密碼請求訪問。
-
服務器校驗用戶憑據(jù) 。
-
應用提供一個token給客戶端 。
-
客戶端存儲 token，并且在隨后的每一次請求中都帶著它。
-
服務器校驗 token 并返回數(shù)據(jù)。
注意：
- 每一次請求都需要 token。
- Token 應該放在請求 header 中。
- 我們還需要將服務器設置為接受來自所有域的請求，用 Access-Control-Allow-Origin: *
5.4. 用Token的好處
- 無狀態(tài)和可擴展性：Tokens 存儲在客戶端。完全無狀態(tài)，可擴展。我們的負載均衡器可以將用戶傳遞到任意服務器，因為在任何地方都沒有狀態(tài)或會話信息。
- ?安全：Token 不是 Cookie。（The token, not a cookie.）每次請求的時候 Token 都會被發(fā)送。而且，由于沒有 Cookie 被發(fā)送，還有助于防止 CSRF 攻擊。即使在你的實現(xiàn)中將 token 存儲到客戶端的Cookie 中，這個 Cookie 也只是一種存儲機制，而非身份認證機制。沒有基于會話的信息可以操作，因為我們沒有會話!
還有一點，token 在一段時間以后會過期，這個時候用戶需要重新登錄。這有助于我們保持安全。還有一個概念叫 token 撤銷，它允許我們根據(jù)相同的授權(quán)許可使特定的 token 甚至一組 token 無效。
5.5. JWT與OAuth的區(qū)別
- OAuth2 是一種授權(quán)框架 ，JWT 是一種認證協(xié)議。
- 無論使用哪種方式切記用 HTTPS 來保證數(shù)據(jù)的安全性。
- OAuth2 用在使用第三方賬號登錄的情況（比如使用 weibo，qq，github 登錄某個 app），而 JWT 是用在前后端分離，需要簡單的對后臺API進行保護時使用。
?
轉(zhuǎn)載于：https://zhuanlan.zhihu.com/p/86937325
?
（SAW：Game Over！）
總結(jié)
- 上一篇： JSON / 格式详解
- 下一篇： 网络编程模型 / Reactor