Postman鑒權-有解無憂

Ok, 今天我們來學習一下 鑒權

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

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

邏輯上，授權發生在鑒權之后，而實際上，這兩者常常是一個程序，

我們常用的鑒權有四種：

1、HTTP Basic Authentication

2、session-cookie

3、Token 驗證

4、OAuth(開放授權)

其他幾種，自己去看相關資料，今天著重講下這種 HTTP Basic Authentication

這種授權方式是瀏覽器遵守http協議實作的基本授權方式,HTTP協議進行通信的程序中，HTTP協議定義了基本認證認證允許HTTP服務器對客戶端進行用戶身份證的方法，

認證程序：

1．客戶端向服務器請求資料，請求的內容可能是一個網頁或者是一個ajax異步請求，此時，假設客戶端尚未被驗證，則客戶端提供如下請求至服務器:

Get /index.html HTTP/1.0
Host:www.google.com

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．當符合http1.0或1.1規范的客戶端（如IE，FIREFOX）收到401回傳值時，將自動彈出一個登錄視窗，要求用戶輸入用戶名和密碼，

4．用戶輸入用戶名和密碼后，將用戶名及密碼以BASE64加密方式加密，并將密文放入前一條請求資訊中，則客戶端發送的第一條請求資訊則變成如下內容：

Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic d2FuZzp3YW5n

注：d2FuZzp3YW5n表示加密后的用戶名及密碼（用戶名：密碼然后通過base64加密，加密程序是瀏覽器默認的行為，不需要我們人為加密，我們只需要輸入用戶名密碼即可）

5．服務器收到上述請求資訊后，將Authorization欄位后的用戶資訊取出、解密，將解密后的用戶名及密碼與用戶資料庫進行比較驗證，如用戶名及密碼正確，服務器則根據請求，將所請求資源發送給客戶端，

效果：
客戶端未未認證的時候，會彈出用戶名密碼輸入框，這個時候請求時屬于pending狀態，這個時候其實服務當用戶輸入用戶名密碼的時候客戶端會再次發送帶Authentication頭的請求，

我們以Postman 官方 api 為例

很多時候，出于安全考慮我們的介面并不希望對外公開，這個時候就需要使用授權(Authorization)機制授權程序驗證您是否具有訪問服務器所需資料的權限，當您發送請求時，您通常必須包含引數，以確保請求具有訪問和回傳所需資料的權限， Postman提供授權型別，可以輕松地在Postman本地應用程式中處理身份驗證協議，

Postman支持的授權協議型別如下：

Inherit auth from parent：是默認的鑒權方式，繼承；
No Auth：代表不需要鑒權
bearer token 鑒權：一般也叫 Json web token，就是發送一個 json 格式的 token 令牌，服務端會針對 token 進行解密驗證
Basic Auth 基礎驗證:提供用戶名密碼驗證，postman 會自動生成 authorization，屬于最常用鑒權方式
digest auth，摘要式認證，在基本身份認證上面擴展了安全性，服務器為每一個連接生成一個唯一的亂數，客戶端用這個亂數對密碼進行 MD5 加密，然后回傳服務器，服務器也用這個亂數對密碼進行加密，然后和客戶端傳送過來的加密資料進行比較,如果一致就回傳結果，
它是一個二次驗證的程序，會有兩次認證互動訊息，客戶端請求資源->服務器回傳認證標示->客戶端發送認證資訊->服務器查驗認證，
Oauth，一般用于第三方認證，有1,2兩個版本，需要提供的資訊不太一樣，也是常用的鑒權方式
Hawk 認證，是另一種認證方案，采用的叫訊息碼認證演算法，和 Digest 認證類似，它也是需要二次互動的
AWS 簽名認證：是針對亞馬遜的 AWS 公有云用戶簽名的認證方式
NTLM：是微軟的局域網管理認證協議
Akamai EdgeGrid：是 Akamai 的專屬認證協議
其中最重要的鑒權方式為：Basic 以及 OAuth2，下面我們通過實體演示下這兩種鑒權方式；

Basic auth

基本身份驗證是一種比較簡單的授權型別，需要經過驗證的用戶名和密碼才能訪問資料資源，這就需要我們輸入用戶名和對應的密碼，

案例：請求URL如下，授權賬號為：

用戶名 : postman
密碼 : password
授權協議為： Basic auth

https://postman-echo.com/basic-auth

如果不輸入用戶名密碼，直接使用GET請求，則會回傳提示：Unauthorized
輸入用戶名密碼，選擇Basic auth授權型別，則會回傳如下結果：

"authenticated": true

Digest Auth

