4種常見的鑑權方式及說明

2021-10-02 02:25:20 字數 4800 閱讀 6960

鑑權(authentication)是指驗證使用者是否擁有訪問系統的權利。傳統的鑑權是通過密碼來驗證的。這種方式的前提是,每個獲得密碼的使用者都已經被授權。在建立使用者時,就為此使用者分配乙個密碼,使用者的密碼可以由管理員指定,也可以由使用者自行申請。這種方式的弱點十分明顯:一旦密碼被偷或使用者遺失密碼,情況就會十分麻煩,需要管理員對使用者密碼進行重新修改,而修改密碼之前還要人工驗證使用者的合法身份。

為了克服這種鑑權方式的缺點,需要乙個更加可靠的鑑權方式。目前的主流鑑權方式是利用認證授權來驗證數字簽名的正確與否。

邏輯上,授權發生在鑑權之後,而實際上,這兩者常常是乙個過程。

這種雙向的認證機制,就是aka(authentication and key agreement,鑑權和金鑰協商)鑑權。

除了aka鑑權,也可以使用其它鑑權方式。在ims aka鑑權廣泛實施之前,或在特定的條件下(例如通過固定網路adsl連線方式接入ims),可以使用http摘要鑑權等其他鑑權方式。

3g umts(universal mobile telecommunication system,通用移動通訊系統)、eps(evolved packet system,演進的分組系統)、ims(ip ********** subsystem,ip多**子系統)網路都採用了aka雙向鑑權機制,鑑權原理也大致相同。而2g網路,只有使用者鑑權,無網路鑑權。

流動網路對鑑權時機的要求為:

我們常用的鑑權有四種:

3、token 驗證

4、oauth(開放授權)

這種授權方式是瀏覽器遵守http協議實現的基本授權方式,http協議進行通訊的過程中,http協議定義了基本認證認證允許http伺服器對客戶端進行使用者身份證的方法。

認證過程:

1. 客戶端向伺服器請求資料,請求的內容可能是乙個網頁或者是乙個ajax非同步請求,此時,假設客戶端尚未被驗證,則客戶端提供如下請求至伺服器:

2. 伺服器向客戶端傳送驗證請求**401,(www-authenticate: basic realm=」google.com」這句話是關鍵,如果沒有客戶端不會彈出使用者名稱和密碼輸入介面)伺服器返回的資料大抵如下:

3. 當符合http1.0或1.1規範的客戶端(如ie,firefox)收到401返回值時,將自動彈出乙個登入視窗,要求使用者輸入使用者名稱和密碼。

4. 使用者輸入使用者名稱和密碼後,將使用者名稱及密碼以base64加密方式加密,並將密文放入前一條請求資訊中,則客戶端傳送的第一條請求資訊則變成如下內容:

authorization: basic d2fuzzp3yw5n

注:d2fuzzp3yw5n表示加密後的使用者名稱及密碼(使用者名稱:密碼 然後通過base64加密,加密過程是瀏覽器預設的行為,不需要我們人為加密,我們只需要輸入使用者名稱密碼即可)

5. 伺服器收到上述請求資訊後,將authorization欄位後的使用者資訊取出、解密,將解密後的使用者名稱及密碼與使用者資料庫進行比較驗證,如使用者名稱及密碼正確,伺服器則根據請求,將所請求資源傳送給客戶端。

效果:

客戶端未未認證的時候,會彈出使用者名稱密碼輸入框,這個時候請求時屬於pending狀態,這個時候其實服務當使用者輸入使用者名稱密碼的時候客戶端會再次傳送帶authentication頭的請求。

http cookie(也叫web cookie或瀏覽器cookie)是伺服器傳送到使用者瀏覽器並儲存在本地的一小塊資料,它會在瀏覽器下次向同一伺服器再發起請求時被攜帶併發送到伺服器上。通常,它用於告知服務端兩個請求是否來自同一瀏覽器,如保持使用者的登入狀態。cookie使基於無狀態的http協議記錄穩定的狀態資訊成為了可能。

cookie主要用於以下三個方面:

認證過程

伺服器在接受客戶端首次訪問時在伺服器端建立seesion,然後儲存seesion(我們可以將seesion儲存在記憶體中,也可以儲存在redis中,推薦使用後者),然後給這個session生成乙個唯一的標識字串,然後在響應頭中種下這個唯一標識字串。

簽名。這一步只是對sid進行加密處理,服務端會根據這個secret金鑰進行解密。(非必需步驟)

瀏覽器中收到請求響應的時候會解析響應頭,然後將sid儲存在本地cookie中,瀏覽器在下次http請求de 請求頭中會帶上該網域名稱下的cookie資訊。

伺服器在接受客戶端請求時會去解析請求頭cookie中的sid,然後根據這個sid去找伺服器端儲存的該客戶端的session,然後判斷該請求是否合法。

一旦使用者登出,服務端和客戶端同時銷毀該會話在後續請求中,伺服器會根據資料庫驗證會話id,如果驗證通過,則繼續處理;

認證過程

使用者輸入登陸憑據;

