更新時間:2018年08月06日15時13分 來源:傳智播客 瀏覽次數(shù):
JSON Web Token(縮寫 JWT)是目前最流行的跨域認(rèn)證解決方案,本文介紹它的原理和用法。
一、跨域認(rèn)證的問題
互聯(lián)網(wǎng)服務(wù)離不開用戶認(rèn)證。一般流程是下面這樣。
1、用戶向服務(wù)器發(fā)送用戶名和密碼。
2、服務(wù)器驗證通過后,在當(dāng)前對話(session)里面保存相關(guān)數(shù)據(jù),比如用戶角色、登錄時間等等。
3、服務(wù)器向用戶返回一個 session_id,寫入用戶的 Cookie。
4、用戶隨后的每一次請求,都會通過 Cookie,將 session_id 傳回服務(wù)器。
5、服務(wù)器收到 session_id,找到前期保存的數(shù)據(jù),由此得知用戶的身份。
這種模式的問題在于,擴展性(scaling)不好。單機當(dāng)然沒有問題,如果是服務(wù)器集群,或者是跨域的服務(wù)導(dǎo)向架構(gòu),就要求 session 數(shù)據(jù)共享,每臺服務(wù)器都能夠讀取 session。
舉例來說,A 網(wǎng)站和 B 網(wǎng)站是同一家公司的關(guān)聯(lián)服務(wù)?,F(xiàn)在要求,用戶只要在其中一個網(wǎng)站登錄,再訪問另一個網(wǎng)站就會自動登錄,請問怎么實現(xiàn)?
一種解決方案是 session 數(shù)據(jù)持久化,寫入數(shù)據(jù)庫或別的持久層。各種服務(wù)收到請求后,都向持久層請求數(shù)據(jù)。這種方案的優(yōu)點是架構(gòu)清晰,缺點是工程量比較大。另外,持久層萬一掛了,就會單點失敗。
另一種方案是服務(wù)器索性不保存 session 數(shù)據(jù)了,所有數(shù)據(jù)都保存在客戶端,每次請求都發(fā)回服務(wù)器。JWT 就是這種方案的一個代表。
二、JWT 的原理
JWT 的原理是,服務(wù)器認(rèn)證以后,生成一個 JSON 對象,發(fā)回給用戶,就像下面這樣。
{
"姓名": "張三",
"角色": "管理員",
"到期時間": "2018年7月1日0點0分"
}
以后,用戶與服務(wù)端通信的時候,都要發(fā)回這個 JSON 對象。服務(wù)器完全只靠這個對象認(rèn)定用戶身份。為了防止用戶篡改數(shù)據(jù),服務(wù)器在生成這個對象的時候,會加上簽名(詳見后文)。
服務(wù)器就不保存任何 session 數(shù)據(jù)了,也就是說,服務(wù)器變成無狀態(tài)了,從而比較容易實現(xiàn)擴展。
三、JWT 的數(shù)據(jù)結(jié)構(gòu)
實際的 JWT 大概就像下面這樣。
它是一個很長的字符串,中間用點(.)分隔成三個部分。注意,JWT 內(nèi)部是沒有換行的,這里只是為了便于展示,將它寫成了幾行。
JWT 的三個部分依次如下。
Header(頭部)
Payload(負(fù)載)
Signature(簽名)
寫成一行,就是下面的樣子。
Header.Payload.Signature
下面依次介紹這三個部分。
3.1 Header
Header 部分是一個 JSON 對象,描述 JWT 的元數(shù)據(jù),通常是下面的樣子。
{
"alg": "HS256",
"typ": "JWT"
}
上面代碼中,alg屬性表示簽名的算法(algorithm),默認(rèn)是 HMAC SHA256(寫成 HS256);typ屬性表示這個令牌(token)的類型(type),JWT 令牌統(tǒng)一寫為JWT。
最后,將上面的 JSON 對象使用 Base64URL 算法(詳見后文)轉(zhuǎn)成字符串。
3.2 Payload
Payload 部分也是一個 JSON 對象,用來存放實際需要傳遞的數(shù)據(jù)。JWT 規(guī)定了7個官方字段,供選用。
iss (issuer):簽發(fā)人
exp (expiration time):過期時間
sub (subject):主題
aud (audience):受眾
nbf (Not Before):生效時間
iat (Issued At):簽發(fā)時間
jti (JWT ID):編號
除了官方字段,你還可以在這個部分定義私有字段,下面就是一個例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意,JWT 默認(rèn)是不加密的,任何人都可以讀到,所以不要把秘密信息放在這個部分。
這個 JSON 對象也要使用 Base64URL 算法轉(zhuǎn)成字符串。
3.3 Signature
Signature 部分是對前兩部分的簽名,防止數(shù)據(jù)篡改。
首先,需要指定一個密鑰(secret)。這個密鑰只有服務(wù)器才知道,不能泄露給用戶。然后,使用 Header 里面指定的簽名算法(默認(rèn)是 HMAC SHA256),按照下面的公式產(chǎn)生簽名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出簽名以后,把 Header、Payload、Signature 三個部分拼成一個字符串,每個部分之間用"點"(.)分隔,就可以返回給用戶。
3.4 Base64URL
前面提到,Header 和 Payload 串型化的算法是 Base64URL。這個算法跟 Base64 算法基本類似,但有一些小的不同。
JWT 作為一個令牌(token),有些場合可能會放到 URL(比如 api.example.com/?token=xxx)。Base64 有三個字符+、/和=,在 URL 里面有特殊含義,所以要被替換掉:=被省略、+替換成-,/替換成_ 。這就是 Base64URL 算法。
四、JWT 的使用方式
客戶端收到服務(wù)器返回的 JWT,可以儲存在 Cookie 里面,也可以儲存在 localStorage。
此后,客戶端每次與服務(wù)器通信,都要帶上這個 JWT。你可以把它放在 Cookie 里面自動發(fā)送,但是這樣不能跨域,所以更好的做法是放在 HTTP 請求的頭信息Authorization字段里面。
Authorization: Bearer
另一種做法是,跨域的時候,JWT 就放在 POST 請求的數(shù)據(jù)體里面。
五、JWT 的幾個特點
(1)JWT 默認(rèn)是不加密,但也是可以加密的。生成原始 Token 以后,可以用密鑰再加密一次。
(2)JWT 不加密的情況下,不能將秘密數(shù)據(jù)寫入 JWT。
(3)JWT 不僅可以用于認(rèn)證,也可以用于交換信息。有效使用 JWT,可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。
(4)JWT 的最大缺點是,由于服務(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é)議傳輸。
作者:傳智播客Python培訓(xùn)學(xué)院
首發(fā):http://python.itcast.cn/