http無狀態和鑑權解決四種方案

http協議自己是無狀態的,可是在實際的web開發中常有一些操做須要有狀態.好比想要訪問一些私人訪問權限的文章,或者這種操做須要明確當前用戶身份.html

顯然,最簡單的方案就是每次都發送帳戶和密碼,可是這樣重複操做用用戶並不友好,對服務器頁增添了額外的壓力.爲了解決無狀態帶來的鑑權問題,通常有如下幾種解決方案:cookie、session、token.至於標題中說起的outh二、jwt本質上也是token方案.linux

http無狀態和鑑權解決四種方案http無狀態和鑑權解決四種方案

cookieweb

Cookie是儲存在客戶端的一串字符,通常說來大小不超過4kb.好比咱們常見的記住密碼功能,或者一些基於以前輸入的提醒和默認配置,就是經過cookie來實現的,cookie簡單說來就是一種本地存儲方法.可是這裏存儲的信息經常使用來進行鑑權操做.cookie只能保存文本信息,瀏覽器能夠禁止cookie.cookie的期限能夠被自由設定,能夠是僅僅一次瀏覽起效,也能夠長達一年.若是是短時間的,那麼這些信息會被存儲在內存中,若是是長期則會存儲在硬盤上.cookie的起效範圍是路徑下的全部子路徑.不容許其餘來源的訪問.算法

單純的採用cookie來認證身份會帶來一個比較麻煩的問題,就是僞造比較容易.由於這樣處理,cookie中必然要帶有身份信息,可是服務器也要解析這個身份信息,因此必然要在原理上支持雙向的編碼和解碼,那麼這個信息很容易被破解和進一步僞造.想想,若是想要解決這個問題,咱們經常使用的方案應該是加一個secret,而這個secret應該是放在服務器上的,服務器返回這樣一個帶有secret編碼的字符串,而在服務器端再帶上這個secret反向解密,如此一來,問題不就解決了嗎?確實如此,可是這不表明cookie就安全,由於這已經不叫cookie了,而是咱們要講的第二個對象:session.跨域

session瀏覽器

經過上面說的東西,咱們已經可以得到身份信息,額外的,咱們還能夠把更復雜形式的信息都存儲進來,由於這裏沒有cookie的純文本限制.可是剛纔說的帶有secret編碼的字符串也就是sessionid,依然要存儲在客戶端.是否是意味着session一定要依賴cookie呢?不是!想想,咱們實際上須要的是在每一次請求(至少是須要斷定身份狀態的請求中),都帶上這個字符串,咱們有如下這幾種解決方案:緩存

  1. cookie
  2. 表單隱藏字段:在form中放置一個隱藏的域
  3. url重寫:在url後邊加上session的query段

Session也能夠設定有效時間.其實際的存儲能夠在內存、緩存、文件中.經過相似//可能具體實現不一樣.//hash表的數據結構存儲.cookie是一個存在的實體,session是一種機制.安全

token服務器

對token的理解還不夠,可能多有紕漏之處,待以後再進行修改.cookie

使用基於 Token 的身份驗證方法,在服務端不須要存儲用戶的登陸記錄。大概的流程是這樣的:

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

能夠看出來,這裏的token與sessionid有些相似,其區別:

  1. sessionid是帶着以前的狀態的,在服務器端能夠getSession(sessionid)
  2. token是在登陸驗證以後發放的一個包含着用戶基本信息的較長的字符串,用處是驗證身份以及簡化後續獲取信息的難度.
  3. token機制更靈活,能夠實現跨域

jwt

Jwt簡單說來是一種token的具體實現規範!

Jwt標準的token有三個部分,中間用點分隔開,而且都會使用 Base64 編碼:

  1. header。header 部分主要是兩部份內容,一個是 Token 的類型,另外一個是使用的算法
  2. Payload。裏面是 Token 的具體內容,這些內容裏面有一些是標準字段,你也能夠添加其它須要的內容
  3. Signature。編碼以上兩個部分而且加入一個secret使用信息摘要算法得出一個字符串

oauth2

簡單來講,oauth是用來向第三方平臺提供能夠細緻的權限管理的一種方案.
如何直接向第三方提供帳號和密碼,可能存在的問題有:

  1. 不安全
  2. 沒法更細緻的限制受權範圍和有效期
  3. 只有修改密碼才能收回權限
  4. 一個第三方程序被破解將會致使用戶密碼泄漏

OAuth的基本思路以下:

OAuth在」客戶端」與」服務提供商」之間,設置了一個受權層(authorization layer)。」客戶端」不能直接登陸」服務提供商」,只能登陸受權層,以此將用戶與客戶端區分開來。」客戶端」登陸受權層所用的令牌(token),與用戶的密碼不一樣。用戶能夠在登陸的時候,指定受權層令牌的權限範圍和有效期。」客戶端」登陸受權層之後,」服務提供商」根據令牌的權限範圍和有效期,向」客戶端」開放用戶儲存的資料。

本文地址:https://www.linuxprobe.com/cookie-session-token-oauth2.html

相關文章
相關標籤/搜索