掌握基於 JWT 實現的 Token 身份認證

引語

最近正好在獨立開發一個後臺管理系統，涉及到了基於Token的身份認證，本身邊學邊用邊作整理和總結，對基於JWT實現的Token的身份認證作一次相對比較全面的認識。

1、基於session的跨域身份驗證

Internet服務沒法與用戶身份驗證分開。通常過程以下。

1. 用戶向服務器發送用戶名和密碼。
2. 驗證服務器後，相關數據（如用戶角色，登陸時間等）將保存在當前會話中。
3. 服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie。
4. 用戶的每一個後續請求都將經過在Cookie中取出session_id傳給服務器。
5. 服務器收到session_id並對比以前保存的數據，確認用戶的身份。

這種模式最大的問題是，沒有分佈式架構，沒法支持橫向擴展。若是使用一個服務器，該模式徹底沒有問題。可是，若是它是服務器羣集或面向服務的跨域體系結構的話，則須要一個統一的session數據庫庫來保存會話數據實現共享，這樣負載均衡下的每一個服務器才能夠正確的驗證用戶身份。
例如蟲蟲舉一個實際中常見的單點登錄的需求：站點A和站點B提供同一公司的相關服務。如今要求用戶只須要登陸其中一個網站，而後它就會自動登陸到另外一個網站。怎麼作？

一種解決方案是聽過持久化session數據，寫入數據庫或文件持久層等。收到請求後，驗證服務從持久層請求數據。該解決方案的優勢在於架構清晰，而缺點是架構修改比較費勁，整個服務的驗證邏輯層都須要重寫，工做量相對較大。並且因爲依賴於持久層的數據庫或者問題系統，會有單點風險，若是持久層失敗，整個認證體系都會掛掉。

總結基於服務器驗證方式暴露的一些明顯的問題：

1. Session：每次認證用戶發起請求時，服務器須要去建立一個記錄來存儲信息。當愈來愈多的用戶發請求時，內存的開銷也會不斷增長。
2. 可擴展性：在服務端的內存中使用Seesion存儲登陸信息，伴隨而來的是可擴展性問題。
3. CORS(跨域資源共享)：當咱們須要讓數據跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另外一個域的資源，就能夠會出現禁止請求的狀況。
4. CSRF(跨站請求僞造)：用戶在訪問銀行網站時，他們很容易受到跨站請求僞造的攻擊，而且可以被利用其訪問其餘的網站。
5. 在這些問題中，可擴展行是最突出的。所以咱們有必要去尋求一種更有行之有效的方法。

基於Token認證的身份認證方案

那麼有什麼更好的方案嗎？固然有，那就是基於Token的身份認證方案。

那麼基於Token的身份驗證能夠解決哪些問題呢？

1. Token 徹底由應用管理，因此它能夠避開同源策略
2. Token 能夠避免 CSRF 攻擊
3. Token 能夠是無狀態的，能夠在多個服務間共享

基於Token認證的原理

Token 是在服務端產生的，是無狀態的，咱們不將用戶信息存在服務器或Session中。若是客戶端使用用戶名/密碼向服務端請求認證，服務端認證成功，那麼在服務端會返回 Token 給客戶端。

客戶端能夠在每次請求的時候帶上 Token 證實本身的合法地位。若是這個 Token 在服務端持久化（好比存入數據庫），那它就是一個永久的身份令牌。基於Token的身份驗證這種概念解決了在服務端存儲信息時的許多問題。NoSession意味着你的程序能夠根據須要去增減機器，而不用去擔憂用戶是否登陸。

基於Token的身份驗證的方案過程以下:

1. 用戶經過用戶名和密碼發送請求。
2. 服務端驗證。
3. 服務端返回一個簽名的token 給客戶端。
4. 客戶端儲存token,而且每次發送請求都會攜帶token。
5. 服務端驗證token並返回數據。

Token的優點

無狀態、可擴展

在客戶端存儲的Tokens是無狀態的，而且可以被擴展。基於這種無狀態和不存儲Session信息，負載負載均衡器可以將用戶信息從一個服務傳到其餘服務器上。

安全性

請求中發送token而再也不是發送cookie可以防止CSRF(跨站請求僞造)。即便在客戶端使用cookie存儲token，cookie也僅僅是一個存儲機制而不是用於認證。不將信息存儲在Session中，讓咱們少了對session操做。
Token是有時效的，一段時間以後用戶須要從新驗證。咱們也不必定須要等到token自動失效，token有撤回的操做，經過token revocataion可使一個特定的token或是一組有相同認證的token無效。

可擴展性

