今天就跟大家聊聊有關(guān)如何在Node中利用koa2實(shí)現(xiàn)一個(gè)JWT鑒權(quán)功能,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
全稱JSON Web Token
, 是目前最流行的跨域認(rèn)證解決方案?;镜膶?shí)現(xiàn)是服務(wù)端認(rèn)證后,生成一個(gè)JSON
對(duì)象,發(fā)回給用戶。用戶與服務(wù)端通信的時(shí)候,都要發(fā)回這個(gè)JSON
對(duì)象。
該JSON
類似如下:
{ "姓名": "張三", "角色": "管理員", "到期時(shí)間": "2018年7月1日0點(diǎn)0分" }
先看下一般的認(rèn)證流程,基于session_id
和Cookie
實(shí)現(xiàn)
1、用戶向服務(wù)器發(fā)送用戶名和密碼。
2、服務(wù)器驗(yàn)證通過后,在當(dāng)前對(duì)話(session
)里面保存相關(guān)數(shù)據(jù),比如用戶角色、登錄時(shí)間等等。
3、服務(wù)器向用戶返回一個(gè)session_id
,寫入用戶的Cookie
。
4、用戶隨后的每一次請(qǐng)求,都會(huì)通過Cookie
,將session_id
傳回服務(wù)器。
5、服務(wù)器收到session_id
,找到前期保存的數(shù)據(jù),由此得知用戶的身份。
但是這里有一個(gè)大的問題, 假如是服務(wù)器集群,則要求 session 數(shù)據(jù)共享,每臺(tái)服務(wù)器都能夠讀取 session 。這個(gè)實(shí)現(xiàn)成本是比較大的。
而JWT
轉(zhuǎn)換了思路,將JSON
數(shù)據(jù)返回給前端的,前端再次請(qǐng)求時(shí)候?qū)?shù)據(jù)發(fā)送到后端,后端進(jìn)行驗(yàn)證。也就是服務(wù)器是無狀態(tài)的,所以更加容易拓展。
JWT
的三個(gè)部分依次如下:
Header
(頭部),類似如下
{ "alg": "HS256", "typ": "JWT" }
alg
屬性表示簽名的算法(algorithm
),默認(rèn)是HMAC SHA256
(寫成HS256
)。typ
屬性表示這個(gè)令牌(token
)的類型(type
),JWT
令牌統(tǒng)一寫為JWT
Payload
(負(fù)載)。也是一個(gè)JSON
,用來存放實(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)
當(dāng)然也可以自定義私有字段。 但是要注意,JWT 默認(rèn)是不加密的,任何人都可以讀到,所以不要把秘密信息放在這個(gè)部分。
Signature
(簽名)。Signature
部分是對(duì)前兩部分的簽名,防止數(shù)據(jù)篡改。首先,需要指定一個(gè)密鑰(secret
)。這個(gè)密鑰只有服務(wù)器才知道,不能泄露給用戶。然后,使用Header
里面指定的簽名算法(默認(rèn)是HMAC SHA256
),按照下面的公式產(chǎn)生簽名。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
算出簽名以后,把Header
、Payload
、Signature
三個(gè)部分拼成一個(gè)字符串,每個(gè)部分之間用"點(diǎn)"(.)分隔,就可以返回給用戶。如下所示
JWT 的安全
JWT
默認(rèn)是不加密,但也是可以加密的。JWT
不加密的情況下,不能將秘密數(shù)據(jù)寫入JWT
JWT
本身包含了認(rèn)證信息,一旦泄露,任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用,JWT
的有效期應(yīng)該設(shè)置得比較短。對(duì)于一些比較重要的權(quán)限,使用時(shí)應(yīng)該再次對(duì)用戶進(jìn)行認(rèn)證
為了減少盜用,JWT
不應(yīng)該使用HTTP
協(xié)議明碼傳輸,要使用HTTPS
協(xié)議傳輸
說完理論知識(shí),我們來看下如何實(shí)現(xiàn)JWT
,大致的流程如下:
首先,用戶登錄后服務(wù)端根據(jù)用戶信息生成并返回token
給到客戶端,前端在下次請(qǐng)求中把token
帶給服務(wù)器,服務(wù)器驗(yàn)證有效后,返回?cái)?shù)據(jù)。無效的話,返回401
狀態(tài)碼
這里我們用Node
實(shí)現(xiàn),主要用到的兩個(gè)庫有
jsonwebtoken ,可以生成token
,校驗(yàn)等
koa-jwt 中間件 對(duì)jsonwebtoken
進(jìn)一步的封裝,主要用來校驗(yàn)token
發(fā)現(xiàn)官方目前沒有一個(gè)快速搭建koa
項(xiàng)目的方式,像Vue-cli
一樣。(可能是搭建一個(gè)koa
項(xiàng)目成本也很低)。但懶人的我,還是找到了一個(gè)工具 ——koa-generator ,使用也相對(duì)簡單,如下
安裝
npm install -g koa-generator
koa2 my-project
新建一個(gè)叫做my-project
的koa2
項(xiàng)目
cd my-project
和npm install
啟動(dòng)項(xiàng)目npm start
打開localhost:3000
為了演示方便,我這里直接定義了變量userList
存儲(chǔ)用戶的信息,真實(shí)應(yīng)該是存放在數(shù)據(jù)庫中的。
const crypto = require("crypto"), jwt = require("jsonwebtoken"); // TODO:使用數(shù)據(jù)庫 // 這里應(yīng)該是用數(shù)據(jù)庫存儲(chǔ),這里只是演示用 let userList = []; class UserController { // 用戶登錄 static async login(ctx) { const data = ctx.request.body; if (!data.name || !data.password) { return ctx.body = { code: "000002", message: "參數(shù)不合法" } } const result = userList.find(item => item.name === data.name && item.password === crypto.createHash('md5').update(data.password).digest('hex')) if (result) { const token = jwt.sign( { name: result.name }, "Gopal_token", // secret { expiresIn: 60 * 60 } // 60 * 60 s ); return ctx.body = { code: "0", message: "登錄成功", data: { token } }; } else { return ctx.body = { code: "000002", message: "用戶名或密碼錯(cuò)誤" }; } } } module.exports = UserController;
通過jsonwebtoken
的sign
方法生成一個(gè)token
。該方法第一個(gè)參數(shù)指的是Payload
(負(fù)載),用于編碼后存儲(chǔ)在token
中的數(shù)據(jù),也是校驗(yàn)token
后可以拿到的數(shù)據(jù)。第二個(gè)是秘鑰,服務(wù)端特有,注意校驗(yàn)的時(shí)候要相同才能解碼,而且是保密的 ,一般而言,好是定公共的變量,這里只是演示方便,直接寫死。第三個(gè)參數(shù)是option
,可以定義token
過期時(shí)間
前端登錄獲取到token
后可以存儲(chǔ)到cookie
中也可以存放在localStorage
中。這里我直接存到了localStorage
中
login() { this.$axios .post("/api/login", { ...this.ruleForm, }) .then(res => { if (res.code === "0") { this.$message.success('登錄成功'); localStorage.setItem("token", res.data.token); this.$router.push("/"); } else { this.$message(res.message); } }); }
封裝axios
的攔截器,每次請(qǐng)求的時(shí)候把token
帶在請(qǐng)求頭發(fā)送給服務(wù)器進(jìn)行驗(yàn)證。這里如果之前放在Cookie
中,可以讓它自動(dòng)發(fā)送,但是這樣不能跨域。所以推薦做法是放在 HTTP 請(qǐng)求頭Authorization
中,注意這里的Authorization
的設(shè)置,前面要加上Bearer
。詳情可以見 Bearer Authentication
// axios 請(qǐng)求攔截器處理請(qǐng)求數(shù)據(jù) axios.interceptors.request.use(config => { const token = localStorage.getItem('token'); config.headers.common['Authorization'] = 'Bearer ' + token; // 留意這里的 Authorization return config; })
使用koa-jwt
中間件進(jìn)行驗(yàn)證,方式比較簡單,如下所示
// 錯(cuò)誤處理 app.use((ctx, next) => { return next().catch((err) => { if(err.status === 401){ ctx.status = 401; ctx.body = 'Protected resource, use Authorization header to get access\n'; }else{ throw err; } }) }) // 注意:放在路由前面 app.use(koajwt({ secret: 'Gopal_token' }).unless({ // 配置白名單 path: [/\/api\/register/, /\/api\/login/] })) // routes app.use(index.routes(), index.allowedMethods()) app.use(users.routes(), users.allowedMethods())
需要注意的是以下幾點(diǎn):
secret
必須和sign
時(shí)候保持一致
可以通過unless
配置接口白名單,也就是哪些URL
可以不用經(jīng)過校驗(yàn),像登陸/注冊(cè)都可以不用校驗(yàn)
校驗(yàn)的中間件需要放在需要校驗(yàn)的路由前面,無法對(duì)前面的URL
進(jìn)行校驗(yàn)
如果直接訪問需要登錄的接口,則會(huì)401
先注冊(cè),后登錄,不然會(huì)提示用戶名或者密碼錯(cuò)誤
登錄后帶上Authorization
,可以正常訪問,返回200
以及正確的數(shù)據(jù)
看完上述內(nèi)容,你們對(duì)如何在Node中利用koa2實(shí)現(xiàn)一個(gè)JWT鑒權(quán)功能有進(jìn)一步的了解嗎?如果還想了解更多知識(shí)或者相關(guān)內(nèi)容,請(qǐng)關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道,感謝大家的支持。
網(wǎng)站名稱:如何在Node中利用koa2實(shí)現(xiàn)一個(gè)JWT鑒權(quán)功能-創(chuàng)新互聯(lián)
鏈接地址:http://jinyejixie.com/article16/dicpgg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站排名、App開發(fā)、電子商務(wù)、企業(yè)建站、定制網(wǎng)站、響應(yīng)式網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容