聊聊鑑權那些事

時間 2019-11-08

標籤聊聊那些简体版

原文原文鏈接

在系統級項目開發時經常會遇到一個問題就是鑑權，身爲一個前端來講可能咱們距離鑑權可能比較遠，通常來講咱們也只是去應用，並無對權限這一部分進行深刻的理解。html

什麼是鑑權

鑑權：是指驗證用戶是否擁有訪問系統的權利。傳統的鑑權是經過密碼來驗證的。這種方式的前提是，每一個得到密碼的用戶都已經被受權。在創建用戶時，就爲此用戶分配一個密碼，用戶的密碼能夠由管理員指定，也能夠由用戶自行申請。這種方式的弱點十分明顯：一旦密碼被偷或用戶遺失密碼，狀況就會十分麻煩，須要管理員對用戶密碼進行從新修改，而修改密碼以前還要人工驗證用戶的合法身份。 -- 節選自百度百科前端

上述簡單扼要的說明了一下鑑權的概念，可是這也只是簡單的鑑權，也是項目中最最多見的及安全形式了，可是對於後端鑑權又是如何去作的，咱們還是一無所知，通常來講對於後端來講，鑑權最長見的方式分爲三種：vue

Session/Cookie
Token或Jwt
OAuth

這種受權方式是瀏覽器遵照http協議實現的基本受權方式,HTTP協議進行通訊的過程當中，HTTP協議定義了基本認證認證容許HTTP服務器對客戶端進行用戶身份證的方法。接下來就一一介紹一下這三種鑑權方式。node

Session/Cookie

Cookie是一個很是具體的東西，指的就是瀏覽器裏面能永久存儲的一種數據，僅僅是瀏覽器實現的一種數據存儲功能。Cookie由服務器生成，發送給瀏覽器，瀏覽器把Cookie以KV形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該Cookie發送給服務器。因爲Cookie是存在客戶端上的，因此瀏覽器加入了一些限制確保Cookie不會被惡意使用，同時不會佔據太多磁盤空間，因此每一個域的Cookie數量是有限的。ios

Cookie.jsweb

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運行上面代碼，等程序啓動後訪問http://localhost:3000/，就能夠看到hello cookie字樣，這樣的話就表明該服務已經啓動了。若想查看到到咱們所設置的Cookie，首先觀察一下在Network中Response Headers中，能夠看到咱們所寫的Set-Cookie屬性，當咱們訪問http://localhost:3000/的時候，當瀏覽器接收到Set-Cookie這個屬性的時候，瀏覽器會根據其內部約定，並在其瀏覽器內部對其cookie進行存儲，打開瀏覽器控制檯，在Application中找到Cookies中找到相對應的域名，就能夠看到咱們所設置的cookie值了。當在同域的狀況下，當再次請求數據的時候瀏覽器會默認發送cookie在該請求中，一塊兒發送給後端。爲了證明上面的說法，刷新一下http://localhost:3000/頁面，在控制檯Network找到Request Headers中能夠看到Cookie: cx=Segmentfault屬性，既然發送給服務端以後，相應的在後端也是能夠接收到該Cookie的，修改一下上面的例子：redis

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);

在接收到訪問的時候，就能夠接收到了cx=Segmentfault，若是說如今這份Cookie是一份加密的數據的話，裏面包含一些用戶信息，在經過先後端進行交互以後，當客戶端再次請求服務端的時候，服務端拿到相對應的Cookie並對其進行解密，對其中用戶的信息進行鑑權處理就能夠了。算法

服務端經過Set-Cookie在Response Headers設置了一段加密數據，客戶端接收到了其相對應的數據以後，瀏覽器對其進行存儲，當可客戶端再次發送請求的時候，會攜帶已有的Cookie在Request Headers中一併發送給服務端，服務端解密數據完成鑑權，由此能夠得出Cookie是服務端存儲在客服端的狀態標誌，再由客戶端發送給服務端，由服務端解析。Cookie在使用中必須是同域的狀況下才能夠，通常經常使用的是在MVC這種開發形式中很經常使用。npm

