RESTful服務的用戶身份驗證

Question

我有當前的客戶羣。我想通過RESTful服務（通過應用程序）讓他們訪問有關他們自己的某些細節。

我想給客戶提供儘可能少的麻煩，因此我正在考慮爲每個客戶生成一個UUID，然後讓他們通過提供他們的UUID作爲標識來訪問REST。

例如：http://www.example.org/rest/value/UUID或http://www.example.org/rest/value將UUID作爲HTTP基本身份驗證通過TLS。

我的擔心是安全。請記住，我對這些概念中的一些是新手。使用按需生成的UUID作爲某個客戶的「證明」，我的主要擔憂是什麼？

如果我的上述情況應該對有人嗅出UUID開放，如果我理論上能夠在傳輸過程中隱藏UUID，也請將其合併。

我知道UUID不是非常容易理解，但輸入被認爲是通過URL/QR /類似的。

Answer 1

將UUID用作有效用戶的固定標識符是有風險的。 UUID生成爲be unique, not random。如果攻擊者擁有合法的UUID，他可能會嘗試猜測其他用戶的標識符。

固定的標識符也很容易泄漏。即使您使用HTTPS在傳輸通道上隱藏標識符，仍然存在用戶使用複製鏈接到電子郵件或某人從屏幕上塗抹標識符的風險。

在HTTP標頭中發送標識符會更安全一些，因爲HTTP標頭不會反映在鏈接中或顯示在屏幕上。但是，如果標識符泄漏，攻擊者可以輕鬆地模擬標識符被盜用的用戶。

這就是爲什麼大多數身份驗證系統生成（會話）標識符或令牌在有限的時間內有效。如果它被盜，那麼它可以用於有限的窗口。

您沒有提及您運行的平臺或REST服務是在互聯網上還是在Intranet上訪問。在後一種情況下，在Windows Active Directory域中，像Integrated Windows Authentication這樣的東西可能是最少麻煩的（您使用用戶的登錄會話）。

否則，你應該看看一些JWT based authentication機制。

Answer 2

考慮實施基於OpenID Connect 1.0規範的認證層。在這種情況下，認證會話的提供者在應用程序的外部。 OpenID規範是可擴展的，所以你可以使用加密，如果你想。

根據需求爲每個客戶生成的UUID並不能保證安全性。從HTTP會話中嗅出UUID或其他明文信息並不困難。 Open ID Connect的不同之處在於它爲應用程序定義了一種方法來建立經過驗證的會話並使用唯一的會話標識符來驗證每個後續請求。

希望總結有幫助。 有關於它如何在這裏工作的更多信息http://openid.net/connect/faq/