RESTful身份驗證

RESTful身份驗證的含義是什麼？它是如何工做的？ 我沒法在Google上找到一個很好的概述。 我惟一的理解是你在URL中傳遞會話密鑰（remeberal），但這多是很是錯誤的。

---

#1樓

我懷疑那些熱心地喊「HTTP身份驗證」的人是否嘗試過用REST建立一個基於瀏覽器的應用程序（而不是機器到機器的Web服務）（沒有冒犯的意圖 - 我只是以爲他們沒有遇到過複雜的問題） 。

我在RESTful服務上使用HTTP身份驗證時發現的問題是生成可在瀏覽器中查看的HTML頁面：

• 用戶一般會獲得一個醜陋的瀏覽器製做的登陸框，這對用戶不友好。 你不能添加密碼檢索，幫助框等。
• 以不一樣的名稱註銷或登陸是一個問題 - 瀏覽器將繼續向站點發送身份驗證信息，直到您關閉窗口
• 超時很難

剷球這些逐點很是有見地的文章是在這裏 ，可是這致使了不少特定瀏覽器的JavaScript兩輪牛車，變通辦法變通辦法，等等的。 所以，它也不是向前兼容的，所以在發佈新瀏覽器時須要不斷維護。 我不認爲乾淨清晰的設計，並且我以爲這是一項額外的工做和頭痛，因此我能夠熱情地向個人朋友展現個人REST徽章。

我相信cookie是解決方案。 但等等，餅乾是邪惡的，不是嗎？ 不，他們不是，餅乾常用的方式是邪惡的。 Cookie自己只是一條客戶端信息，就像瀏覽器在瀏覽時會跟蹤的HTTP身份驗證信息同樣。 這條客戶端信息在每次請求時都會發送到服務器，就像HTTP身份驗證信息同樣。 在概念上，惟一不一樣的是，這片客戶端狀態的內容能夠由服務器做爲其響應的一部分來肯定。

經過使用如下規則使會話成爲RESTful資源：

• 會話將密鑰映射到用戶標識（多是超時的最後動做時間戳）
• 若是存在會話 ，則表示該密鑰有效。
• 登陸意味着POST到/ sessions，新密鑰被設置爲cookie
• 註銷意味着刪除/ sessions / {key}（使用重載的POST，記住，咱們是瀏覽器，HTML 5還有很長的路要走）
• 經過在每一個請求時將密鑰做爲cookie發送並檢查會話是否存在且有效來完成身份驗證

如今，與HTTP身份驗證的惟一區別在於，身份驗證密鑰由服務器生成併發送給不斷髮送回來的客戶端，而不是客戶端從輸入的憑據計算它。

converter42補充說，當使用https（咱們應該）時，重要的是cookie將設置其安全標誌，以便永遠不會經過非安全鏈接發送身份驗證信息。 好極了，本身沒見過。

我認爲這是一個運行良好的充分解決方案，但我必須認可，我不足以識別此方案中的潛在漏洞 - 我所知道的是，數百個非RESTful Web應用程序使用的基本相同登陸協議（PHP中的$ _SESSION，Java EE中的HttpSession等）。 cookie頭內容僅用於尋址服務器端資源，就像接受語言可能用於訪問翻譯資源同樣，等等。 我以爲它是同樣的，但也許其餘人不同？ 大家以爲怎麼樣？

---

#2樓

@skrebel（ http://www.berenddeboer.net/rest/authentication.html ）提到的「很是富有洞察力」的文章討論了一種使人費解但卻很是破碎的身份驗證方法。

您能夠嘗試訪問該頁面（應該只對通過身份驗證的用戶可查看） http://www.berenddeboer.net/rest/site/authenticated.html，無需任何登陸憑據。

（對不起，我沒法對答案發表評論。）

我會說REST和身份驗證根本不混合。 REST意味着無狀態，但「通過身份驗證」是一種狀態。 你不能將它們放在同一層。 若是你是一個RESTful的擁護者並對國家不滿，那麼你必須使用HTTPS（即將安全問題留給另外一層）。

---

#3樓

首先，RESTful Web服務是STATELESS （或換句話說， SESSIONLESS ）。 所以，RESTful服務沒有也不該該包含會話或cookie的概念。 在RESTful服務中進行身份驗證或受權的方法是使用RFC 2616 HTTP規範中定義的HTTP Authorization標頭。 每一個請求都應包含HTTP Authorization標頭，而且請求應經過HTTP（SSL）鏈接發送。 這是在HTTP RESTful Web服務中進行身份驗證和驗證請求受權的正確方法。 我已經爲Cisco Systems的Cisco PRIME Performance Manager應用程序實現了RESTful Web服務。 做爲該Web服務的一部分，我也實現了身份驗證/受權。

---

#4樓

說實話，我在這裏看到了很好的答案，可是讓我感到困擾的是當有人將整個無狀態概念推向一個極端的教條時。 它讓我想起那些只想擁抱純粹OO的老Smalltalk粉絲，若是某些東西不是一個對象，那麼你作錯了。 給我一個休息時間。

RESTful方法應該讓您的生活更輕鬆，減小會話的開銷和成本，嘗試遵循它，由於這是明智的作法，可是你遵循一個學科（任何學科/指南）到極端的那一刻再也不提供預期的好處，那麼你作錯了。 今天一些最好的語言同時具備函數式編程和麪向對象。

若是您解決問題的最簡單方法是將身份驗證密鑰存儲在cookie中並在HTTP標頭上發送，那麼請執行此操做，只是不要濫用它。 請記住，若是會話變得沉重並且很大，若是全部會話都包含一個包含密鑰的短字符串，那麼會話有什麼大不了？

我願意在評論中接受更正，但我只是沒有看到（到目前爲止）讓咱們的生活變得悲慘的一點，只是避免在咱們的服務器中保留一個大的哈希詞典。

---

#5樓

這是一個真正徹底RESTful的身份驗證解決方案：

1. 在身份驗證服務器上建立公鑰/私鑰對。
2. 將公鑰分發給全部服務器。

3. 當客戶端進行身份驗證時：

   3.1。 發出包含如下內容的令牌：

   • 到期時間
   • 用戶名（可選）
   • 用戶IP（可選）
   • 密碼哈希（可選）

   3.2。 使用私鑰加密令牌。

   3.3。 將加密的令牌發送回用戶。

4. 當用戶訪問任何API時，他們還必須傳遞其身份驗證令牌。

5. 服務器能夠經過使用auth服務器的公鑰解密來驗證令牌是否有效。

這是無狀態/ RESTful身份驗證。

請注意，若是包含密碼哈希，則用戶還將發送未加密的密碼以及身份驗證令牌。 服務器能夠經過比較哈希來驗證密碼是否與用於建立身份驗證令牌的密碼匹配。 使用HTTPS之類的安全鏈接是必要的。 客戶端的Javascript能夠處理獲取用戶密碼並將其存儲在客戶端，能夠存儲在內存中，也能夠存儲在cookie中，可能使用服務器的公鑰進行加密。