創建OAuth API時的應用程序令牌/祕密

Question

背景：我正在使用node.js和express來創建API。我在API服務器中以標準的用戶/用戶密鑰/祕密方式實現了OAuth（與Twitter，Facebook等相同）。我希望第三方能夠連接到我的API，再次以與這些通用API相同的方式。

通常情況下，客戶端將連接一個應用程序令牌/祕密（例如，您創建一個Facebook應用程序作爲Facebook開發人員，這些給你）。然而，有時候客戶端不能爲應用程序提供祕密，因爲代碼是以不安全的方式實現的。具體來說，我指的是Javascript庫。例如，開發人員不希望在Javascript代碼中公開他們的應用程序祕密，因爲它是明文的，可以被惡意用戶讀取。

我注意到Facebook避免了這個問題。開發人員只需向Javascript庫提供一個應用程序令牌（非祕密）。我不明白如何爲我的API提供類似的選項，而不會從根本上使我的庫不安全。也就是說，如果請求是通過Javascript客戶端庫向API提出的，而沒有提供良好安全的令牌/密碼，那麼這些請求如何通過OAuth API進行身份驗證？

在智能上，我能想到的最佳解決方案是通過HTTPS連接在Javascript客戶端庫和API服務器之間進行某種令牌切換，以便爲庫返回一個祕密。不過，我不太確定我如何確保這一切換，以防止惡搞。

Answer 1

在大多數情況下，遵循標準比實施一些自定義方式更好。 OAuth2指定4 methods in the latest draft (28)來執行授權授權流程。 隱含流量是您在Facebook上看到的流量。

作爲標準表示爲：

當隱含授予流動過程中發出的訪問令牌，授權服務器不驗證客戶端。在某些情況下，可以通過用於將訪問令牌傳遞給客戶端的重定向URI來驗證客戶端身份。訪問令牌可能暴露給資源所有者或具有對資源所有者的用戶代理的訪問的其他應用程序。

隱補助改善一些客戶端（如作爲在瀏覽器應用中實現的客戶端），因爲它減少以獲得訪問令牌所需的往返次數的響應性和效率。但是，應該權衡這種便利與使用隱式授權的安全含義，特別是在授權代碼授權類型可用的情況下。

它有一些安全缺陷。

但據我所見，其他方法不適用於您，因爲它們向客戶端（第三方網站所有者）或資源所有者（用戶）公開祕密，所以您應該留下來有了這個。