說了半天Cookie，可是對於Session卻隻字未提，接下來就介紹一下Session，Session從字面上講，就是會話。這個就相似於你和一我的交談，你怎麼知道當前和你交談的是張三而不是李四呢？對方確定有某種特徵（長相等）代表他就是張三。Session也是相似的道理，服務器要知道當前發請求給本身的是誰。爲了作這種區分，服務器就要給每一個客戶端分配不一樣的身份標識，而後客戶端每次向服務器發請求的時候，都帶上這個身份標識，服務器就知道這個請求來自於誰了。至於客戶端怎麼保存這個身份標識，能夠有不少種方式，對於瀏覽器客戶端，你們都默認採用Cookie的方式。json

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而已，在實際項目中獲取cookie比這個要複雜不少。

Session/Cookie認證主要分四步：

服務器在接受客戶端首次訪問時在服務器端建立seesion，而後保存seesion(咱們能夠將seesion保存在內存中，也能夠保存在redis中，推薦使用後者)，而後給這個session生成一個惟一的標識字符串,而後在響應頭中種下這個惟一標識字符串。
簽名。這一步只是對sid進行加密處理，服務端會根據這個secret密鑰進行解密。（非必需步驟）
瀏覽器中收到請求響應的時候會解析響應頭，而後將sid保存在本地cookie中，瀏覽器在下次http請求的時候，請求頭中會帶上該域名下的cookie信息，
服務器在接受客戶端請求時會去解析請求頭cookie中的sid，而後根據這個sid去找服務器端保存的該客戶端的session，而後判斷該請求是否合法。

利用服務器端的session和瀏覽器端的cookie來實現先後端的認證，因爲http請求時是無狀態的，服務器正常狀況下是不知道當前請求以前有沒有來過，這個時候咱們若是要記錄狀態，就須要在服務器端建立一個會話(seesion),將同一個客戶端的請求都維護在各自得會會話中，每當請求到達服務器端的時候，先去查一下該客戶端有沒有在服務器端建立seesion，若是有則已經認證成功了，不然就沒有認證。

與redis結合使用：

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 = {
    //  所設置的session的key
    key:"sId",
    //  最大有效期
    maxAge:8640000,
    //  是否防止js讀取
    httpOnly:true,
    //  cookie二次簽名
    signed:true,
    //  存儲方式
    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能夠解決鑑權問題，可是會有很大的問題，對於服務端來講說是一個巨大的開銷，嚴重的限制了服務器擴展能力，好比說我用兩個機器組成了一個集羣，小F經過機器A登陸了系統，那sessionId會保存在機器A上，假設小F的下一次請求被轉發到機器B怎麼辦？機器B可沒有小F的sessionId，有時候會採用一點小伎倆：session sticky，就是讓小F的請求一直粘連在機器A上，可是這也無論用，要是機器A掛掉了，還得轉到機器B去。那隻好作session的複製了，把sessionId在兩個機器之間搬來搬去，再好的服務器也經不起這樣的折騰。

Token或Jwt

在計算機身份認證中是令牌（臨時）的意思，在詞法分析中是標記的意思。通常做爲邀請、登陸系統使用。如今先後端分離火熱，Token混的風生水起，不少項目開發過程當中都會用到Token，其實Token是一串字符串，一般由於做爲鑑權憑據，最經常使用的使用場景是API鑑權。

客戶端使用用戶名跟密碼請求登陸
服務端收到請求，去驗證用戶名與密碼
驗證成功後，服務端會簽發一個Token，再把這個Token發送給客戶端
客戶端收到Token之後能夠把它存儲起來，好比放在Cookie裏或者Local Storage裏
客戶端每次向服務端請求資源的時候須要帶着服務端簽發的Token
服務端收到請求，而後去驗證客戶端請求裏面帶着的Token，若是驗證成功，就向客戶端返回請求的數據

示例：

前端

<!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"
//  請求攔截
axios.interceptors.request.use((config) => {
    const token = localStorage.getItem("token");
    if(token){
        //  判斷是否存在token，若是存在的話
        //  每次發起HTTP請求時在headers中添加token
        //  Bearer是JWT的認證頭部信息
        config.headers["Authorization"] = `Bearer ${token}`
    }
    return config;
},error => alert(error));
//  響應攔截
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參數
    console.log(ctx.state.user.data)
    ctx.body = {
        code:1,
        message:"成功",
        data:ctx.state.user.data
    }
})
app.use(router.routes());
app.listen(3000);

