我正在實施OAuth提供程序以保護不同的基於Web的API。最頭痛的是讓我通過OAuth保護WebSockets。是否可以使用OAuth 2.0來保護WebSocket API？
可以在瀏覽器中設置的客戶端中完全安全嗎？
如果它在瀏覽器中與使用服務器的Web應用程序相比有什麼風險？
我想使用雙腿OAuth來限制到websocket的連接，所以只有註冊的客戶端可以獲得到API的WebSocket連接而不會被拒絕。由於WebSocket連接始終（）在客戶端（從瀏覽器）建立，是否有可能保護accessToken不被盜用和濫用？
此時，唯一從Web應用程序客戶端應用程序設置基於瀏覽器的客戶端的是URL。
如果基於瀏覽器的應用程序不安全，我可以忍受這一點，但我想確保至少基於Web的應用程序具有訪問websocket的安全方式。
但是在那一點上我問自己是否需要accessToken，因爲我只能使用origin-URI作爲唯一的安全機制。
是的，你可以使用OAuth保護你的WebSocket連接。 Kaazing WebSocket Gateway擁有優雅的體系結構，可使用各種方法（基於標記，基於HTTP或基於cookie）進行身份驗證和授權。
此外，它是以一種安全的方式在Web上進行，您可能正在處理不受信任的客戶端。 （或者至少，您應該始終假設您正在處理不可信的客戶端。）
當客戶端嘗試WebSocket連接時，網關接收請求。如果特定服務（即URL）已被配置爲受保護，則客戶端將受到挑戰。
接到挑戰後，客戶需要提供一個令牌（假設這是在這種情況下配置的）。如果客戶端已經擁有令牌 - 因爲他們以前已經登錄過其他系統或網頁 - 那麼很好。如果不是，那麼它必須獲得一個。這完全取決於您選擇的安全性。在這種情況下，它會聯繫OAuth令牌提供程序以獲取令牌。這可能意味着用戶必須提供憑證。
一旦客戶端有令牌，就會將其發送到網關作爲對挑戰的迴應。網關支持標準JAAS架構，因此您可以插入登錄模塊以執行必要的身份驗證。在這種情況下，它可能會將令牌發送給令牌提供者以確定它是否是有效的令牌。
如果是，則打開WebSocket連接並繼續。如果不是，則拒絕該請求並關閉連接。
這有利於保護您的後端應用程序 - 只有有效的用戶才能通過網關。此外，由於Kaazing WebSocket Gateway可以駐留在DMZ中，因此未經身份驗證的用戶甚至不會在主防火牆內進入可信網絡。他們在外面快速失敗。
該體系結構非常強大，因爲您選擇的安全框架並不重要，Kaazing的Gateway將插入它，而不是將自己的安全機制強加給您。而且，在OAUth或OAuth2的情況下，它不需要理解或解碼令牌。令牌提供者是唯一需要理解它的人。但是如果您的令牌提供者想要爲會話指定一個持續時間，那麼它可以與令牌一起包含在內，並且網關將會遵守它。
如果基於瀏覽器的應用程序不安全，我可以忍受這一點，但我想確保至少基於Web的應用程序具有訪問websocket的安全方式。
基於Web和基於瀏覽器的應用程序可以通過正確的體系結構和實現來實現安全。在Kaazing，我們總是假設您正在處理Web上不受信任的客戶端，並據此構建我們的體系結構。
下面是有一個高層次的描述文檔的幾個部分：
問候， 羅賓 產品經理的Kaazing
一憑據授權只與執行的認證一樣安全在分發訪問令牌之前。這超出了他們所說的規格。這取決於您決定在響應證書授予時給予令牌前的任何身份驗證機制。
現在，假設您已經設置了一個安全的方式來獲得您的憑據授權，或通過常規的OAuth2請求將訪問令牌存入瀏覽器。
根據OAuth2規範，您可以免費使用MAC摘要部分，以任意數量的方式對部分進行加密或保護數據。訪問令牌在瀏覽器中的安全性取決於它包含的信息 - 通常人們將它設計爲包含最少的信息（用戶標識，到期時間，版本，摘要），並使其可以由服務器進行自我驗證（因此是摘要） 。令牌的內容幾乎是任意的。有些系統甚至將訪問「代碼」作爲代理的代理。
現在讓我們假設你有一個受保護的「安全格式」訪問令牌，並有時間限制。讓我們考慮一個真實世界的例子：Facebook和他們的OAuth2實現。無論是完整的訪問令牌還是用於服務器端憑證檢索的訪問代碼（每個都有時間限制），您都可以使用Kaazing Gateway從瀏覽器發送令牌（或代碼）以確保訪問WebSocket。
我從與Kaazing的門戶合作中解脫出來的一件事是，OAUth2確實沒有任何保證 - 您可以隨意發放任意形式的訪問令牌。確保您的憑證認證方案，access_token格式和access_token生命週期都是良好的策略決策是一個不錯的主意，那麼您就可以獲得安全性。
Kaazing Gateway將允許您向網關發送任意令牌並使用您編寫的JAAS登錄模塊驗證它們以驗證它們。政權的安全取決於你和政策決定。
問候，
史蒂芬·阿特金森
網關服務器開發者， 的Kaazing
這是否需要用戶驗證一個很好的解決方案，但我不能肯定它是否工作，如果只有客戶端需要在oauth-2草案http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-4.4中的客戶端憑據授權中進行驗證。它還表示它只能用於機密客戶。但即使你有一個機密的客戶端，然後你發送了accesstoken到瀏覽器（建立ws連接），它也被暴露了。所以爲了保護它免受重複使用，你必須允許這個accessToken只用於很短的時間或限制訪問權限。 – JustGoscha 2012-04-27 10:01:10