什么是JWT

Json web token (JWT), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開(kāi)放標(biāo)準(zhǔn)（(RFC 7519).該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場(chǎng)景。JWT的聲明一般被用來(lái)在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

起源

認(rèn)證是用來(lái)判斷用戶身份。
為了避免每次都要重新認(rèn)證，可以在認(rèn)證成功后創(chuàng)建會(huì)話，保持認(rèn)證方式通常有兩種，session認(rèn)證和基于token的認(rèn)證。

我們來(lái)談一談基于token的認(rèn)證和傳統(tǒng)的session認(rèn)證的區(qū)別。

• 傳統(tǒng)的session認(rèn)證
  我們知道，http協(xié)議本身是一種無(wú)狀態(tài)的協(xié)議，而這就意味著如果用戶向我們的應(yīng)用提供了用戶名和密碼來(lái)進(jìn)行用戶認(rèn)證，那么下一次請(qǐng)求時(shí)，用戶還要再一次進(jìn)行用戶認(rèn)證才行，因?yàn)楦鶕?jù)http協(xié)議，我們并不能知道是哪個(gè)用戶發(fā)出的請(qǐng)求，所以為了讓我們的應(yīng)用能識(shí)別是哪個(gè)用戶發(fā)出的請(qǐng)求，我們只能在服務(wù)器存儲(chǔ)一份用戶登錄的信息，這份登錄信息會(huì)在響應(yīng)時(shí)傳遞給瀏覽器，告訴其保存為cookie,以便下次請(qǐng)求時(shí)發(fā)送給我們的應(yīng)用，這樣我們的應(yīng)用就能識(shí)別請(qǐng)求來(lái)自哪個(gè)用戶了,這就是傳統(tǒng)的基于session認(rèn)證。

  但是這種基于session的認(rèn)證使應(yīng)用本身很難得到擴(kuò)展，隨著不同客戶端用戶的增加，獨(dú)立的服務(wù)器已無(wú)法承載更多的用戶，而這時(shí)候基于session認(rèn)證應(yīng)用的問(wèn)題就會(huì)暴露出來(lái).

  基于session認(rèn)證所顯露的問(wèn)題

Session: 每個(gè)用戶經(jīng)過(guò)我們的應(yīng)用認(rèn)證之后，我們的應(yīng)用都要在服務(wù)端做一次記錄，以方便用戶下次請(qǐng)求的鑒別，通常而言session都是保存在內(nèi)存中，而隨著認(rèn)證用戶的增多，服務(wù)端的開(kāi)銷會(huì)明顯增大。

擴(kuò)展性: 用戶認(rèn)證之后，服務(wù)端做認(rèn)證記錄，如果認(rèn)證的記錄被保存在內(nèi)存中的話，這意味著用戶下次請(qǐng)求還必須要請(qǐng)求在這臺(tái)服務(wù)器上,這樣才能拿到授權(quán)的資源，這樣在分布式的應(yīng)用上，相應(yīng)的限制了負(fù)載均衡器的能力。這也意味著限制了應(yīng)用的擴(kuò)展能力。

CSRF: 因?yàn)槭腔赾ookie來(lái)進(jìn)行用戶識(shí)別的, cookie如果被截獲，用戶就會(huì)很容易受到跨站請(qǐng)求偽造的攻擊。

基于token的鑒權(quán)機(jī)制

基于token的鑒權(quán)機(jī)制類似于http協(xié)議也是無(wú)狀態(tài)的，它不需要在服務(wù)端去保留用戶的認(rèn)證信息或者會(huì)話信息。這就意味著基于token認(rèn)證機(jī)制的應(yīng)用不需要去考慮用戶在哪一臺(tái)服務(wù)器登錄了，這就為應(yīng)用的擴(kuò)展提供了便利。

流程上是這樣的：

用戶使用用戶名密碼來(lái)請(qǐng)求服務(wù)器
服務(wù)器進(jìn)行驗(yàn)證用戶的信息
服務(wù)器通過(guò)驗(yàn)證發(fā)送給用戶一個(gè)token
客戶端存儲(chǔ)token，并在每次請(qǐng)求時(shí)附送上這個(gè)token值
服務(wù)端驗(yàn)證token值，并返回?cái)?shù)據(jù)
這個(gè)token必須要在每次請(qǐng)求時(shí)傳遞給服務(wù)端，它應(yīng)該保存在請(qǐng)求頭里， 另外，服務(wù)端要支持CORS(跨域源資源共享)策略，一般我們?cè)诜?wù)端這么做就可以了：

@Configuration public class WebConfig extends WebMvcConfigurerAdapter {@Overridepublic void addCorsMappings(CorsRegistry registry) {registry.addMapping("/**/*").allowedOrigins("*");} }

那么我們現(xiàn)在回到JWT的主題上。

JWT的構(gòu)成

JWT長(zhǎng)什么樣？
JWT是由三段信息構(gòu)成的，將這三段信息文本用.鏈接一起就構(gòu)成了Jwt字符串。就像這樣:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload,即自定義的一些信息)，第三部分是簽證（signature).
（JWT.io官方網(wǎng)站提供工具進(jìn)行token的解析）

1. header

jwt的頭部承載兩部分信息：
聲明類型，這里是jwt
聲明使用的hash算法如：HMAC SHA256或RSA， 通常直接使用 HMAC SHA256
完整的頭部就像下面這樣的JSON：

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