上面代碼用到了不少的依賴模塊，最關鍵的的是jsonwebtoken和koa-jwt，這兩個模塊一個是用來對token進行加密，一個是用來對數據進行解密的，同時在每次訪問須要保護的路由的時候須要使用jwtAuth對其進行攔截處理，jwtAuth會根據其secret進行數據解密，把解密的數據存放到ctx.state中，供用戶讀取。

有關jwt相關請查看深刻理解令牌認證機制詳細的解釋了其加密後數據token的構成。

加密後的數據主要分爲三個部分機密頭部、載荷、數據若是咱們想查看其加密前內容是什麼樣子的，能夠經過base64對其沒一部分進行解密。

機密頭部：聲明加密規則，可反解
載荷：數據信息，也就是咱們須要加密的信息，可反解
驗證：這部分是對前兩部分使用hash算法的摘要，是不可逆的

在使用jsonwebtoken時須要注意的是，因爲加密信息是能夠反解的因此，儘可能不要在加密數據中存放敏感信息，好比用戶的密碼，用戶私密信息等等（千萬不要效仿Dome，這是不對的O(∩_∩)O）。同過上面所述，所傳遞給前端的token一旦發生變化，僅僅是一個字母大小寫發生變化也是不行的，當服務端接收到token解密時，是沒法正確解密的，這種token能夠是發篡改的。若是想要篡改token必需要有其secret才能夠對其進行篡改和僞造。

OAuth

OAuth（開放受權）是一個開放標準，容許用戶受權第三方網站訪問他們存儲在另外的服務提供者上的信息，而不須要將用戶名和密碼提供給第三方網站或分享他們數據的全部內容，爲了保護用戶數據的安全和隱私，第三方網站訪問用戶數據前都須要顯式的向用戶徵求受權。咱們常見的提供OAuth認證服務的廠商有支付寶，QQ,微信。

OAuth協議又有1.0和2.0兩個版本。相比較1.0版，2.0版整個受權驗證流程更簡單更安全，也是目前最主要的用戶身份驗證和受權方式。

OAuth認證主要經歷了以下幾步:

須要第三方應用存儲資源全部者的憑據，以供未來使用，一般是明文密碼。
須要服務器支持密碼身份認證，儘管密碼認證天生就有安全缺陷。
第三方應用得到的資源全部者的受保護資源的訪問權限過於寬泛，從而致使資源全部者失去對資源使用時限或使用範圍的控制。
資源全部者不能僅撤銷某個第三方的訪問權限而不影響其它，而且，資源全部者只有經過改變第三方的密碼，才能單獨撤銷這第三方的訪問權限。
與任何第三方應用的讓步致使對終端用戶的密碼及該密碼所保護的全部數據的讓步。

簡單歸納，就是用於第三方在用戶受權下調取平臺對外開放接口獲取用戶相關信息。OAuth引入了一個受權環節來解決上述問題。第三方應用請求訪問受保護資源時，資源服務器在獲准資源用戶受權後，會向第三方應用頒發一個訪問令牌(AccessToken)。該訪問令牌包含資源用戶的受權訪問範圍、受權有效期等關鍵屬性。第三方應用在後續資源訪問過程當中須要一直持有該令牌，直到用戶主動結束該次受權或者令牌自動過時。

總結

受權方式多種多樣，主要仍是要取決於咱們對於產品的定位。若是咱們的產品只是在企業內部使用，token和session就能夠知足咱們的需求，如今先後端分離如此火熱jwt認證方式更加適合。

感謝你們閱讀本文章，文章中如有錯誤請你們指正，若是感受有多幫助的話，不要忘記點贊哦。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。