伺服器驗證憑據是否正確,然後返回乙個經過簽名的token;

客戶端負責儲存token,可以存在localstorage,或者cookie中

對伺服器的請求帶上這個token;

伺服器對jwt進行解碼,如果token有效,則處理該請求;

一旦使用者登出,客戶端銷毀token。

cookie與taken看上去很像,那麼他們到底有什麼區別呢?

cookie與taken效能對比

sessionid 他只是乙個唯一標識的字串,服務端是根據這個字串,來查詢在伺服器端保持的seesion,這裡面才儲存著使用者的登陸狀態。但是token本身就是一種登陸成功憑證,他是在登陸成功後根據某種規則生成的一種資訊憑證,他裡面本身就儲存著使用者的登陸狀態。伺服器端只需要根據定義的規則校驗這個token是否合法就行。

時效性。session-cookie的sessionid實在登陸的時候生成的而且在登出事時一直不變的,在一定程度上安全就會低,而token是可以在一段時間內動態改變的。

可擴充套件性。token驗證本身是比較靈活的,一是token的解決方案有許多,常用的是jwt,二來我們可以基於token驗證機制,專門做乙個鑑權服務,用它向多個服務的請求進行統一鑑權。

oauth協議為使用者資源的授權提供了乙個安全的、開放而又簡易的標準。與以往的授權方式不同之處是oauth的授權不會使第三方觸及到使用者的帳號資訊(如使用者名稱與密碼),即第三方無需使用使用者的使用者名稱與密碼就可以申請獲得該使用者資源的授權,因此oauth是安全的。同時,任何第三方都可以使用oauth認證服務,任何服務提供商都可以實現自身的oauth認證服務,因而oauth是開放的。

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

典型案例

當使用者要使用服務b列印儲存在服務a上的時,使用者該如何處理?

方法三:當服務b(列印服務)要訪問使用者的服務a(服務)時,通過oauth機制,服務b向服務a請求未經使用者授權的requesttoken後,服務a將引導使用者在服務a的**上登入,並詢問使用者是否將服務授權給服務b。使用者同意後,服務b就可以訪問使用者在服務a上的服務。整個過程服務b沒有觸及到使用者在服務a的帳號資訊。

oauth相關術語

在認證和授權的過程中涉及的三方包括:

使用者(user),存放在服務提供方的受保護的資源的擁有者

客戶端(consumer),要訪問服務提供方資源的第三方應用,通常是**,如提供**列印服務的**也可以是桌面或移動應用程式。在認證過程之前,客戶端要向服務提供者申請客戶端標識。

requesttoken url:獲取未授權的requesttoken服務位址;

userauthorization url:獲取使用者授權的requesttoken服務位址;

accesstoken url:用授權的requesttoken換取accesstoken的服務位址。

oauth認證和授權過程

客戶端(第三方軟體)向oauth服務提供商請求未授權的requesttoken。即向requesttoken url發起請求;

oauth服務提供商同意使用者的請求,並向其頒發未經使用者授權的oauth_token與對應的oauth_token_secret,並返回給使用者;

使用者向oauth服務提供商請求使用者授權的requesttoken。即向userauthorization url發起請求並在請求中攜帶上一步服務提供商頒發的未授權的token與其金鑰;

oauth服務提供商通過網頁要求使用者登入並引導使用者完成授權;

requesttoken授權後,使用者將向accesstoken url發起請求,將上步授權的requesttoken換取成accesstoken。請求的引數見上圖,這個比第一步多了乙個引數就是requesttoken;

oauth服務提供商同意使用者的請求,並向其頒發accesstoken與對應的金鑰,並返回給使用者;

使用者以後就可以使用上步返回的accesstoken訪問使用者授權的資源。

簡單整理就三個步驟

獲取未授權的requesttoken

獲取使用者授權的requesttoken

用授權的requesttoken換取accesstoken

mysql鑑權方式 四種常用鑑權方式

由於http 協議是一種無狀態的協議,伺服器端並不知道客戶端的那一頭是誰在請求伺服器。而且伺服器上的資源不一定是對所有人開放,所以需要進行使用者對登入鑑權。目前,我們在開發中主要使用過4 種鑑權方式。一 http basic authentication鑑權 這種授權方式是瀏覽器遵守http協議實現...

前後端常見的幾種鑑權方式

目前我們常用的鑑權有四種 token 驗證 oauth 開放授權 一.http basic authentication 這種授權方式是瀏覽器遵守http協議實現的基本授權方式,http協議進行通訊的過程中,http協議定義了基本認證認證允許http伺服器對客戶端進行使用者身份證的方法。認證過程 1...

前後端常見的幾種鑑權方式

每個專案產品都要加埋點,加500行埋點是不是會占用你一兩天的時間而且很容易犯錯,想只用一小時準確加完這500行埋點剩下一天喝茶聊天麼?來試試這520工具,高效加埋點,目前我們公司100號前端都在用,因為很好用,所以很自然普及開來了,推薦給大家吧 目前我們常用的鑑權有四種 token 驗證 oauth...