然后將頭部進(jìn)行Base64Url編碼（注意當(dāng)然客戶端可以解碼）構(gòu)成了第一部分.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.<second part>.<third part>

base64UrlEncode

---

Base64URL和常見(jiàn)Base64算法類似，稍有差別。
作為令牌的JWT可以放在URL中（例如api.example/?token=xxx）。 Base64中用的三個(gè)字符是"+"，"/“和”="，由于在URL中有特殊含義，因此Base64URL中對(duì)他們做了替換："=“去掉，”+“用”-“替換，”/“用”_"替換，這就是Base64URL算法，很簡(jiǎn)單吧。

2. playload
載荷就是存放有效信息的地方。這個(gè)名字像是特指飛機(jī)上承載的貨品，這些有效信息包含三個(gè)部分

• 標(biāo)準(zhǔn)中注冊(cè)的聲明
  iss: jwt簽發(fā)者
  sub: jwt所面向的用戶
  aud: 接收jwt的一方
  exp: jwt的過(guò)期時(shí)間，這個(gè)過(guò)期時(shí)間必須要大于簽發(fā)時(shí)間
  nbf: 定義在什么時(shí)間之前，該jwt都是不可用的.
  iat: jwt的簽發(fā)時(shí)間
  jti: jwt的唯一身份標(biāo)識(shí)，主要用來(lái)作為一次性token,從而回避重放攻擊。
• 公共的聲明
  公共的聲明可以添加任何的信息，一般添加用戶的相關(guān)信息或其他業(yè)務(wù)需要的必要信息.但不建議添加敏感信息，因?yàn)樵摬糠衷诳蛻舳丝山饷?
• 私有的聲明
  標(biāo)準(zhǔn)中注冊(cè)的聲明 (建議但不強(qiáng)制使用) ：
  私有聲明是提供者和消費(fèi)者所共同定義的聲明，一般不建議存放敏感信息，因?yàn)閎ase64不是加密，可以解碼的，相當(dāng)于明文信息。

定義一個(gè)payload:

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

這部分同樣使用Base64Url編碼成第二部分

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.<third part>

3. signature
Signature是用來(lái)驗(yàn)證發(fā)送者的JWT的同時(shí)也能確保客戶端傳來(lái)的JWT沒(méi)有被篡改。

簽名哈希部分是對(duì)上面兩部分?jǐn)?shù)據(jù)簽名，通過(guò)指定的算法生成哈希，以確保數(shù)據(jù)不會(huì)被篡改。
首先，需要指定一個(gè)密碼（secret）。該密碼僅僅為保存在服務(wù)器中，并且不能向用戶公開(kāi)。然后，使用標(biāo)頭中指定的簽名算法（默認(rèn)情況下為HMAC SHA256）根據(jù)以下公式生成簽名。

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

結(jié)果

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意：secret是保存在服務(wù)器端的，jwt的簽發(fā)生成也是在服務(wù)器端的，secret就是用來(lái)進(jìn)行jwt的簽發(fā)和jwt的驗(yàn)證，所以，它就是你服務(wù)端的私鑰，在任何場(chǎng)景都不應(yīng)該流露出去。一旦客戶端得知這個(gè)secret, 那就意味著客戶端是可以自我簽發(fā)jwt了。

客戶端如何應(yīng)用

客戶端接收服務(wù)器返回的JWT，將其存儲(chǔ)在Cookie或localStorage中。

此后，客戶端將在與服務(wù)器交互中都會(huì)帶JWT。如果將它存儲(chǔ)在Cookie中，就可以自動(dòng)發(fā)送，但是不會(huì)跨域，因此一般是將它放入HTTP請(qǐng)求的Header Authorization字段中。

Authorization: Bearer JWT_TOKEN

當(dāng)跨域時(shí)，也可以將JWT被放置于POST請(qǐng)求的數(shù)據(jù)主體中。
一般是在請(qǐng)求頭里加入Authorization，并加上Bearer標(biāo)注：

服務(wù)端會(huì)驗(yàn)證token，如果驗(yàn)證通過(guò)就會(huì)返回相應(yīng)的資源。整個(gè)流程就是這樣的:

總結(jié)

優(yōu)點(diǎn)

• 因?yàn)閖son的通用性，所以JWT是可以進(jìn)行跨語(yǔ)言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語(yǔ)言都可以使用。
• 因?yàn)橛辛藀ayload部分，所以JWT可以在自身存儲(chǔ)一些其他業(yè)務(wù)邏輯所必要的非敏感信息。
• 便于傳輸，jwt的構(gòu)成非常簡(jiǎn)單，字節(jié)占用很小，所以它是非常便于傳輸?shù)摹?/li>
• 它不需要在服務(wù)端保存會(huì)話信息, 所以它易于應(yīng)用的擴(kuò)展，不用考慮服務(wù)器之間的同步問(wèn)題

安全相關(guān)

• 不應(yīng)該在jwt的payload部分存放敏感信息，因?yàn)樵摬糠质强蛻舳丝山饷艿牟糠帧?/li>
• 保護(hù)好secret私鑰，該私鑰非常重要。
• 如果可以，請(qǐng)使用https協(xié)議

總結(jié)

以上是生活随笔為你收集整理的JWT-基于token的认证方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。