jwt 認(rèn)證

JSON Web Token（縮寫 JWT）是目前最流行的跨域認(rèn)證解決方案。

當(dāng)用戶成功登錄系統(tǒng)并成功驗(yàn)證有效之后，服務(wù)器會利用某種機(jī)制產(chǎn)生一個token字符串，這個token中可以包含很多信息，例如來源IP，過期時間，用戶信息等， 把這個字符串下發(fā)給客戶端，客戶端在之后的每次請求中都攜帶著這個token，攜帶方式其實(shí)很自由，無論是cookie方式還是其他方式都可以。當(dāng)服務(wù)端收到請求，取出token進(jìn)行驗(yàn)證（可以驗(yàn)證來源ip，過期時間等信息），如果合法則允許進(jìn)行操作。

基于token的驗(yàn)證方式它有什么優(yōu)點(diǎn)嗎？

1. 支持跨域訪問，Cookie是不允許跨域訪問的，這一點(diǎn)對Token機(jī)制是不存在的，前提是傳輸?shù)挠脩粽J(rèn)證信息通過HTTP頭傳輸.

2. 無狀態(tài):Token機(jī)制在服務(wù)端不需要存儲session信息，因?yàn)門oken自身包含了所有登錄用戶的信息，只需要在客戶端的cookie或本地介質(zhì)存儲狀態(tài)信息.

3. 解耦 不需要綁定到一個特定的身份驗(yàn)證方案。Token可以在任何地方生成，只要在你的API被調(diào)用的時候，你可以進(jìn)行Token生成調(diào)用即可.

4. 適用性更廣：只要是支持http協(xié)議的客戶端，就可以使用token認(rèn)證。

5. 服務(wù)端只需要驗(yàn)證token的安全，不必再去獲取登錄用戶信息，因?yàn)橛脩舻牡卿浶畔⒁呀?jīng)在token信息中。

6. 基于標(biāo)準(zhǔn)化:你的API可以采用標(biāo)準(zhǔn)化的 JSON Web Token (JWT).

那基于token的認(rèn)證方式有哪些缺點(diǎn)呢？

1. 網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量增大：由于token中存儲了大量的用戶和安全相關(guān)的信息，所以比單純的cookie信息(例如session_id)要大很多，傳輸過程中需要消耗更多流量，占用更多帶寬，

2. 和所有的客戶端認(rèn)證方式一樣，如果想要在服務(wù)端控制token的注銷有難度，而且也很難解決客戶端的劫持問題。

3. 由于token信息在服務(wù)端增加了一次驗(yàn)證數(shù)據(jù)完整性的操作，所以比session的認(rèn)證方式增加了cpu的開銷。

但是整體來看，基于token的認(rèn)證方式還是比session和cookie方式要有很大優(yōu)勢。在所知的token認(rèn)證中，jwt是一種優(yōu)秀的解決方案。

JSON Web Token (JWT)是一個開放標(biāo)準(zhǔn)(RFC 7519)，它定義了一種緊湊的、自包含的方式，用于作為JSON對象在各方之間安全地傳輸信息。該信息可以被驗(yàn)證和信任，因?yàn)樗菙?shù)字簽名的。

一個JWT實(shí)際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。中間用點(diǎn)（.）分隔成三個部分。注意JWT 內(nèi)部是沒有換行的。

2.1 頭部

header典型的由兩部分組成：token的類型（“JWT”）和算法名稱（比如：HMAC SHA256或者RSA等等）。

1
2
3
4

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

2.2 Payload

Payload 部分也是一個JSON對象，用來存放實(shí)際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個官方字段，供選用。

1
2
3
4
5
6
7

iss (issuer)：簽發(fā)人
exp (expiration time)：過期時間
sub (subject)：主題
aud (audience)：受眾
nbf (Not Before)：生效時間
iat (Issued At)：簽發(fā)時間
jti (JWT ID)：編號

除了以上字段之外，你完全可以添加自己想要的任何字段，這里還是提醒一下，由于jwt的標(biāo)準(zhǔn)，信息是不加密的，所以一些敏感信息最好不要添加到j(luò)son里面

1
2
3
4

{
    "Name":"菜菜",
    "Age":18
}

2.3 Signature

為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個秘鑰（這個秘鑰只有服務(wù)端知道），簽名算法是header中指定的那個，然后對它們簽名即可。

1

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

算出簽名以后，把 Header、Payload、Signature 三個部分拼成一個字符串，每個部分之間用”點(diǎn)”（.）分隔，就可以返回給用戶。需要提醒一下：base64是一種編碼方式，并非加密方式。

3.1 流程

1. 客戶端攜帶用戶的登錄憑證（一般為用戶名密碼）提交請求

2. 服務(wù)端收到登錄請求，驗(yàn)證憑證正確性，如果正確則按照協(xié)議規(guī)定生成token信息，經(jīng)過簽名并返回給客戶端

3. 客戶端收到token信息，可以保存在cookie或者其他地方，以后每次請求的時候都攜帶上token信息

4. 業(yè)務(wù)服務(wù)器收到請求，驗(yàn)證token的正確性，如果正確則進(jìn)行下一步操作

3.2 交互

客戶端收到服務(wù)器返回的 JWT，可以儲存在 Cookie 里面，也可以儲存在 localStorage。
此后，客戶端每次與服務(wù)器通信，都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發(fā)送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。

1
2
3
4
5
6
7

Authorization: Bearer 

fetch('api/user/1', {
  headers: {
'Authorization': 'Bearer ' + token
  }
})

3.3 特點(diǎn)

（1）JWT 默認(rèn)是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。
（2）JWT 不加密的情況下，不能將秘密數(shù)據(jù)寫入 JWT。
（3）JWT 不僅可以用于認(rèn)證，也可以用于交換信息。有效使用 JWT，可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。
（4）JWT 的最大缺點(diǎn)是，由于服務(wù)器不保存 session 狀態(tài)，因此無法在使用過程中廢止某個 token，或者更改 token 的權(quán)限。也就是說，一旦 JWT 簽發(fā)了，在到期之前就會始終有效，除非服務(wù)器部署額外的邏輯。
（5）JWT 本身包含了認(rèn)證信息，一旦泄露，任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用，JWT 的有效期應(yīng)該設(shè)置得比較短。對于一些比較重要的權(quán)限，使用時應(yīng)該再次對用戶進(jìn)行認(rèn)證。
（6）為了減少盜用，JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸，要使用 HTTPS 協(xié)議傳輸。

3.4 問題

1. 用戶登出，如何設(shè)置token無效？

• 用戶登出，瀏覽器端丟棄token

• 使用redis數(shù)據(jù)庫，用戶登出，從redis中刪除對應(yīng)的token,請求訪問時，需要從redis庫中取出對應(yīng)的token,若沒有，則表明已經(jīng)登出

兩個不同的設(shè)備，一個設(shè)備登出，另外一個設(shè)備如何處理？

• 服務(wù)器維護(hù)一個清單（記錄該賬號是否已經(jīng)簽發(fā)token），這樣又回到session的老路了

• 每一個設(shè)備與用戶生成唯一的key,保存在redis中，即設(shè)備1的用戶登出，只刪除對應(yīng)的token，設(shè)備2的token仍然存在

• 服務(wù)器端維護(hù)一個版本號，相同用戶不同設(shè)備登入，版本號加1，這樣保持key的唯一性（和上面差不多）

source: //www.liuvv.com/p/722ed7e7.html

記得點(diǎn)「贊」和「在看」↓

愛你們