jwt簡介
JSON Web Token(縮寫 JWT)是目前最流行的跨域認證解決方案,是一個開放標準(RFC 7519),它定義了一種緊湊的、自包含的方式,用於作為JSON物件在各方之間安全地傳輸資訊。該資訊可以被驗證和信任,因為它是數字簽名的。
一、跨域認證的問題
HTTP協議是無狀態的,也就是說,如果我們已經認證了一個使用者,那麼他下一次請求的時候,伺服器不知道我是誰,我們必須再次認證。
網際網路服務離不開使用者認證。一般流程是下面這樣。
1、使用者向伺服器傳送使用者名稱和密碼。
2、伺服器驗證通過後,在當前對話(session)裡面儲存相關資料,比如使用者角色、登入時間等等。
3、伺服器向使用者返回一個 session_id,寫入使用者的 Cookie。
4、使用者隨後的每一次請求,都會通過 Cookie,將session_id 傳回伺服器。
5、伺服器收到 session_id,找到前期儲存的資料,由此得知使用者的身份。
這種模式的問題在於,擴充套件性(scaling)不好。單機當然沒有問題,如果是伺服器叢集,或者是跨域的服務導向架構,就要求 session 資料共享,每臺伺服器都能夠讀取 session。
舉例來說,A 網站和 B 網站是同一家公司的關聯服務。現在要求,使用者只要在其中一個網站登入,再訪問另一個網站就會自動登入,請問怎麼實現?
一種解決方案是 session 資料持久化,寫入資料庫或別的持久層。各種服務收到請求後,都向持久層請求資料。這種方案的優點是架構清晰,缺點是工程量比較大。另外,持久層萬一掛了,就會單點失敗。
另一種方案是伺服器索性不儲存 session 資料了,所有資料都儲存在客戶端,每次請求都發回伺服器。JWT 就是這種方案的一個代表。
二、JWT 的原理
JWT 的原理是,伺服器認證以後,生成一個 JSON 物件,發回給使用者,就像下面這樣。
{
“姓名”: “張三”,
“角色”: “管理員”,
“到期時間”: “2018年7月1日0點0分”
}
以後,使用者與服務端通訊的時候,都要發回這個 JSON 物件。伺服器完全只靠這個物件認定使用者身份。為了防止使用者篡改資料,伺服器在生成這個物件的時候,會加上簽名。伺服器就不儲存任何 session 資料了,也就是說,伺服器變成無狀態了,從而比較容易實現擴充套件。
三、JWT 的資料結構
實際的 JWT 大概就像下面這樣。
eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
它是一個很長的字串,中間用點(.)分隔成三個部分。
JWT 的三個部分依次如下。
Header(頭部)
Payload(負載)
Signature(簽名)
寫成一行,就是下面的樣子。
Header.Payload.Signature
下面依次介紹這三個部分。
1、 Header
Header 部分是一個 JSON 物件,描述 JWT 的後設資料,通常是下面的樣子。
{
“alg”: “HS256”,
“typ”: “JWT”
}
上面程式碼中,alg屬性表示簽名的演算法(algorithm),預設是 HMAC SHA256(寫成HS256);typ屬性表示這個令牌(token)的型別(type),JWT 令牌統一寫為JWT。
最後,將上面的 JSON 物件使用 Base64URL 演算法(詳見後文)轉成字串。
2、Payload
Payload 部分也是一個 JSON 物件,用來存放實際需要傳遞的資料。JWT 規定了7個官方欄位,供選用。
iss (issuer):簽發人
exp (expiration time):過期時間
sub (subject):主題 aud
(audience):受眾
nbf (Not Before):生效時間
iat (Issued At):簽發時間
jti (JWT ID):編號
除了官方欄位,你還可以在這個部分定義私有欄位,下面就是一個例子。
{
“sub”: “1234567890”,
“name”: “John Doe”,
“admin”: true
}
注意,JWT 預設是不加密的,任何人都可以讀到,所以不要把祕密資訊放在這個部分。
這個 JSON 物件也要使用 Base64URL 演算法轉成字串。
3、 Signature
Signature 部分是對前兩部分的簽名,防止資料篡改。
首先,需要指定一個金鑰(secret)。這個金鑰只有伺服器才知道,不能洩露給使用者。然後,使用 Header 裡面指定的簽名演算法(預設是 HMAC SHA256),按照下面的公式產生簽名。
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),
secret)
算出簽名以後,把 Header、Payload、Signature 三個部分拼成一個字串,每個部分之間用"點"(.)分隔,就可以返回給使用者。
4、Base64URL
前面提到,Header 和 Payload 串型化的演算法是 Base64URL。這個演算法跟 Base64 演算法基本類似,但有一些小的不同。
JWT 作為一個令牌(token),有些場合可能會放到 URL(比如 api.example.com/?token=xxx)。 Base64 有三個字元+、/和=,在 URL 裡面有特殊含義,所以要被替換掉:=被省略、+替換成-,/替換成_ 。這就是 Base64URL 演算法。
四、JWT 的使用方式
在認證的時候,當使用者用他們的憑證成功登入以後,一個JSON Web Token將會被返回。此後,token就是使用者憑證了,你必須非常小心以防止出現安全問題。一般而言,你儲存令牌的時候不應該超過你所需要它的時間。
客戶端收到伺服器返回的 JWT,可以儲存在 Cookie 裡面,也可以儲存在 localStorage。
此後,客戶端每次與伺服器通訊,都要帶上這個 JWT。你可以把它放在 Cookie 裡面自動傳送,但是這樣不能跨域,所以更好的做法是放在 HTTP 請求的頭資訊Authorization欄位裡面,因為它不使用cookie。
Authorization: Bearer token
另一種做法是,跨域的時候,JWT 就放在 POST 請求的資料體裡面。
五、JWT 的幾個特點:
1、JWT 預設是不加密,但也是可以加密的。生成原始 Token 以後,可以用金鑰再加密一次。
2、JWT 不加密的情況下,不能將私密資料寫入 JWT。
3、JWT 不僅可以用於認證,也可以用於交換資訊。有效使用 JWT,可以降低伺服器查詢資料庫的次數。
4、JWT 的最大缺點是,由於伺服器不儲存 session 狀態,因此無法在使用過程中廢止某個 token,或者更改 token 的許可權。也就是說,一旦 JWT 簽發了,在到期之前就會始終有效,除非伺服器部署額外的邏輯。
5、JWT 本身包含了認證資訊,一旦洩露,任何人都可以獲得該令牌的所有許可權。為了減少盜用,JWT 的有效期應該設定得比較短。對於一些比較重要的許可權,使用時應該再次對使用者進行認證。
6、為了減少盜用,JWT 不應該使用 HTTP 協議明碼傳輸,要使用 HTTPS 協議傳輸。
六、 JWT與Session的差異
1、相同點是,它們都是儲存使用者資訊;然而,Session是在伺服器端的,而JWT是在客戶端的。
2、Session方式儲存使用者資訊的最大問題在於要佔用大量伺服器記憶體,增加伺服器的開銷。
3、而JWT方式將使用者狀態分散到了客戶端中,可以明顯減輕服務端的記憶體壓力。
4、Session的狀態是儲存在伺服器端,客戶端只有session id;而Token的狀態是儲存在客戶端。
七、基於Token的身份認證流程
基於Token的身份認證是無狀態的,伺服器或者Session中不會儲存任何使用者資訊。沒有會話資訊意味著應用程式可以根據需要擴充套件和新增更多的機器,而不必擔心使用者登入的位置。
雖然這一實現可能會有所不同,但其主要流程如下:
1、使用者攜帶使用者名稱和密碼請求訪問
2、伺服器校驗使用者憑據
3、應用提供一個token給客戶端
4、客戶端儲存token,並且在隨後的每一次請求中都帶著它
5、 伺服器校驗token並返回資料
注意:
每一次請求都需要token。Token應該放在請求header中。
八、使用Token的優點
1、無狀態和可擴充套件性:Tokens儲存在客戶端。完全無狀態,可擴充套件。我們的負載均衡器可以將使用者傳遞到任意伺服器,因為在任何地方都沒有狀態或會話資訊。
2、安全:Token不是Cookie。(The token, not a cookie.)每次請求的時候Token都會被髮送。而且,由於沒有Cookie被髮送,還有助於防止CSRF攻擊。即使在你的實現中將token儲存到客戶端的Cookie中,這個Cookie也只是一種儲存機制,而非身份認證機制。沒有基於會話的資訊可以操作,因為我們沒有會話。
3、token在一段時間以後會過期,這個時候使用者需要重新登入。這有助於我們保持安全。還有一個概念叫token撤銷,它允許我們根據相同的授權許可使特定的token甚至一組token無效。
九、JWT與OAuth的區別
1、OAuth2是一種授權框架 ,JWT是一種認證協議。
2、無論使用哪種方式切記用HTTPS來保證資料的安全性
3、OAuth2用在使用第三方賬號登入的情況(比如使用weibo, qq, github登入某個app),而JWT是用在前後端分離, 需要簡單的對後臺API進行保護時使用。
相關文章
- JSON Web Token(JWT) 簡介JSONWebJWT
- 第68篇 jwt的簡單介紹JWT
- JWT簡介:從Session到Token的轉變JWTSession
- 會話、cookie、JWT、令牌、SSO和OAuth 2.0簡介會話CookieJWTOAuth
- Python JWT 介紹和使用PythonJWT
- JWT簡單瞭解JWT
- jwt 就是這麼簡單JWT
- simple-jwt的簡單使用JWT
- 簡介
- Jira使用簡介 HP ALM使用簡介
- Spring Boot 最簡單整合 Shiro+JWT 方式Spring BootJWT
- JWT在專案中的簡單應用JWT
- Spring-cloud學習筆記---分散式架構統一認證主流實現方案JWT簡介SpringCloud筆記分散式架構JWT
- BookKeeper 介紹(1)--簡介
- ggml 簡介
- PCIe簡介
- valgrind簡介
- SpringMVC簡介SpringMVC
- HTML 簡介HTML
- 核心簡介
- DPDK簡介
- Docker簡介Docker
- SpotBugs 簡介
- webservice簡介Web
- OME 簡介
- Spring 簡介Spring
- pytorch簡介PyTorch
- 【QCustomPlot】簡介
- DuckDB簡介
- SDL簡介
- swagger簡介Swagger
- MongoDb簡介MongoDB
- RabbitMQ簡介MQ
- JetCache 簡介
- JavaParser 簡介Java
- SSHJ 簡介
- Redpanda簡介
- Swoole 簡介