Web應用程序和WebService的身份驗證

Question

我目前正在開發一個包含Web應用程序和客戶端軟件的應用程序。客戶端通過Web服務進行通信，同時支持SOAP和Protobuffer實現。

初始登記經由web應用，這依賴於用戶名+密碼認證以後完成。

完成註冊過程後，所有的功能也可通過客戶端，這將僅通過HTTPS通信。爲了驗證web服務調用，我正在考慮三種可能的方法：

1. 在每條消息中包含用戶名和密碼。但是，在每個請求中包含憑據是否真的是一種很好的做法，即使通過HTTPS進行保護？

2. 不在第一Web服務請求的用戶名和密碼。客戶端然後獲取用於所有未來請求的令牌。 （注意：強制用戶將服務器生成的令牌複製到客戶端應用程序是不可接受的。）只有在用戶撤銷令牌時，他需要再次發送其用戶名和密碼以獲取新令牌。這種基於令牌的方法似乎很常見，例如Google，AWS和Rackspace正在使用它們很多。但是在這種情況下它真的會得到回報嗎？

3. 哈希客戶端上的密碼，聽起來是個不錯的解決方案。不過，我想在服務器端加密加密的密碼。添加僅用於取鹽的請求聽起來不像是最佳解決方案，還是它？

是否有任何最佳實踐或技巧？我無法準確找到符合這些要求的太多信息。 目前我會與2），但我還沒有真正確信。

該項目是基於Java，Apache的CXF，Protobuffers和四郎，但應該不會有太大的爲一般問題的影響......

Answer 1

如果你只通過認證和既不關注保密性也不完整性，您可以通過確保處理：

• HTTP傳輸層，使用HTTP基本驗證（用戶+密碼的每個消息）+最終HTTPS保密的，但是當你發現（溶液1）它是一種舊的學校和保持本地緩存中的用戶/密碼不是什麼大不了的，但不能被建議。
• 使用安全令牌的消息級別（肥皂消息），但我不知道Protobuffer
• 應用程序級別（解決方案2和3），這是Google，Amazon，Ebay和其他人的工作方式。您不會要求用戶複製/粘貼他的令牌，您將從用戶/密碼生成一個

我會使用令牌保護應用程序級別，因爲從服務器獲取鹽幾乎就像獲取令牌並沒有增加更多的安全性（一個安全的鹽應該只從你知道，如果頻道被保護，它意味着從給定的密碼和用戶名得到令牌也是安全的）。

一個更好的，但更復雜的解決方案將SSL證書，無論是在瀏覽器和客戶端軟件提供的使用。