目前我們常用的鑒權有四種：
HTTP Basic Authentication
session-cookie
Token 驗證
OAuth(開放授權)
壹.HTTP Basic Authentication
這種授權方式是瀏覽器遵守
2． 服務器向客戶端發送驗證請求代碼401,（WWW-Authenticate: Basic realm=”google.com”這句話是關鍵，如果沒有客戶端不會彈出用戶名和密碼輸入界面）服務器返回的數據大抵如下：
HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm=”google.com”
Content-Type: text/html
Content-Length: xxx
3． 當符合
Authorization: Basic d2FuZzp3YW5n
註：d2FuZzp3YW5n表示加密後的用戶名及密碼（用戶名：密碼 然後通過base64加密，加密過程是瀏覽器默認的行為，不需要我們人為加密，我們只需要輸入用戶名密碼即可）
5． 服務器收到上述請求信息後，將Authorization字段後的用戶信息取出、解密，將解密後的用戶名及密碼與用戶數據庫進行比較驗證，如用戶名及密碼正確，服務器則根據請求，將所請求資源發送給客戶端
效果：
客戶端未未認證的時候，會彈出用戶名密碼輸入框，這個時候請求時屬於pending狀態，這個時候其實服務當用戶輸入用戶名密碼的時候客戶端會再次發送帶Authentication頭的請求。
認證成功：
server.js
let express = require("express");
let app = express();
app.use(express.static(__dirname+'/public'));
app.get("/Authentication_base",function(req,res){
console.log('req.headers.authorization:',req.headers)
if(!req.headers.authorization){
res.set({
'WWW-Authenticate':'Basic realm="wang"'
});
res.status(401).end();
}else{
let base64 = req.headers.authorization.split(" ")[1];
let userPass = new Buffer(base64, 'base64').toString().split(":");
let user = userPass[0];
let pass = userPass[1];
if(user=="wang"&&pass="wang"){
res.end("OK");
}else{
res.status(401).end();
}
}
})
app.listen(9090)
index.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>HTTP Basic Authentication</title>
</head>
<body>
<div></div>
<script src="js/jquery-3.2.1.js"></script>
<script>
$(function(){
send('./Authentication_base');
})
var send = function(url){
$.ajax({
url : url,
method : 'GET',
});
}
</script>
</body>
</html>
當然有登陸就有註銷，我們會發現當我們認證成功後每次請求請求頭都會帶上Authentication及裏面的內容，那麽如何做到讓這次登陸失效的？
網上查了半天，目前最有效的方式就是在註銷操作的時候，專門在服務器設置壹個專門的註銷賬號，當接收到的Authentication信息為註銷用戶名密碼的時候糾就帶便註銷成功了，而客戶端在註銷操作的時候，手動的的去修改請求頭重的Authentication，將他設置未服務器默認的註銷賬號和密碼。
通過上面的簡單講解 其實我們已經可以返現這種驗證方式的缺陷加密方式簡單，僅僅是base64加密，這種加密方式是可逆的。同時在每個請求的頭上都會附帶上用戶名和密碼信息，這樣在外網是很容易被嗅探器探測到的。
總結:
正式因為這樣，這種加密方式壹般多被用在內部安全性要求不高的的系統上，只是相對的多，總的來說現在使用這種鑒權比較少了。如果項目需要部署在公網上，這種方式不推薦，當然妳也可以和SSL來加密傳輸，這樣會好壹點，這個如果我後面有時間來研究壹下。
二.session-cookie
第二種這個方式是利用服務器端的session（會話）和瀏覽器端的cookie來實現前後端的認證，由於/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=/account/login?oauth_provider=QQProvider&state=test
這個url地址我們可以看見Auth2.0常見的幾個參數：
response_type，返回類型
client_id，第三方應用id,由授權服務器（qq）在第三方應用提交時頒發給第三方應用。
redirect_uri，登陸成功重定向頁面
oauth_provider，第三方授權提供方
state，由第三方應用給出的隨機碼
第二步. 返回用戶憑證（code），並返回壹個憑證（code），當用戶點擊授權並登陸後，授權服務器將生成壹個用戶憑證（code）。這個用戶憑證會附加在重定向的地址redirect_uri的後面
/account/login?code=9e3efa6cea739f9aaab2&state=XXX
第3步. 請求授權服務器授權:
經過第二部獲取code後後面的工作就可以交給後臺去處理的，和用戶的交互就結束了。接下來我的需要獲取Access Token，我們需要用他來向授權服務器獲取用戶信息等資源。
第三方應用後臺通過第二步的憑證（code）向授權服務器請求Access Token，這時候需要以下幾個信息：
client_id 標識第三方應用的id，由授權服務器（Github）在第三方應用提交時頒發給第三方應用
client_secret 第三方應用和授權服務器之間的安全憑證，由授權服務器（Github）在第三方應用提交時頒發給第三方應用
code 第壹步中返回的用戶憑證redirect_uri 第壹步生成用戶憑證後跳轉到第二步時的地址
state 由第三方應用給出的隨機碼
第四步. 授權服務器同意授權後，返回壹個資源訪問的憑證（Access Token）。
第五步. 第三方應用通過第四步的憑證（Access Token）向資源服務器請求相關資源。
第六步. 資源服務器驗證憑證（Access Token）通過