引語

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

一、基于session的跨域身份驗證

Internet服務無法與用戶身份驗證分開。一般過程如下。

用戶向服務器發送用戶名和密碼。驗證服務器后，相關數據（如用戶角色，登錄時間等）將保存在當前會話中。服務器向用戶返回session_id，session信息都會寫入到用戶的Cookie。用戶的每個后續請求都將通過在Cookie中取出session_id傳給服務器。服務器收到session_id并對比之前保存的數據，確認用戶的身份。

這種模式最大的問題是，沒有分布式架構，無法支持橫向擴展。如果使用一個服務器，該模式完全沒有問題。但是，如果它是服務器群集或面向服務的跨域體系結構的話，則需要一個統一的session數據庫庫來保存會話數據實現共享，這樣負載均衡下的每個服務器才可以正確的驗證用戶身份。

例如蟲蟲舉一個實際中常見的單點登陸的需求：站點A和站點B提供同一公司的相關服務?，F在要求用戶只需要登錄其中一個網站，然后它就會自動登錄到另一個網站。怎么做？

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

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

Session：每次認證用戶發起請求時，服務器需要去創建一個記錄來存儲信息。當越來越多的用戶發請求時，內存的開銷也會不斷增加。可擴展性：在服務端的內存中使用Seesion存儲登錄信息，伴隨而來的是可擴展性問題。CORS(跨域資源共享)：當我們需要讓數據跨多臺移動設備上使用時，跨域資源的共享會是一個讓人頭疼的問題。在使用Ajax抓取另一個域的資源，就可以會出現禁止請求的情況。CSRF(跨站請求偽造)：用戶在訪問銀行網站時，他們很容易受到跨站請求偽造的攻擊，并且能夠被利用其訪問其他的網站。在這些問題中，可擴展行是最突出的。因此我們有必要去尋求一種更有行之有效的方法?；赥oken認證的身份認證方案

那么有什么更好的方案嗎？當然有，那就是基于Token的身份認證方案。

那么基于Token的身份驗證可以解決哪些問題呢？

Token 完全由應用管理，所以它可以避開同源策略Token 可以避免 CSRF 攻擊Token 可以是無狀態的，可以在多個服務間共享基于Token認證的原理

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

客戶端可以在每次請求的時候帶上 Token 證明自己的合法地位。如果這個 Token 在服務端持久化（比如存入數據庫），那它就是一個永久的身份令牌?；赥oken的身份驗證這種概念解決了在服務端存儲信息時的許多問題。NoSession意味著你的程序可以根據需要去增減機器，而不用去擔心用戶是否登錄。

基于Token的身份驗證的方案過程如下:

用戶通過用戶名和密碼發送請求。服務端驗證。服務端返回一個簽名的token 給客戶端?？蛻舳藘Υ鎡oken,并且每次發送請求都會攜帶token。服務端驗證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 簽名時并無必要——既然不需要解密，摘要（散列）算法就會更快?？梢灾付艽a的散列算法，自然是 HMAC。

上面說了這么多，還需要自己去實現嗎？不用！ JWT 已經定義了詳細的規范，而且有各種語言的若干實現。

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

Refresh Token 有效時間較長，所以它應該在服務器端有狀態，以增強安全性，確保用戶注銷時可控應該考慮使用二次認證來增強敏感操作的安全性基于JWT實現的Token認證方案JSON Web Token是什么？

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

JSON Web Token（JWT）是一個開放標準（RFC 7519），它定義了一種緊湊且自包含的方式，用于在各方之間作為JSON對象安全地傳輸信息。由于此信息是經過數字簽名的，因此可以被驗證和信任?？梢允褂妹孛埽ㄊ褂肏MAC算法）或使用RSA或ECDSA的公用/專用密鑰對對JWT進行簽名。

JWT架構：

什么時候應該使用 JSON Web Token？身份驗證

這是使用JWT的最常見方案。一旦用戶登錄，每個后續請求將包括JWT，從而允許用戶訪問該令牌允許的路由，服務和資源。

單一登錄是當今廣泛使用JWT的一項功能，因為它的開銷很小并且可以在不同的域中輕松使用。

信息交換

JSON Web令牌是在各方之間安全地傳輸信息的一種好方法。因為可以對JWT進行簽名（例如，使用公鑰/私鑰對），所以您可以確定發件人是本人。

另外，由于簽名是使用標頭和有效負載計算的，因此您還可以驗證內容是否未被篡改。

JSON Web Token 結構

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

因此，JWT通常如下所示

xxxxx.yyyyy.zzzzz 

Header：標頭

讓我們分解不同的部分。

標頭通常由兩部分組成：令牌的類型（即JWT）和所使用的簽名算法，例如HMAC SHA256或RSA。

例如：

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

然后，此JSON被Base64Url編碼以形成JWT的第一部分。

Payload： 有效載荷

令牌的第二部分是包含聲明的有效負載。聲明是關于實體（通常是用戶）和其他數據的聲明。有三種類型的聲明：已注冊聲明、公共聲明和私有聲明。

已注冊的聲明：這些是一組預定義的聲明，它們不是強制的登錄token無效，而是推薦的，以提供一組有用的、可互操作的聲明。主要有：

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

公共聲明：這些聲明可以由使用JWTs的用戶隨意定義。但是，為了避免沖突，應該在IANA JSON Web令牌注冊表中定義它們，或者將它們定義為包含防沖突命名空間的URI。

私有聲明：這些是為在同意使用它們的各方之間共享信息而創建的自定義索賠，既不是注冊索賠，也不是公開索賠。

有效負載示例可以是：

{
  "sub": "1234567890",

  "name": "John Doe",
  "admin": true
}

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

請注意，對于已簽名的令牌登錄token無效，此信息盡管可以防止篡改，但任何人都可以讀取。除非將其加密，否則請勿將機密信息放入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 

在某些情況下，這可以是無狀態授權機制。服務器的受保護路由將檢查授權頭中是否存在有效的JWT，如果存在，則允許用戶訪問受保護的資源。如果JWT包含必要的數據，則可以減少查詢數據庫以執行某些操作的需要，盡管情況并非總是如此。

如果令牌在授權頭中發送，則跨源資源共享（CORS）不會成為問題，因為它不使用cookies。

下圖顯示了如何獲取JWT并將其用于訪問API或資源：

應用程序或客戶端向授權服務器請求授權。這是通過不同的授權流之一執行的。例如，典型的符合OpenID Connect的web應用程序將使用授權代碼流通過/oauth/authorize端點。當授權被授予時，授權服務器將向應用程序返回一個訪問Token。應用程序使用訪問令牌訪問受保護的資源（如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 ValueDigital 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問題和趨勢

1、JWT默認不加密，但可以加密。生成原始令牌后，可以使用改令牌再次對其進行加密。

2、當JWT未加密方法是，一些私密數據無法通過JWT傳輸。

3、JWT不僅可用于認證，還可用于信息交換。善用JWT有助于減少服務器請求數據庫的次數。

4、JWT的最大缺點是服務器不保存會話狀態，所以在使用期間不可能取消令牌或更改令牌的權限。也就是說，一旦JWT簽發，在有效期內將會一直有效。

5、JWT本身包含認證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權限。為了減少盜用，JWT的有效期不宜設置太長。對于某些重要操作，用戶在使用時應該每次都進行進行身份驗證。

6、為了減少盜用和竊取，JWT不建議使用HTTP協議來傳輸代碼，而是使用加密的HTTPS協議進行傳輸。

結語

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