.Net?Core如何授權(quán)認(rèn)證JWT

這篇文章主要講解了“.Net Core如何授權(quán)認(rèn)證JWT”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“.Net Core如何授權(quán)認(rèn)證JWT”吧！

一、前言

現(xiàn)在越來越多的項(xiàng)目或多或少會(huì)用到JWT，為什么會(huì)出現(xiàn)使用JWT這樣的場(chǎng)景的呢？

假設(shè)現(xiàn)在有一個(gè)APP，后臺(tái)是分布式系統(tǒng)。APP的首頁(yè)模塊部署在上海機(jī)房的服務(wù)器上，子頁(yè)面模塊部署在深圳機(jī)房的服務(wù)器上。此時(shí)你從首頁(yè)登錄了該APP，然后跳轉(zhuǎn)到子頁(yè)面模塊。session在兩個(gè)機(jī)房之間不能同步，用戶是否需要重新登錄？

傳統(tǒng)的方式（cookie+session）需要重新登錄，用戶體驗(yàn)不好。session共享（在多臺(tái)物理機(jī)之間傳輸和復(fù)制session）方式對(duì)網(wǎng)絡(luò)IO的壓力大，延遲太長(zhǎng)，用戶體驗(yàn)也不好。

說到這大家可能會(huì)想到，用服務(wù)器的session_id存儲(chǔ)到cookies中也能做到，為什么非要用token呢？網(wǎng)上有許多文章來比較token和session的優(yōu)缺點(diǎn)，其實(shí)，開發(fā)web應(yīng)用的話用哪種都行。但如果是開發(fā)api接口，前后端分離，最好使用token，為什么這么說呢，因?yàn)閟ession+cookies是基于web的。但是針對(duì) api接口，可能會(huì)考慮到移動(dòng)端，app是沒有cookies和session的。

Session方式存儲(chǔ)用戶信息的最大問題在于要占用大量服務(wù)器內(nèi)存，增加服務(wù)器的開銷。

而JWT方式將用戶狀態(tài)分散到了客戶端中，可以明顯減輕服務(wù)端的內(nèi)存壓力。Session的狀態(tài)是存儲(chǔ)在服務(wù)器端，客戶端只有session id；而Token的狀態(tài)是存儲(chǔ)在客戶端

二、原理

JSON Web Token（縮寫 JWT）

JWT 的原理是，服務(wù)器認(rèn)證以后，生成一個(gè) JSON 對(duì)象，發(fā)回給用戶，以后，用戶與服務(wù)端通信的時(shí)候，都要發(fā)回這個(gè) JSON 對(duì)象。

服務(wù)器完全只靠這個(gè)對(duì)象認(rèn)定用戶身份。為了防止用戶篡改數(shù)據(jù)，服務(wù)器在生成這個(gè)對(duì)象的時(shí)候，會(huì)加上簽名。

服務(wù)器就不保存任何 session 數(shù)據(jù)了，也就是說，服務(wù)器變成無(wú)狀態(tài)了，從而比較容易實(shí)現(xiàn)擴(kuò)展。

三、組合

JWT 的三個(gè)部分依次是：Header（頭部）、Payload（負(fù)載）、Signature（簽名）

寫成一行，就是下面的樣子。

Header.Payload.Signature

1、Header頭部

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

{
    "alg": "HS256", //alg屬性表示簽名的算法（algorithm），默認(rèn)是 HMAC SHA256（寫成 HS256）
    "typ": "JWT"   //typ屬性表示這個(gè)令牌（token）的類型（type）
}

然后用Base64對(duì)這個(gè)JSON編碼就得到JWT的第一部分

2、Payload負(fù)載

JWT的第二部分是payload，它包含聲明（要求）。聲明是關(guān)于實(shí)體(通常是用戶)和其他數(shù)據(jù)的聲明

JWT 規(guī)定了7個(gè)官方字段

• iss (issuer)：簽發(fā)人

• exp (expiration time)：過期時(shí)間

• sub (subject)：主題

• aud (audience)：受眾

• nbf (Not Before)：生效時(shí)間

• iat (Issued At)：簽發(fā)時(shí)間

• jti (JWT ID)：編號(hào)

除了官方字段，你還可以在這個(gè)部分定義私有字段，下面就是一個(gè)例子

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

注意，不要在JWT的payload或header中放置敏感信息，除非它們是加密的

3、Signature簽名

Signature 部分是對(duì)前兩部分的簽名，防止數(shù)據(jù)篡改。

簽名是用于驗(yàn)證消息在傳遞過程中有沒有被更改，并且，對(duì)于使用私鑰簽名的token，它還可以驗(yàn)證JWT的發(fā)送方是否為它所稱的發(fā)送方。

為了得到簽名部分，你必須有編碼過的header、編碼過的payload、一個(gè)秘鑰。簽名算法是header中指定的那個(gè)，然對(duì)它們簽名即可。按照下面的公式產(chǎn)生簽名。

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

算出簽名以后，把 Header、Payload、Signature 三個(gè)部分拼成一個(gè)字符串，每個(gè)部分之間用"點(diǎn)"（.）分隔，就可以返回給用戶。

四、開始

1、客戶端收到服務(wù)器返回的 JWT，可以儲(chǔ)存在 Cookie 里面，也可以儲(chǔ)存在 localStorage。

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

Authorization: Bearer <token>

2、JWT 就放在 POST 請(qǐng)求的數(shù)據(jù)體里面，那么跨源資源共享(CORS)將不會(huì)成為問題，因?yàn)樗皇褂胏ookie。

• 應(yīng)用（或者客戶端）向授權(quán)服務(wù)器請(qǐng)求授權(quán)。例如，如果用授權(quán)碼流程的話，就是/oauth/authorize

• 當(dāng)授權(quán)被許可以后，授權(quán)服務(wù)器返回一個(gè)access token給應(yīng)用

• 應(yīng)用使用access token訪問受保護(hù)的資源（比如：API）

五、特點(diǎn)

1.JWT 默認(rèn)是不加密，但也是可以加密的。生成原始 Token 以后，可以用密鑰再加密一次。

2.JWT 不加密的情況下，不能將秘密數(shù)據(jù)寫入 JWT。

3.JWT 的最大缺點(diǎn)是，由于服務(wù)器不保存 session 狀態(tài)，因此無(wú)法在使用過程中廢止某個(gè) token，或者更改 token 的權(quán)限。也就是說，一旦 JWT 簽發(fā)了，在到期之前就會(huì)始終有效，除非服務(wù)器部署額外的邏輯。

4.JWT 本身包含了認(rèn)證信息，一旦泄露，任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用，JWT 的有效期應(yīng)該設(shè)置得比較短。對(duì)于一些比較重要的權(quán)限，使用時(shí)應(yīng)該再次對(duì)用戶進(jìn)行認(rèn)證。

注意：

JWT 是 JSON 格式的被加密了的字符串

JWT 的核心是密鑰，就是 JSON 數(shù)據(jù)。這是你關(guān)心的，并希望安全傳遞出去的數(shù)據(jù)。JWT 如何做到這一點(diǎn)，并使你信任它，就是加密簽名。

被篡改之后

感謝各位的閱讀，以上就是“.Net Core如何授權(quán)認(rèn)證JWT”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì).Net Core如何授權(quán)認(rèn)證JWT這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！