Tokens可以建立與其它程序共享權限的程序。例如，能將一個隨便的社交賬號和本身的大號(Fackbook或是Twitter)聯繫起來。當經過服務登陸Twitter(咱們將這個過程Buffer)時，咱們能夠將這些Buffer附到Twitter的數據流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens時，能夠提供可選的權限給第三方應用程序。當用戶想讓另外一個應用程序訪問它們的數據，咱們能夠經過創建本身的API，得出特殊權限的tokens。

多平臺跨域

咱們提早先來談論一下CORS(跨域資源共享)，對應用程序和服務進行擴展的時候，須要介入各類各類的設備和應用程序。
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.
只要用戶有一個經過了驗證的token，數據和資源就可以在任何域上被請求到。

基於標準

建立token的時候，你能夠設定一些選項。咱們在後續的文章中會進行更加詳盡的描述，可是標準的用法會在JSON Web Tokens體現。
最近的程序和文檔是供給JSON Web Tokens的。它支持衆多的語言。這意味在將來的使用中你能夠真正的轉換你的認證機制。

無狀態 Token

若是咱們把全部狀態信息都附加在 Token 上，服務器就能夠不保存。可是服務端仍然須要認證 Token 有效。不過只要服務端能確認是本身簽發的 Token，並且其信息未被改動過，那就能夠認爲 Token 有效——「簽名」能夠做此保證。平時常說的簽名都存在一方簽發，另外一方驗證的狀況，因此要使用非對稱加密算法。可是在這裏，簽發和驗證都是同一方，因此對稱加密算法就能達到要求，而對稱算法比非對稱算法要快得多（可達數十倍差距）。更進一步思考，對稱加密算法除了加密，還帶有還原加密內容的功能，而這一功能在對 Token 簽名時並沒有必要——既然不須要解密，摘要（散列）算法就會更快。能夠指定密碼的散列算法，天然是 HMAC。

上面說了這麼多，還須要本身去實現嗎？不用！ JWT 已經定義了詳細的規範，並且有各類語言的若干實現。

在使用無狀態 Token 的時候，有兩點須要注意：

1. Refresh Token 有效時間較長，因此它應該在服務器端有狀態，以加強安全性，確保用戶註銷時可控
2. 應該考慮使用二次認證來加強敏感操做的安全性

基於JWT實現的Token認證方案

JSON Web Token是什麼？

JSON Web Token（JWT）是目前最流行的跨域身份驗證解決方案。

JSON Web Token（JWT）是一個開放標準（RFC 7519），它定義了一種緊湊且自包含的方式，用於在各方之間做爲JSON對象安全地傳輸信息。因爲此信息是通過數字簽名的，所以能夠被驗證和信任。可使用祕密（使用HMAC算法）或使用RSA或ECDSA的公用/專用密鑰對對JWT進行簽名。

JWT架構：

何時應該使用 JSON Web Token？

身份驗證

這是使用JWT的最多見方案。一旦用戶登陸，每一個後續請求將包括JWT，從而容許用戶訪問該令牌容許的路由，服務和資源。
單一登陸是當今普遍使用JWT的一項功能，由於它的開銷很小而且能夠在不一樣的域中輕鬆使用。

信息交換

JSON Web令牌是在各方之間安全地傳輸信息的一種好方法。由於能夠對JWT進行簽名（例如，使用公鑰/私鑰對），因此您能夠肯定發件人是本人。
另外，因爲簽名是使用標頭和有效負載計算的，所以您還能夠驗證內容是否未被篡改。

JSON Web Token 結構

JSON Web令牌以緊湊的形式由三部分組成，這些部分由點 （. ）分隔，分別是：

• Header：標頭
• Payload： 有效載荷
• Signature： 簽名

所以，JWT一般以下所示

xxxxx.yyyyy.zzzzz

Header：標頭

讓咱們分解不一樣的部分。
標頭一般由兩部分組成：令牌的類型（即JWT）和所使用的簽名算法，例如HMAC SHA256或RSA。
例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

而後，此JSON被Base64Url編碼以造成JWT的第一部分。

Payload： 有效載荷

令牌的第二部分是包含聲明的有效負載。聲明是關於實體（一般是用戶）和其餘數據的聲明。有三種類型的聲明：已註冊聲明、公共聲明和私有聲明。
已註冊的聲明：這些是一組預約義的聲明，它們不是強制的，而是推薦的，以提供一組有用的、可互操做的聲明。主要有：

• iss：發行人
• exp：到期時間
• sub：主題
• aud：用戶
• nbf：在此以前不可用
• Iat：發佈時間
• jti：JWT ID用於標識該JWT

請注意，聲明名稱僅是三個字符，由於JWT是緊湊的。

