我們在設(shè)計(jì)REST(Representational State Transfer)風(fēng)格的Web service API,有一個(gè)問題經(jīng)常要考慮，就是如何設(shè)計(jì)用戶認(rèn)證的體系(Authentication).?

比較傳統(tǒng)的做法是首先有一個(gè)登陸的API，然后服務(wù)器返回一個(gè)session ID,后續(xù)的操作客戶端都必須帶上這個(gè)session ID，但是這樣的，服務(wù)就變成了有狀態(tài)了，不符合REST風(fēng)格的原則。另外，由于負(fù)載均衡的存在，必須有公共存儲(chǔ)來保存用戶的Session，這也增加了系統(tǒng)的復(fù)雜度。?

所以比較好的做法是每次都傳遞認(rèn)證信息，這樣系統(tǒng)就是無狀態(tài)的，當(dāng)然由于每次都需要認(rèn)證，必然降低了一些效率，必要的時(shí)候要考慮緩存用戶信息在服務(wù)器端。?

有幾點(diǎn)要注意：?

1.密碼不能傳播?

一個(gè)比較低級的錯(cuò)誤是通訊時(shí)，由客戶端傳遞用戶名和密碼到服務(wù)器端認(rèn)證，這樣很容易被黑客攻擊造成密碼泄露。?

標(biāo)準(zhǔn)的做法是使用HMAC(Hash-based Message Authentication Code),想法就是不傳播password，而傳播content和password的混合hash值。我們來看看Amazon S3怎么做認(rèn)證的。?

Amazon對每一個(gè)用戶有一個(gè)AWSAccessKeyId和一個(gè)AWSSecretAccessKey，每次HTTP請求需要一個(gè)Id和一個(gè)Autherticantion信息。 比如：?

GET /photos/puppy.jpg HTTP/1.1? Host: johnsmith.s3.amazonaws.com? Date: Tue, 27 Mar 2007 19:36:42 +0000 Authorization: AWS 0PN5J17HBGZHT7JJ3X82: xXjDGYUmKxnwqr5KXNPGldn5LbA=? 這個(gè)Authorization的頭是這樣產(chǎn)生的： 其中YourSecretAccessKeyID用的就是AWSSecretAccessKey。? Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;? Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );?StringToSign = HTTP-Verb + "\n" +? Content-MD5 + "\n" +? Content-Type + "\n" +? Date + "\n" +? CanonicalizedAmzHeaders +? CanonicalizedResource;?CanonicalizedResource = [ "/" + Bucket ] +? <HTTP-Request-URI, from the protocol name up to the query string> +? [ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"];? CanonicalizedAmzHeaders = <described below>?

這樣服務(wù)端就很容易根據(jù)用戶信息來驗(yàn)證信息的正確與否。?

驗(yàn)證信息的位置?

驗(yàn)證信息可以放在HTTP HEADER里面也可以放在HTTP URL里面，象這樣：?

GET /photos/puppy.jpg?AWSAccessKeyId=0PN5J17HBGZHT7JJ3X82&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1? Host: johnsmith.s3.amazonaws.com? Date: Mon, 26 Mar 2007 19:37:58 +0000?

放在HTTP HEADER里面的好處是URL比較干凈整潔，適合放在internet與人分享，而放在URL里面則有利于發(fā)布私有的訪問權(quán)限給第三方。?

如何防范重放攻擊(Replay attack)??

理論上，黑客可以竊取你的通訊報(bào)文，然后重新發(fā)送來通過認(rèn)證。有幾種可能的solution.?

客戶端所以向服務(wù)器申請一個(gè)隨機(jī)數(shù)，然后這個(gè)隨機(jī)數(shù)作為下次通訊的key，一旦使用過后就立即失效，也就是所謂的”一次一密”。這種方法的好處是很安全，但是增加通訊量，而且由于負(fù)載均衡的存在，必須有公共存貯保存這個(gè)key。?

b.服務(wù)器端保存使用過的authertication信息，只要是使用過的就拒絕再次使用。這種方法不需要客戶端支持，但是需要公共空間來保持歷史記錄。?

c.使用時(shí)間戳。做法就是認(rèn)證信息中含有時(shí)間信息，這樣服務(wù)器端就可以拒絕時(shí)間相隔太長的請求，認(rèn)為其已經(jīng)過期。這種做法需要服務(wù)器端和客戶端有某種形式的時(shí)間同步。?

4.要不要使用HTTPS??

如果安全度要求很高或者是針對internet的API，無疑應(yīng)該使用HTTPS，來避免內(nèi)容被竊取的可能。?

如果只是在局域網(wǎng)范圍或者可信賴的計(jì)算環(huán)境，則使用HTTP來提高一點(diǎn)效率。?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的Restful HMAC认证的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。