Digest auth是一個簡單的認證機制，最初是為HTTP協議開發的，因此也常叫做HTTP摘要，其身份驗證機制非常簡單，它采用哈希加密方法，以避免用明文傳輸用戶的口令，摘要認證就是核實參與通信的兩方都知道雙方共享的一個口令，

當server想要查證用戶的身份，它產生一個摘要盤問（digest challenge），并發送給用戶，典型的摘要盤問例如以下：

Digest realm=“iptel.org”, qop=“auth,auth-int”, nonce=“dcd98b7102dd2f0e8b11d0f600bfb0c093”, opaque="", algorithm=MD5

這里包含了一組引數，也要發送給用戶，用戶使用這些引數，來產生正確的摘要回答，并發送給server，摘要盤問中的各個引數，其意義以下：

realm（領域）：領域參數是強制的，在全部的盤問中都必須有，它是目的是鑒別SIP訊息中的機密，在SIP實際應用中，它通常設定為SIP代理server所負責的域名，

nonce（現時）：這是由server規定的資料字串，在server每次產生一個摘要盤問時，這個參數都是不一樣的（與前面所產生的不會雷同），“現時”一般是由一些資料通過md5雜湊運算構造的，這種資料通常包含時間標識和server的機密短語，這確保每一個“現時”都有一個有限的生命期（也就是過了一些時間后會失效，并且以后再也不會使用），并且是獨一無二的（即不論什么其他的server都不能產生一個同樣的“現時”），

algorithm（演算法）：這是用來計算的演算法，當前僅僅支持MD5演算法，

qop（保護的質量）：這個參數規定server支持哪種保護方案，client能夠從串列中選擇一個，值 auth表示僅僅進行身份查驗， auth-int表示進行查驗外，另一些完整性保護，須要看更具體的描寫敘述，請參閱RFC2617，

案例：

請求URL： https://postman-echo.com/digest-auth

摘要配置資訊如下：用戶名密碼和上面basic auth一樣

Digest username=“postman”, realm=“Users”, nonce=“ni1LiL0O37PRRhofWdCLmwFsnEtH1lew”, uri="/digest-auth", response=“254679099562cf07df9b6f5d8d15db44”, opaque=""

執行請求結果如下：

{
"authenticated": true
}

OAuth 1.0

OAuth（開放授權）是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存盤的私密的資源（如照片，視頻，聯系人串列），而無需將用戶名和密碼提供給第三方應用，

擴展資料：

OAuth那些事兒
OAuth的改變

案例

請求URL如下：請求方式為GET，Add authorization data to設定為：Request Headers

https://postman-echo.com/oauth1

引數配置為：

Consumer Key: RKCGzna7bv9YD57c
Consumer Secret: D+EdQ-gs$-%@2N

發送請求結果如下：

{"status": "pass",

"message": "OAuth-1.0a signature verification was successful"
}

如果Consumer Secret錯誤則回傳如下結果：

{"status": "fail",

"message": "HMAC-SHA1 verification failed",

"base_uri": "https://postman-echo.com/oauth1",

"normalized_param_string": "oauth_consumer_key=RKCGzna7bv9YD57c&oauth_nonce=9Tp6pr0xQwV&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1612414971&oauth_version=1.0",

"base_string": "GET&https%3A%2F%2Fpostman-echo.com%2Foauth1&oauth_consumer_key%3DRKCGzna7bv9YD57c%26oauth_nonce%3D9Tp6pr0xQwV%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1612414971%26oauth_version%3D1.0",

"signing_key": "D%2BEdQ-gs%24-%25%402Nu7&"
}

擴展資料：各個授權協議檔案

Hawk Authentication

Hawk Auth是一個HTTP認證方案，使用MAC（Message Authentication Code，訊息認證碼演算法）演算法，它提供了對請求進行部分加密驗證的認證HTTP請求的方法，hawk方案要求提供一個共享對稱密匙在服務器與客戶端之間，通常這個共享的憑證在初始TLS（安全傳輸層協議）保護階段建立的，或者是從客戶端和服務器都可用的其他一些共享機密資訊中獲得的，

案例

請求URL如下： https://postman-echo.com/auth/hawk

密鑰資訊如下：

Hawk Auth ID: dh37fgj492je
Hawk Auth Key: werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn
Algorithm: sha256

{"message": "Hawk Authentication Successful"}

如果將key改為其他任意的字符則回傳如下結果：

{"statusCode": 401,

"error": "Unauthorized",

"message": "Bad mac",

"attributes": {

    "error": "Bad mac"

}
}

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/340706.html

標籤：其他

上一篇：C# 生成驗證碼

下一篇：Appium環境搭建