postman認證使用篇(五) - JavaShuo

postman 認證使用篇(五)html

Authorization

儘管請求編輯器已經足夠強大去構造各類各樣的請求，可是有的時候你的請求多是須要認證，那麼就能夠嘗試使用下面的認證功能了（因爲認證的參數信息屬於敏感數據，爲了保證在協做環境中工做時數據的安全，建議使用變量）nginx

下面分別說明下拉選項中的認證方式：算法

No Auth

不須要認證，這是默認選中的npm

Bearer Auth

填寫Token進行驗證，JWT中有使用segmentfault

Basic Auth 基礎身份驗證

輸入用戶名和密碼，直接發送明文數據，在點擊Preview Request按鈕就會自動在Headers中生成authorization header.api

或者直接發送請求，也會自動把authorizationheader 添加到 Headers 中
安全

Digest Auth 摘要認證

消息摘要式身份認證是在基自己份認證上面擴展了安全性，服務器爲每個鏈接生成一個惟一的隨機數，客戶端用這個隨機數對密碼進行MD5加密，而後返回服務器，服務器也用這個隨機數對密碼進行加密，而後和客戶端傳送過來的加密數據進行比較,若是一致就返回結果
客戶端請求資源->服務器返回認證標示->客戶端發送認證信息->服務器查驗認證
服務器

過程：markdown

發送一個請求app
```
GET /auth/basic/ HTTP/1.1
 HOST: target
```

服務器返回401響應頭,要求輸入用戶憑據

HTTP/1.1 401 Unauthorized
    WWW-Authenticate: Digest realm="Digest Encrypt",nonce="nmeEHKLeBAA=aa6ac7ab3cae8f1b73b04e1e3048179777a174b3", opaque="0000000000000000",stale=false, algorithm=MD5, qop="auth"

輸入憑據後再發送請求

GET /auth/digest/ HTTP/1.1
    Accept: */*
    Authorization:  Digest username="LengWa", realm="Digest Encrypt",  qop="auth", algorithm="MD5", uri="/auth/digest/", nonce="nmeEHKLeBAA=aa6ac7ab3cae8f1b73b04e1e3048179777a174b3", nc=00000001, cnonce="6092d3a53e37bb44b3a6e0159974108b", opaque="0000000000000000", response="652b2f336aeb085d8dd9d887848c3314"

服務端驗證經過後返回數據

返回401請求頭時，對於WWW-Authenticate 各個域的做用：

realm: 是一個簡單的字符串，通常是是郵件格式
qop: 是認證的(校驗)方式，這個比較重要，對後面md5的加密過程有影響
nonce: 是一個字符串，惟一的、不重複的(還能夠包含一些有用的信息，進行驗證)
opaque: 是個字符串，它只是透傳而已，即客戶端還會原樣返回過來
username: 用戶認證的用戶名
uri: 本次資源的位置
cnonce: 客戶端隨機參數的GUID
nc: 是認證的次數，由於若是認證失敗，則仍然能夠從新發送認證信息繼續認證
response: 這個值很重要，是根據以上信息加上密碼根據必定的順序加密生成的MD5值，服務端在收到這個信息後，也根據相同的方式計算出這個值，而密碼保存在服務端。服務端根據用戶名去找密碼，計算出MD5值，若是和客戶端傳過來一致，就認證經過，不然不經過

OAuth 1.0 / OAuth 2.0

如今大多數受權登陸都是基於 OAuth 2.0

這兩種認證方式，就不具體介紹了。網上講解的比較多

不瞭解的能夠看看這個文檔:理解OAuth

Hawk authentication

hawk是一個HTTP認證方案，使用MAC(Message Authentication Code，消息認證碼算法)算法，它提供了對請求進行部分加密驗證的認證HTTP請求的方法，包括HTTP方法、請求URI和主機。

hawk方案要求提供一個共享對稱密匙在服務器與客戶端之間，一般這個共享的憑證在初始TLS保護階段創建的，或者是從客戶端和服務器均可用的其餘一些共享機密信息中得到的

舉例過程：

發起一個資源請求

GET /resource/1?b=1&a=2 HTTP/1.1
Host: 127.0.0.1:8000

服務器返回401響應頭

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Hawk

客戶端以前已經獲取一組Hawk訪問資源的資格證書在對應的服務器上資格證書包含如下的屬性：

Key identifier(Hawk Auth ID): dh37fgj492je
Key(Hawk Auth Key): werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn
Algorithm: hmac-sha-256

客戶端經過計算時間戳來生成認證報頭，並構造標準的請求字符串
```
1353832234
GET
/resource/1?b=1&a=2
127.0.0.1
8000
some-app-data
```
使用Hawk憑證中的Algorithm指定的加密算法加上Key(Hawk Auth Key)指定的key進行加密，以後把結果在通過bae64轉碼爲/uYWR6W5vTbY3WKUAN6fa+7p1t+1Yl6hFxKeMLfR6kk=

客戶單在發送請求，在Authorization頭字段包括Key identifier(Hawk Auth ID)指定的id，時間戳，以及加密生成的MAC

GET /resource/1?b=1&a=2 HTTP/1.1
Host: 127.0.0.1:8000
Authorization: Hawk id="dh37fgj492je", ts="1353832234", ext="some-app-data", mac="/uYWR6W5vTbY3WKUAN6fa+7p1t+1Yl6hFxKeMLfR6kk="

服務端收到請求後再次按相同的算法計算出MAC，並驗證Hawk憑證的有效性，若是驗證經過就返回結果

這個認證的方式 npm中有包,裏面有案例，能夠查看一下hawk

官方詳細文檔

AWS Signature

AWS的使用者可使用自定義的HTTP方案基於HMAC的加密算法去認證

參考文檔

[http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html](http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html)
[http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-use-postman-to-call-api.html](http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-use-postman-to-call-api.html)

postman 的基礎使用篇(一)
postman發送請求使用篇(二)
postman響應使用篇(三)
postman的代理使用篇(四)