はい、OAuth を使用して WebSocket 接続を保護できます。Kaazing WebSocket ゲートウェイには、さまざまな方法 (トークンベース、HTTP ベース、または Cookie ベース) を使用した認証と承認のための洗練されたアーキテクチャがあります。
さらに、信頼されていないクライアントを扱う可能性のある Web 上で安全な方法で行われます。(または、少なくとも、信頼できないクライアントを扱っていると常に想定する必要があります。)
クライアントが WebSocket 接続を試みると、ゲートウェイはリクエストを受け取ります。特定のサービス (つまり、URL) が保護されるように構成されている場合、クライアントはチャレンジされます。
チャレンジを受信すると、クライアントはトークンを提供する必要があります (この場合、トークンが構成されていると仮定します)。クライアントが既にトークンを持っている場合 (以前に他のシステムまたは Web ページにサインオンしたことがあるため)、それで問題ありません。そうでない場合は、取得する必要があります。これは、セキュリティの選択に完全に依存します。この場合、OAuth トークン プロバイダーに接続してトークンを取得します。これは、ユーザーが資格情報を提供する必要があることを意味する場合があります。
クライアントがトークンを取得すると、チャレンジへの応答としてそれをゲートウェイに送信します。Gateway は標準の JAAS アーキテクチャをサポートしているため、ログイン モジュールをプラグインして必要な認証を実行できます。この場合、トークンが有効なトークンであるかどうかを判断するために、トークンをトークン プロバイダーに送信できます。
接続されている場合、WebSocket 接続が開かれ、続行できます。そうでない場合、リクエストは拒否され、接続は閉じられます。
これには、バックエンド アプリケーションを保護するという利点があります。有効なユーザーのみがゲートウェイを通過します。さらに、Kaazing WebSocket ゲートウェイは DMZ 内に存在できるため、認証されていないユーザーがメイン ファイアウォール内の信頼できるネットワークに侵入することさえありません。彼らは外側ですぐに失敗します。
このアーキテクチャは強力です。選択したセキュリティ フレームワークに関係なく、独自のセキュリティ メカニズムを課すのではなく、Kaazing のゲートウェイがそれにプラグインするからです。また、OAUth や OAuth2 の場合は、トークンを理解したりデコードしたりする必要はありません。それを理解する必要があるのは、トークン プロバイダーだけです。ただし、トークン プロバイダーがセッションの期間を指定したい場合は、それをトークンと共に含めることができ、ゲートウェイはそれを尊重します。
ブラウザーベースのアプリケーションが安全でない場合は、それを受け入れることができますが、少なくとも Web ベースのアプリケーションが WebSocket に安全にアクセスできるようにしたいと考えています。
Web ベースおよびブラウザベースのアプリケーションは、適切なアーキテクチャと実装によって安全にすることができます。Kaazing では、Web 上の信頼できないクライアントを扱っているという前提の下で常に動作し、それに応じてアーキテクチャを構築しています。
高レベルの説明があるドキュメントのいくつかのセクションを次に示します。
よろしく、Kaazing、Robin プロダクト マネージャー