5.4 REST API常見認證方式

表述性狀態(tài)傳遞（Representational State Transfer，REST）是一套新興的Web通信協(xié)議，訪問方式和普通的HTTP類似，平臺接口分GET和POST兩種請求方式。REST接口為第三方應(yīng)用提供了簡單易用的API調(diào)用服務(wù)，第三方開發(fā)者可以快速、高效、低成本地集成平臺API。REST API常見的認證方式有HTTP Digest、API Key、OAuth2、HMAC和JWT（參見5.2.5節(jié)）等。

5.4.1 HTTP Digest

摘要認證（Digest Authentication）是服務(wù)器端以nonce（響應(yīng)中包含信息）進行質(zhì)詢，客戶端以用戶名、密碼、nonce、HTTP方法和請求的URI等信息為基礎(chǔ)產(chǎn)生的response（響應(yīng)）信息進行認證的方式。

摘要認證的步驟如下。

1）客戶端訪問一個受HTTP摘要認證保護的資源。

2）服務(wù)器返回401狀態(tài)及nonce等信息，要求客戶端進行認證。

3）客戶端將以用戶名、密碼、nonce值、HTTP方法和被請求的URI為基礎(chǔ)而加密（默認為MD5算法）的摘要信息返回給服務(wù)器。

認證必須的五個情報：

● realm：響應(yīng)中包含信息。

● nonce：響應(yīng)中包含信息。

● username：用戶名。

● digest-uri：請求的URI。

● response：以上面4個信息加密碼信息，使用MD5算法得出的字符串。

4）如果認證成功，則返回相應(yīng)的資源；如果認證失敗，則仍返回401狀態(tài)，要求重新進行認證。

注意事項如下。

● 避免將密碼作為明文在網(wǎng)絡(luò)上傳遞，相對提高了HTTP認證的安全性。

● 當用戶為某個realm首次設(shè)置密碼時，服務(wù)器保存的是以用戶名、realm和密碼為基礎(chǔ)計算出的哈希值（ha1），而非密碼本身。

● 如果qop=auth-int，在計算ha2時，除了包括HTTP方法、URI路徑外，還包括請求實體、主體，從而防止PUT和POST請求被人篡改。

● 因為nonce本身可以被用來進行摘要認證，所以也無法確保認證后傳遞過來的數(shù)據(jù)的安全性。

5.4.2 API KEY

API KEY非常適合開發(fā)人員快速入門。一般會分配app_key、sign_key兩個值。將通知所有參數(shù)，按參數(shù)名1參數(shù)值1…參數(shù)名n參數(shù)值n的方式進行連接，得到一個字符串，然后在此字符串前添加通知驗證密鑰（sign_key，不同于app_key），計算ha1值，轉(zhuǎn)成小寫。

比如，請求的參數(shù)為：

通常，API KEY可以完全訪問API可以執(zhí)行的每個操作，包括寫入新數(shù)據(jù)或刪除現(xiàn)有數(shù)據(jù)。如果在多個應(yīng)用中使用相同的API密鑰，則被破壞的應(yīng)用可能會損壞用戶的數(shù)據(jù)，而無法輕松停止該應(yīng)用。有些應(yīng)用程序允許用戶生成新的API密鑰，甚至可以有多個API密鑰，可以選擇撤銷API密鑰。更改API密鑰的能力提高了安全性。

注意：許多API密鑰作為URL的一部分在查詢字符串中發(fā)送，這使得很容易被其他人發(fā)現(xiàn)。更好的選擇是將API密鑰放在Authorization標頭中，即Authorization:Apikey 1234567890abcdef。

5.4.3 OAuth2

OAuth是使用API訪問用戶數(shù)據(jù)的更好方式。與API密鑰不同，OAuth不需要用戶通過開發(fā)人員門戶進行探索。事實上，在最好的情況下，用戶只需單擊一個按鈕即可讓應(yīng)用程序訪問其賬戶。OAuth，特別是OAuth2，是幕后流程的標準，用于確保安全處理這些權(quán)限。

最常見的OAuth實現(xiàn)使用這些令牌中的一個或兩個。

● 訪問令牌：像API密鑰一樣發(fā)送，它允許應(yīng)用程序訪問用戶的數(shù)據(jù)；訪問令牌可以到期。

● 刷新令牌：是OAuth流的一部分，刷新令牌如果已過期則檢索新的訪問令牌。

與API密鑰類似，可以在很多地方找到OAuth訪問令牌，如查詢字符串、標題和其他位置。由于訪問令牌就像一種特殊類型的API密鑰，因此最有可能放置在授權(quán)頭，如下所示：

訪問和刷新令牌不應(yīng)與客戶端ID和客戶端密鑰混淆。這些值可能看起來像一個類似的隨機字符集，用于協(xié)商訪問和刷新令牌。

與API密鑰一樣，任何擁有訪問令牌的人都可能會調(diào)用有害操作，如刪除數(shù)據(jù)。但是，OAuth對API密鑰提供了一些改進。對于初學者來說，訪問令牌可以綁定到特定的范圍，這限制了應(yīng)用程序可以訪問的操作類型和數(shù)據(jù)。此外，與刷新令牌相結(jié)合，曾使用過的訪問令牌將會過期，因此舊訪問令牌被泄露所產(chǎn)生的負面影響有限。最后，即使不使用刷新令牌，仍然可以撤銷訪問令牌。

5.4.4 HMAC

HMAC運算利用哈希算法，以一個密鑰和一個消息作為輸入，生成一個消息摘要作為輸出。

HMAC的認證流程如下。

1）由客戶端向服務(wù)器發(fā)出一個驗證請求。

2）服務(wù)器接收到此請求后，生成一個隨機數(shù)并通過網(wǎng)絡(luò)傳輸給客戶端（此為質(zhì)詢）。

3）客戶端將收到的隨機數(shù)提供給ePass，ePass使用該隨機數(shù)與存儲在ePass中的密鑰進行HMAC-MD5運算，并得到一個結(jié)果作為認證證據(jù)傳給服務(wù)器（此為響應(yīng)）。

4）與此同時，服務(wù)器也使用該隨機數(shù)與存儲在服務(wù)器數(shù)據(jù)庫中的該客戶密鑰進行HMAC-MD5運算，如果服務(wù)器的運算結(jié)果與客戶端傳回的響應(yīng)結(jié)果相同，則認為客戶端是一個合法用戶。

由上面的介紹可以看出，HMAC算法更像是一種加密算法，它引入了密鑰，其安全性已經(jīng)不完全依賴于所使用的HASH算法，其安全性體現(xiàn)在以下幾點。

● 使用的密鑰是雙方事先約定的，第三方不可能知道。

● 作為非法截獲信息的第三方，能夠得到的信息只有作為“挑戰(zhàn)”的隨機數(shù)和作為“響應(yīng)”的HMAC結(jié)果，無法根據(jù)這兩個數(shù)據(jù)推算出密鑰。

● 由于不知道密鑰，所以無法仿造出一致的響應(yīng)。

大多數(shù)的語言都實現(xiàn)了HMAC算法，比如PHP的mhash、Python的hmac.py和Java的MessageDigest類，在Web驗證中使用HMAC也是可行的，用JS進行MD5運算的速度也比較快。