關於前後端鑑權的幾種方式
“ 人生亦有命，安能行嘆復坐愁**”**
01 前言
最近看的比較多的方面都是關於計算機網絡的內容，不得不說這個方面是真的很廣泛，然後花了一些時間來了解一下如何實現前後端鑑權的方式，查閱了一下文章，也順便寫一下總結。
02 鑑權方式
前後之間進行數據交互，當然後端要判斷你是否是真正的操作者，只有符合條件的用戶纔可以操作。也就是說必須要有一個身份證明你是一個好人。通常會有四種方式：
- HTTP Basic Authentication
- session-cookie機制
- Token驗證
- OAuth開放授權
1、HTTP Basic Authentication
在HTTP中，基本認證是允許http用戶代理（瀏覽器）在請求時，提供用戶名和密碼的一種方式。是一種十分簡單的技術，使用的是HTTP頭部字段強制用戶訪問網絡資源，而不是通過cookie、sessionId、登陸頁面等非獲取訪問控制的手段。
很多網頁瀏覽器都支持這個，但是很少可以在公網上使用，因爲他並沒有爲傳送憑證提供數據保護，使用簡單的base64編碼後直接發送，編碼可逆且安全性低。還有一個缺點就是用戶在打開瀏覽器的情況下用戶無法登出，也就是無法註銷你已登錄。解決方法一般是服務器準備一個註銷的賬號，當服務器接收到的賬號密碼是註銷賬號時就會註銷。
如果用戶在沒有驗證的情況下會返回401狀態碼提示用戶進行授權，上圖中的Authorization字段就是加密用戶名和密碼後的base64字符串，服務端解密比對驗證後會將用戶請求數據返回。基本上就是一種密碼機制，中間可能會被截取和修改字段，所以是很不安全的機制。
2、session-cookie機制
利用服務端的session和瀏覽器的cookie來實現前後端鑑權，我們知道http是一種無狀態的請求，用戶請求完成就會關閉。如果要維持狀態就需要瀏覽器第一次請求的時候在服務端創建一個session，session有一個唯一的標識就是sessionId。一般生產sessionId之後經過加密（可不用加密）返回給客戶端，以cookie的形式保存在瀏覽器中。
當下一次請求時就會在請求頭中加入cookie信息，服務器取出sessionId與之前生成的sessionId比對是否一致，來判斷請求是否合法。
這種方法一般用在老版本的web系統，因爲信息也是存儲在cookie當中，也有不安全的成分在裏面，一般現在的系統也不會採用這種形式的鑑權。
3、Token驗證
Token又稱爲一個令牌，比如我們熟悉的QQ都有一個令牌，而且這個令牌隔一段時間是會變化的，上一種利用cookie的形式是不會變的。所以Token的鑑權方式更爲安全也用的比較多。
就拿我們一個網站舉例，當我們輸入用戶名和密碼點擊登陸的時候，加入網站是以Token進行鑑權的話，會有以下的步驟產生：
- 用戶名和密碼請求登陸
- 服務端驗證是否爲數據庫用戶
- 成功，下發令牌Token給客戶端
- 客戶端以後每次請求都會帶上令牌
- 服務端每次都會驗證令牌
其實看起來和上一個的驗證方法差不多呀，到底有哪些區別呢？
session和cookie機制是在客戶端與服務端之間保持一個狀態，服務端創建session對象也是需要開闢一定的內存空間來保存登陸狀態的，但是利用Token的話就不會保持狀態，只需比對令牌是否有效即可。
也就是說Token是不存儲在服務器的，這個Token本身就保存着登陸狀態，服務器根據事先定義好的規則進行解密就可以知道該Token是否合理。初次之外，我們知道不只是瀏覽器是代理客戶端，手機APP也是，在手機上面cookie是不起作用的，那麼久限制了客戶端類型，Token驗證就不會有這個問題。
4、OAuth開放授權
這種方法用的是最多的，我們常見的一些網站比如CSDN、掘金等都可以利用微信和QQ進行登陸的，無須使用其他的用戶名和密碼。這種方式就可以省略了很多步驟，使得用戶體驗良好。
那麼它是怎麼操作的呢？
- 向用戶請求授權
- 用戶授權，返回憑證code給第三方（CSDN/掘金）
- 利用code向授權服務器請求Access Token
- 返回Access Token
- 利用Access Token向資源服務器請求用戶資源
- 獲取用戶資源，登陸成功
03 小結
用戶鑑權在前端安全方面起着至關重要的作用，企業或者大型應用都會有自己獨特的鑑權方法，但是原理還是離不開以上的步驟，而以上都是比較經典也是有代表性的鑑權方式，大家可以多瞭解多觀察其他企業的做法。
參考文章
- 前後端鑑權方式總結
- 維基百科 HTTP Basic Authentication
- 維基百科 安全令牌
歡迎大家關注我的公衆號《前端小時》
個人博客：blog.alanwu.site