公共聲明：這些聲明能夠由使用JWTs的用戶隨意定義。可是，爲了不衝突，應該在IANA JSON Web令牌註冊表中定義它們，或者將它們定義爲包含防衝突命名空間的URI。

私有聲明：這些是爲在贊成使用它們的各方之間共享信息而建立的自定義索賠，既不是註冊索賠，也不是公開索賠。

有效負載示例能夠是：

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

對有效負載進行Base64Url編碼，以造成JSON Web令牌的第二部分。

請注意，對於已簽名的令牌，此信息儘管能夠防止篡改，但任何人均可以讀取。除非將其加密，不然請勿將機密信息放入JWT的有效負載或報頭元素中。

簽名

要建立簽名部分，您必須獲取編碼的頭、編碼的負載、密鑰、頭中指定的算法，並對其進行簽名。
例如，若是要使用HMAC SHA256算法，則將經過如下方式建立簽名：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

簽名用於驗證消息在整個過程當中沒有更改，而且對於使用私鑰進行簽名的令牌，它還能夠驗證JWT的發送者是它所說的真實身份。

整合在一塊兒

輸出是三個由點分隔的Base64 URL字符串，這些點能夠在HTML和HTTP環境中輕鬆傳遞，同時與基於XML的標準（如SAML）相比更加緊湊。
下面顯示了一個JWT，它對前一個報頭和有效負載進行了編碼，並用一個祕密進行了簽名。

能夠今後圖中看出JWT生成的令牌的格式與其對應餓原文之間的關聯。這裏也順帶推薦一下jwt官網的JWT debuger工具。

JSON Web Token工做原理

在身份驗證中，當用戶使用其憑據成功登陸時，將返回一個JSON Web Token。因爲Token是憑據，必須很是當心地防止安全問題。通常來講，您不該該將令牌保留的時間超過所需的時間。

因爲缺少安全性，也不該將敏感會話數據存儲在瀏覽器存儲中。

當用戶想要訪問受保護的路由或資源時，用戶代理應該發送JWT，一般在受權頭中使用承載模式。標題的內容應以下所示：

Authorization: Bearer <token>

在某些狀況下，這能夠是無狀態受權機制。服務器的受保護路由將檢查受權頭中是否存在有效的JWT，若是存在，則容許用戶訪問受保護的資源。若是JWT包含必要的數據，則能夠減小查詢數據庫以執行某些操做的須要，儘管狀況並不是老是如此。

若是令牌在受權頭中發送，則跨源資源共享（CORS）不會成爲問題，由於它不使用cookies。

下圖顯示瞭如何獲取JWT並將其用於訪問API或資源：

1. 應用程序或客戶端向受權服務器請求受權。這是經過不一樣的受權流之一執行的。例如，典型的符合OpenID Connect的web應用程序將使用受權代碼流經過/oauth/authorize端點。
2. 當受權被授予時，受權服務器將嚮應用程序返回一個訪問Token。
3. 應用程序使用訪問令牌訪問受保護的資源（如API）。

請注意：使用簽名的Token，Token中包含的全部信息都將向用戶或其餘方公開，即便他們沒法更改它。這意味着您不該將機密信息放入Token中。

JWT的使用

生成令牌

jwt.sign(payload, secretOrPrivateKey, [options, callback])
// paylod: 有效載荷
// secretOrPrivateKey: 加密密鑰或私鑰
// option(可選): 生成令牌設置
// callback(可選): 回調函數

其中option可配置屬性，屬性均爲可選：

algorithm: 算法(默認: HS256)

noTimestamp: 無時間戳

header: 頭部

keyid: 鍵值編號

mutatePayload: 是否對payload進行轉化，若爲true則會用payload初始值生成令牌

如下6相便可在payload中配置也可在option中配置，注意只可在一處出現。

expiresIn: 令牌過時時間（可爲數字（單位秒）或帶單位的字符串，例如 60, "2 days", "10h", "7d"等）

notBefore: 在此以前不可用（格式如上述expiresIn）

audience: 用戶

issuer: 發佈者

jwtid: 令牌id

subject: 主題

生成令牌實例

// 異步回調方式
Let privateKey = 'Cloudy'
jwt.sign({ id: '1', exp:'7d' }, privateKey, { algorithm: 'RS256' }, function(err, token) {
  console.log(token);
});

// 同步方式（推薦用promise對其進行進一步封裝）
let token = jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256', expiresIn: '1h' });

令牌驗證

jwt.verify(token, secretOrPublicKey, [options, callback])
// token: 令牌
// secretOrPublicKey: 密鑰或公鑰
// option: 生成令牌設置(可選）
// callback: 回調函數（可選）

其中option可配置屬性有：

algorithms: 算法

audience: 若是你想驗證用戶，爲其提供一個字符串或正則表達式

