在系統(tǒng)級(jí)項(xiàng)目開發(fā)時(shí)常常會(huì)遇到一個(gè)問題就是鑒權(quán)，身為一個(gè)前端來說可能我們距離鑒權(quán)可能比較遠(yuǎn)，一般來說我們也只是去應(yīng)用，并沒有對(duì)權(quán)限這一部分進(jìn)行深入的理解。
什么是鑒權(quán)
鑒權(quán)：是指驗(yàn)證用戶是否擁有訪問系統(tǒng)的權(quán)利。傳統(tǒng)的鑒權(quán)是通過密碼來驗(yàn)證的。這種方式的前提是，每個(gè)獲得密碼的用戶都已經(jīng)被授權(quán)。在建立用戶時(shí)，就為此用戶分配一個(gè)密碼，用戶的密碼可以由管理員指定，也可以由用戶自行申請(qǐng)。這種方式的弱點(diǎn)十分明顯：一旦密碼被偷或用戶遺失密碼，情況就會(huì)十分麻煩，需要管理員對(duì)用戶密碼進(jìn)行重新修改，而修改密碼之前還要人工驗(yàn)證用戶的合法身份。 -- 節(jié)選自百度百科
上述簡單扼要的說明了一下鑒權(quán)的概念，但是這也只是簡單的鑒權(quán)，也是項(xiàng)目中最最常見的及安全形式了，但是對(duì)于后端鑒權(quán)又是如何去做的，我們?nèi)允且粺o所知，一般來說對(duì)于后端來說，鑒權(quán)最長見的方式分為三種：
這種授權(quán)方式是瀏覽器遵守http協(xié)議實(shí)現(xiàn)的基本授權(quán)方式,HTTP協(xié)議進(jìn)行通信的過程中，HTTP協(xié)議定義了基本認(rèn)證認(rèn)證允許HTTP服務(wù)器對(duì)客戶端進(jìn)行用戶身份證的方法。接下來就一一介紹一下這三種鑒權(quán)方式。
Session/Cookie
Cookie是一個(gè)非常具體的東西，指的就是瀏覽器里面能永久存儲(chǔ)的一種數(shù)據(jù)，僅僅是瀏覽器實(shí)現(xiàn)的一種數(shù)據(jù)存儲(chǔ)功能。Cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把Cookie以KV形式保存到某個(gè)目錄下的文本文件內(nèi)，下一次請(qǐng)求同一網(wǎng)站時(shí)會(huì)把該Cookie發(fā)送給服務(wù)器。由于Cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保Cookie不會(huì)被惡意使用，同時(shí)不會(huì)占據(jù)太多磁盤空間，所以每個(gè)域的Cookie數(shù)量是有限的。
Cookie.js
const Http = require("http");const app = Http.createServer((req,res) => { if(req.url === "/favicon.ico"){ return; }else{ res.setHeader("Set-Cookie","cx=Segmentfault"); res.end("hello cookie"); };});app.listen(3000);使用node Cookie.js運(yùn)行上面代碼，等程序啟動(dòng)后訪問http://localhost:3000/，就可以看到hello cookie字樣，這樣的話就代表該服務(wù)已經(jīng)啟動(dòng)了。若想查看到到我們所設(shè)置的Cookie，首先觀察一下在Network中Response Headers中，可以看到我們所寫的Set-Cookie屬性，當(dāng)我們?cè)L問http://localhost:3000/的時(shí)候，當(dāng)瀏覽器接收到Set-Cookie這個(gè)屬性的時(shí)候，瀏覽器會(huì)根據(jù)其內(nèi)部約定，并在其瀏覽器內(nèi)部對(duì)其cookie進(jìn)行存儲(chǔ)，打開瀏覽器控制臺(tái)，在Application中找到Cookies中找到相對(duì)應(yīng)的域名，就可以看到我們所設(shè)置的cookie值了。當(dāng)在同域的情況下，當(dāng)再次請(qǐng)求數(shù)據(jù)的時(shí)候?yàn)g覽器會(huì)默認(rèn)發(fā)送cookie在該請(qǐng)求中，一起發(fā)送給后端。為了證實(shí)上面的說法，刷新一下http://localhost:3000/頁面，在控制臺(tái)Network找到Request Headers中可以看到Cookie: cx=Segmentfault屬性，既然發(fā)送給服務(wù)端之后，相應(yīng)的在后端也是可以接收到該Cookie的，修改一下上面的例子：
const Http = require("http");const app = Http.createServer((req,res) => { if(req.url === "/favicon.ico"){ return; }else{ console.log("cookie",req.headers.cookie) res.setHeader("Set-Cookie","cx=Segmentfault"); res.end("hello cookie"); };});app.listen(3000);在接收到訪問的時(shí)候，就可以接收到了cx=Segmentfault，如果說現(xiàn)在這份Cookie是一份加密的數(shù)據(jù)的話，里面包含一些用戶信息，在通過前后端進(jìn)行交互之后，當(dāng)客戶端再次請(qǐng)求服務(wù)端的時(shí)候，服務(wù)端拿到相對(duì)應(yīng)的Cookie并對(duì)其進(jìn)行解密，對(duì)其中用戶的信息進(jìn)行鑒權(quán)處理就可以了。
服務(wù)端通過Set-Cookie在Response Headers設(shè)置了一段加密數(shù)據(jù)，客戶端接收到了其相對(duì)應(yīng)的數(shù)據(jù)之后，瀏覽器對(duì)其進(jìn)行存儲(chǔ)，當(dāng)可客戶端再次發(fā)送請(qǐng)求的時(shí)候，會(huì)攜帶已有的Cookie在Request Headers中一并發(fā)送給服務(wù)端，服務(wù)端解密數(shù)據(jù)完成鑒權(quán)，由此可以得出Cookie是服務(wù)端存儲(chǔ)在客服端的狀態(tài)標(biāo)志，再由客戶端發(fā)送給服務(wù)端，由服務(wù)端解析。Cookie在使用中必須是同域的情況下才可以，一般常用的是在MVC這種開發(fā)形式中很常用。
說了半天Cookie，但是對(duì)于Session卻只字未提，接下來就介紹一下Session，Session從字面上講，就是會(huì)話。這個(gè)就類似于你和一個(gè)人交談，你怎么知道當(dāng)前和你交談的是張三而不是李四呢？對(duì)方肯定有某種特征（長相等）表明他就是張三。Session也是類似的道理，服務(wù)器要知道當(dāng)前發(fā)請(qǐng)求給自己的是誰。為了做這種區(qū)分，服務(wù)器就要給每個(gè)客戶端分配不同的身份標(biāo)識(shí)，然后客戶端每次向服務(wù)器發(fā)請(qǐng)求的時(shí)候，都帶上這個(gè)身份標(biāo)識(shí)，服務(wù)器就知道這個(gè)請(qǐng)求來自于誰了。至于客戶端怎么保存這個(gè)身份標(biāo)識(shí)，可以有很多種方式，對(duì)于瀏覽器客戶端，大家都默認(rèn)采用Cookie的方式。
const Http = require("http");let session = {};const app = Http.createServer((req,res) => { const sessionKey = "uId"; if(req.url === "/favicon.ico"){ return; }else{ const uId = parseInt(Math.random() * 10e10); const cookie = req.headers.cookie; if(cookie && cookie.indexOf(sessionKey) !== -1){ let _uId = cookie.split("=")[1]; res.end(`${session[_uId].name} Come back`); } else{ res.setHeader("Set-Cookie",`${sessionKey}=${uId}`); session[uId] = {"name":"Aaron"}; res.end("hello cookie"); } };});app.listen(3000);代碼中解析cookie只是用了和很簡單的方式，只是為了完成Dome而已，在實(shí)際項(xiàng)目中獲取cookie比這個(gè)要復(fù)雜很多。
Session/Cookie認(rèn)證主要分四步：
seesion，然后保存seesion(我們可以將seesion保存在內(nèi)存中，也可以保存在redis中，推薦使用后者)，然后給這個(gè)session生成一個(gè)唯一的標(biāo)識(shí)字符串,然后在響應(yīng)頭中種下這個(gè)唯一標(biāo)識(shí)字符串。sid進(jìn)行加密處理，服務(wù)端會(huì)根據(jù)這個(gè)secret密鑰進(jìn)行解密。（非必需步驟）sid保存在本地cookie中，瀏覽器在下次http請(qǐng)求的時(shí)候，請(qǐng)求頭中會(huì)帶上該域名下的cookie信息，cookie中的sid，然后根據(jù)這個(gè)sid去找服務(wù)器端保存的該客戶端的session，然后判斷該請(qǐng)求是否合法。
利用服務(wù)器端的session和瀏覽器端的cookie來實(shí)現(xiàn)前后端的認(rèn)證，由于http請(qǐng)求時(shí)是無狀態(tài)的，服務(wù)器正常情況下是不知道當(dāng)前請(qǐng)求之前有沒有來過，這個(gè)時(shí)候我們?nèi)绻涗洜顟B(tài)，就需要在服務(wù)器端創(chuàng)建一個(gè)會(huì)話(seesion),將同一個(gè)客戶端的請(qǐng)求都維護(hù)在各自得會(huì)會(huì)話中，每當(dāng)請(qǐng)求到達(dá)服務(wù)器端的時(shí)候，先去查一下該客戶端有沒有在服務(wù)器端創(chuàng)建seesion，如果有則已經(jīng)認(rèn)證成功了，否則就沒有認(rèn)證。
與redis結(jié)合使用：
const koa = require("koa");const session = require("koa-session");const redisStore = require("koa-redis");const redis = require("redis");const wrapper = require("co-redis");const app = new koa();const redisClient = redis.createClient(6379,"localhost");const client = wrapper(redisClient);// 類似于密鑰app.keys = ["Aaron"];const SESSION_CONFIG = { // 所設(shè)置的session的key key:"sId", // 最大有效期 maxAge:8640000, // 是否防止js讀取 httpOnly:true, // cookie二次簽名 signed:true, // 存儲(chǔ)方式 stroe:redisStore({client})};app.use(session(SESSION_CONFIG,app));app.use((ctx) => { redisClient.keys("*",(err,keys) => { keys.forEach(key => { redisClient.get(key,(err,val) => { console.log(val); }); }) }) if(ctx.path === "/favicon.ico") return; let n = ctx.session.count || 0; ctx.session.count = ++n; ctx.body = `第${n}次訪問`});app.listen(3000);雖然Session/Cookie可以解決鑒權(quán)問題，但是會(huì)有很大的問題，對(duì)于服務(wù)端來說說是一個(gè)巨大的開銷，嚴(yán)重的限制了服務(wù)器擴(kuò)展能力，比如說我用兩個(gè)機(jī)器組成了一個(gè)集群，小F通過機(jī)器A登錄了系統(tǒng)，那sessionId會(huì)保存在機(jī)器A上，假設(shè)小F的下一次請(qǐng)求被轉(zhuǎn)發(fā)到機(jī)器B怎么辦？機(jī)器B可沒有小F的sessionId，有時(shí)候會(huì)采用一點(diǎn)小伎倆：session sticky，就是讓小F的請(qǐng)求一直粘連在機(jī)器A上，但是這也不管用，要是機(jī)器A掛掉了， 還得轉(zhuǎn)到機(jī)器B去。那只好做session的復(fù)制了，把sessionId在兩個(gè)機(jī)器之間搬來搬去，再好的服務(wù)器也經(jīng)不起這樣的折騰。
Token或Jwt
在計(jì)算機(jī)身份認(rèn)證中是令牌（臨時(shí)）的意思，在詞法分析中是標(biāo)記的意思。一般作為邀請(qǐng)、登錄系統(tǒng)使用。現(xiàn)在前后端分離火熱，Token混的風(fēng)生水起，很多項(xiàng)目開發(fā)過程中都會(huì)用到Token，其實(shí)Token是一串字符串，通常因?yàn)樽鳛殍b權(quán)憑據(jù)，最常用的使用場景是API鑒權(quán)。
客戶端使用用戶名跟密碼請(qǐng)求登錄服務(wù)端收到請(qǐng)求，去驗(yàn)證用戶名與密碼驗(yàn)證成功后，服務(wù)端會(huì)簽發(fā)一個(gè)Token，再把這個(gè)Token發(fā)送給客戶端客戶端收到Token以后可以把它存儲(chǔ)起來，比如放在Cookie里或者Local Storage里客戶端每次向服務(wù)端請(qǐng)求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的Token服務(wù)端收到請(qǐng)求，然后去驗(yàn)證客戶端請(qǐng)求里面帶著的Token，如果驗(yàn)證成功，就向客戶端返回請(qǐng)求的數(shù)據(jù)
示例：
前端
<!DOCTYPE html><html lang="en"><head><meta charset="UTF-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta http-equiv="X-UA-Compatible" content="ie=edge"><script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script><script src="https://unpkg.com/axios/dist/axios.min.js"></script><title>Document</title></head><body><div id="app"> <div> <input type="text" v-model="username"> <input type="text" v-model="passwrold"> </div> <div> <button @click="login">登陸</button> <button @click="loginOut">退出</button> <button @click="getUserInfo">獲取用戶信息</button> </div> <div> <button @click="logs = []">清空日志</button> </div> <ul> <li v-for="(item,index) of logs" :key="index">{{item}}</li> </ul></div><script>axios.defaults.baseURL = "http://localhost:3000"http:// 請(qǐng)求攔截axios.interceptors.request.use((config) => { const token = localStorage.getItem("token"); if(token){ // 判斷是否存在token，如果存在的話 // 每次發(fā)起HTTP請(qǐng)求時(shí)在headers中添加token // Bearer是JWT的認(rèn)證頭部信息 config.headers["Authorization"] = `Bearer ${token}` } return config;},error => alert(error));// 響應(yīng)攔截axios.interceptors.response.use((res) => { app.logs.push(JSON.stringify(res.data)) return res;},error => alert(error));const app = new Vue({ el:"#app", data:{ username:"", passwrold:"", logs:[] }, methods:{ login() { let {username,passwrold} = this; axios.post("/users/login/token",{ username,passwrold }).then((res) => { localStorage.setItem("token",res.data.token) }) }, loginOut(){ axios.post("/users/logout").then((res) => { localStorage.removeItem("token") }) }, getUserInfo(){ axios.get("/users/get/user/info").then((res) => { console.log(res) }); } }})</script></body></html>后端：
const Koa = require("koa");const jwt = require("jsonwebtoken");const jwtAuth = require("koa-jwt");const Router = require('koa-router'); // koa 路由中間件const bodyParser = require("koa-bodyparser");const cors = require("koa2-cors");const app = new Koa();const router = new Router();// 密鑰const secret = "this is a secret";app.use(bodyParser());app.use(cors());router.post("/users/login/token",(ctx) => { const {body} = ctx.request; const {username} = body; ctx.body = { code:1, message:"登陸成功", body:{ username }, token:jwt.sign({ data:body, exp:Math.floor(Date.now() / 1000) + 60 * 60, },secret) }});router.post("/users/logout",(ctx) => { const {body} = ctx.request; ctx.body = { code:1, message:"退出成功" }})router.get("/users/get/user/info",jwtAuth({secret}),(ctx) => { // jwtAuth token參數(shù) console.log(ctx.state.user.data) ctx.body = { code:1, message:"成功", data:ctx.state.user.data }})app.use(router.routes());app.listen(3000);上面代碼用到了很多的依賴模塊，最關(guān)鍵的的是jsonwebtoken和koa-jwt，這兩個(gè)模塊一個(gè)是用來對(duì)token進(jìn)行加密，一個(gè)是用來對(duì)數(shù)據(jù)進(jìn)行解密的，同時(shí)在每次訪問需要保護(hù)的路由的時(shí)候需要使用jwtAuth對(duì)其進(jìn)行攔截處理，jwtAuth會(huì)根據(jù)其secret進(jìn)行數(shù)據(jù)解密，把解密的數(shù)據(jù)存放到ctx.state中，供用戶讀取。
有關(guān)jwt相關(guān)請(qǐng)查看深入理解令牌認(rèn)證機(jī)制詳細(xì)的解釋了其加密后數(shù)據(jù)token的構(gòu)成。
加密后的數(shù)據(jù)主要分為三個(gè)部分機(jī)密頭部、載荷、數(shù)據(jù)如果我們想查看其加密前內(nèi)容是什么樣子的，可以通過base64對(duì)其沒一部分進(jìn)行解密。
hash算法的摘要，是不可逆的在使用jsonwebtoken時(shí)需要注意的是，由于加密信息是可以反解的所以，盡量不要在加密數(shù)據(jù)中存放敏感信息，比如用戶的密碼，用戶私密信息等等（千萬不要效仿Dome，這是不對(duì)的O(∩_∩)O）。同過上面所述，所傳遞給前端的token一旦發(fā)生變化，僅僅是一個(gè)字母大小寫發(fā)生變化也是不行的，當(dāng)服務(wù)端接收到token解密時(shí)，是無法正確解密的，這種token可以是發(fā)篡改的。如果想要篡改token必須要有其secret才可以對(duì)其進(jìn)行篡改和偽造。
OAuth
OAuth（開放授權(quán)）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方網(wǎng)站訪問他們存儲(chǔ)在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方網(wǎng)站或分享他們數(shù)據(jù)的所有內(nèi)容，為了保護(hù)用戶數(shù)據(jù)的安全和隱私，第三方網(wǎng)站訪問用戶數(shù)據(jù)前都需要顯式的向用戶征求授權(quán)。我們常見的提供OAuth認(rèn)證服務(wù)的廠商有支付寶，QQ,微信。
OAuth協(xié)議又有1.0和2.0兩個(gè)版本。相比較1.0版，2.0版整個(gè)授權(quán)驗(yàn)證流程更簡單更安全，也是目前最主要的用戶身份驗(yàn)證和授權(quán)方式。
OAuth認(rèn)證主要經(jīng)歷了如下幾步:
簡單概括，就是用于第三方在用戶授權(quán)下調(diào)取平臺(tái)對(duì)外開放接口獲取用戶相關(guān)信息。OAuth引入了一個(gè)授權(quán)環(huán)節(jié)來解決上述問題。第三方應(yīng)用請(qǐng)求訪問受保護(hù)資源時(shí)，資源服務(wù)器在獲準(zhǔn)資源用戶授權(quán)后，會(huì)向第三方應(yīng)用頒發(fā)一個(gè)訪問令牌(AccessToken)。該訪問令牌包含資源用戶的授權(quán)訪問范圍、授權(quán)有效期等關(guān)鍵屬性。第三方應(yīng)用在后續(xù)資源訪問過程中需要一直持有該令牌，直到用戶主動(dòng)結(jié)束該次授權(quán)或者令牌自動(dòng)過期。
總結(jié)
授權(quán)方式多種多樣，主要還是要取決于我們對(duì)于產(chǎn)品的定位。如果我們的產(chǎn)品只是在企業(yè)內(nèi)部使用，token和session就可以滿足我們的需求，現(xiàn)在前后端分離如此火熱jwt認(rèn)證方式更加適合。
以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持武林網(wǎng)。
新聞熱點(diǎn)
疑難解答
圖片精選
網(wǎng)友關(guān)注