complete: Boolean值，若爲true則完整輸出令牌

issuer(可選): 若是你想驗證發佈者，爲其提供一個字符串或正則表達式

ignoreExpiration: Boolean值，若爲true則不會驗證過時時間

subject: 若是你想驗證主題，爲其提供一個字符串或正則表達式

clockTolerance: 時鐘容忍，在檢查nbf和exp聲明時，處理不一樣服務器之間的小時鐘差別所容許的秒數

maxAge: 容許令牌的最大容許年齡仍然有效。它以秒或描述時間跨度zeit/ms的字符串表示。Eg: 1000, "2 days", "10h", "7d".

clockTimestamp: 時間戳，應用做全部必要比較的當前時間（秒）。

nonce：若是要檢查nonce聲明，請在此處提供一個字符串值。

驗證令牌實例

// 同步驗證（對稱加密算法）
var decoded = jwt.verify(token, 'shhhhh');
console.log(decoded.foo) // bar

// 異步驗證用戶（使用不對稱加密算法）
var cert = fs.readFileSync('public.pem');  // 獲取公鑰
jwt.verify(token, cert, { audience: 'urn:foo', jwtid: 'jwtid', subject: 'subject' }, function(err, decoded) {
  // if audience mismatch, err == invalid audience
});

簡單解碼（無驗證）

（同步）返回解碼的有效負載，而不驗證簽名是否有效。

jwt.decode(token [, options])

解碼options可配置屬性:

json 在負載上強制JSON.parse，即便頭不包含「typ」：「JWT」。
complete 返回一個帶有解碼有效負載和頭的對象。

支持的算法數組。目前支持如下算法。

alg Parameter Value	Digital Signature or MAC Algorithm
HS256	HMAC using SHA-256 hash algorithm
HS384	HMAC using SHA-384 hash algorithm
HS512	HMAC using SHA-512 hash algorithm
RS256	RSASSA-PKCS1-v1_5 using SHA-256 hash algorithm
RS384	RSASSA-PKCS1-v1_5 using SHA-384 hash algorithm
RS512	RSASSA-PKCS1-v1_5 using SHA-512 hash algorithm
PS256	RSASSA-PSS using SHA-256 hash algorithm (only node ^6.12.0 OR >=8.0.0)
PS384	RSASSA-PSS using SHA-384 hash algorithm (only node ^6.12.0 OR >=8.0.0)
PS512	RSASSA-PSS using SHA-512 hash algorithm (only node ^6.12.0 OR >=8.0.0)
ES256	ECDSA using P-256 curve and SHA-256 hash algorithm
ES384	ECDSA using P-384 curve and SHA-384 hash algorithm
ES512	ECDSA using P-521 curve and SHA-512 hash algorithm
none	No digital signature or MAC value included

JWT問題和趨勢

一、JWT默認不加密，但能夠加密。生成原始令牌後，可使用改令牌再次對其進行加密。
二、當JWT未加密方法是，一些私密數據沒法經過JWT傳輸。
三、JWT不只可用於認證，還可用於信息交換。善用JWT有助於減小服務器請求數據庫的次數。
四、JWT的最大缺點是服務器不保存會話狀態，因此在使用期間不可能取消令牌或更改令牌的權限。也就是說，一旦JWT簽發，在有效期內將會一直有效。
五、JWT自己包含認證信息，所以一旦信息泄露，任何人均可以得到令牌的全部權限。爲了減小盜用，JWT的有效期不宜設置太長。對於某些重要操做，用戶在使用時應該每次都進行進行身份驗證。
六、爲了減小盜用和竊取，JWT不建議使用HTTP協議來傳輸代碼，而是使用加密的HTTPS協議進行傳輸。

結語

最近正好在獨立開發一個後臺管理系統，涉及到了Token驗證，若是以爲文章對你有用，請你幫我點個贊吧，你的點贊和關注是我一直堅持分享的動力！

推薦閱讀：
【專題：JavaScript進階之路】
深刻理解 ES6 Promise
JavaScript之函數柯理化
ES6 尾調用和尾遞歸
Git經常使用命令小結
淺談 MVC 和 MVVM 模型

參考:
node-jsonwebtoken
Introduction to JSON Web Tokens
Token 認證的前因後果
完全理解cookie，session，token
先後端分離使用 Token 登陸解決方案
基於JWT的token身份認證方案

---

我是Cloudy，現居上海，年輕的前端攻城獅一枚，愛專研，愛技術，愛分享。
我的筆記，整理不易，感謝關注、閱讀、點贊和收藏。
文章有任何問題歡迎你們指出，也歡迎你們一塊兒交流各類前端、後端、算法問題！