web-dev-qa-db-ja.com

OAuth 2.0でWebSocketAPIを保護することは可能ですか?

さまざまなWebベースのAPIを保護するためにOAuthプロバイダーを実装しています。最も頭痛の種は、OAuthを介してWebSocketを保護することです。

ブラウザに設定されているクライアントで完全に安全に実行できますか?

サーバーを備えたWebアプリケーションと比較して、ブラウザーにある場合のリスクは何ですか?

2本足のOAuthを使用してWebSocketへの接続を制限し、登録済みのクライアントのみが拒否されることなくAPIへのWebSocket接続を取得できるようにします。WebSocket接続は常に(!) (ブラウザから)クライアント側で確立された場合、accessTokenが盗まれたり誤用されたりするのを防ぐことは可能ですか?
その時点で、Webアプリケーションクライアントアプリからブラウザベースのクライアントを設定するのはURLだけです。

ブラウザベースのアプリケーションが安全でない場合、私はそれで生きることができますが、少なくともWebベースのアプリケーションがWebSocketにアクセスするための安全な方法を持っていることを確認したいと思います。

しかし、その時点で、accessTokenが必要かどうかを自問します。なぜなら、Origin-URIを唯一の安全なメカニズムとして使用できるからです。

19
JustGoscha

はい、OAuthを使用してWebSocket接続を保護できます。 Kaazing WebSocket Gateway は、さまざまな方法(トークンベース、HTTPベース、またはCookieベース)を使用した認証と承認のための洗練されたアーキテクチャを備えています。

さらに、信頼できないクライアントを処理している可能性のあるWeb上で安全な方法で実行されます。 (または、少なくとも、信頼できないクライアントを扱っていると常に想定する必要があります。)

クライアントがWebSocket接続を試みると、ゲートウェイはリクエストを受信します。特定のサービス(つまりURL)が保護されるように構成されている場合、クライアントはチャレンジされます。

チャレンジを受信すると、クライアントはトークンを提供する必要があります(この場合はそれが構成されていると想定しています)。クライアントがすでにトークンを持っている場合(以前に他のシステムまたはWebページにサインオンしたことがあるため)、それは素晴らしいことです。そうでない場合は、入手する必要があります。これは、セキュリティの選択に完全に依存します。この場合、トークンを取得するためにOAuthトークンプロバイダーに接続します。これは、ユーザーが資格情報を提供する必要があることを意味する場合があります。

クライアントがトークンを取得すると、チャレンジへの応答としてそれをゲートウェイに送信します。ゲートウェイは標準のJAASアーキテクチャをサポートしているため、ログインモジュールをプラグインして必要な認証を実行できます。この場合、それが有効なトークンであるかどうかを判断するために、トークンをトークンプロバイダーに送信する場合があります。

そうである場合、WebSocket接続が開かれ、続行できます。そうでない場合、要求は拒否され、接続が閉じられます。

これには、バックエンドアプリケーションを保護するという利点があります。有効なユーザーのみがゲートウェイを通過します。さらに、Kaazing WebSocket GatewayはDMZに存在できるため、認証されていないユーザーがメインファイアウォール内の信頼できるネットワークに入ることさえありません。彼らは外側で速く失敗します。

このアーキテクチャは、選択したセキュリティフレームワークに関係なく、独自のセキュリティメカニズムを課すのではなく、Kaazingのゲートウェイがプラグインするため強力です。また、OAUthまたはOAuth2の場合、トークンを理解またはデコードする必要はありません。トークンプロバイダーだけがそれを理解する必要があります。ただし、トークンプロバイダーがセッションの期間を指定します。これはトークンと一緒に含めることができ、ゲートウェイはそれを尊重します。

ブラウザベースのアプリケーションが安全でない場合、私はそれで生きることができますが、少なくともWebベースのアプリケーションがWebSocketにアクセスするための安全な方法を持っていることを確認したいと思います。

Webベースおよびブラウザベースのアプリケーションは、適切なアーキテクチャと実装で安全にすることができます。 Kaazingでは、常にWeb上で信頼できないクライアントを処理していることを前提として運用し、それに応じてアーキテクチャを構築しています。

ここに、高レベルの説明があるドキュメントのいくつかのセクションがあります。

よろしく、ロビンプロダクトマネージャー、Kaazing

8

資格情報の付与は、アクセストークンを配布する前に実行される認証と同じくらい安全です。それは彼らが言う仕様の外です。したがって、これは、資格情報の付与に応じてトークンを配布する前に配置することを決定した認証体制によって異なります。

ここで、資格情報の付与を取得するための安全な方法を設定したか、通常のOAuth2リクエストを介してブラウザにアクセストークンを取得したと仮定します。

OAuth2仕様では、部分をMACダイジェストしたり、部分を暗号化したり、そのトークン内のデータをさまざまな方法で保護したりできます。ブラウザのアクセストークンのセキュリティは、含まれている情報によって異なります。多くの場合、最小限の情報(ユーザーID、有効期限、バージョン、ダイジェスト)を含むように設計し、サーバーで自己検証可能にします(したがってダイジェスト)。 。トークンの内容は事実上任意です。一部のシステムは、トークンのプロキシとしてアクセス「コード」を提供します。

ここで、時間制限のある保護された「セキュアフォーマット」アクセストークンがあると仮定しましょう。実際の例を考えてみましょう:FacebookとそのOAuth2実装。フルアクセストークンでも、サーバー側の資格情報を取得するためのアクセスコード(それぞれ時間制限あり)でも、Kaazing Gatewayを使用して、ブラウザーからトークン(またはコード)を送信し、WebSocketへのアクセスを保護できます。

Kaazingのゲートウェイでの作業から私が奪ったことの1つは、OAUth2は実際には何も保護しないということです。つまり、任意の形式のアクセストークンを自由に配布できます。資格情報認証スキーム、access_token形式、およびaccess_tokenライフタイムがすべて適切なポリシー決定であることを確認することをお勧めします。そうすれば、セキュリティを確保できます。

Kaazing Gatewayを使用すると、任意のトークンをGatewayに送信し、それらを検証するために作成したJAASログインモジュールを使用してそれらを検証できます。政権の安全はあなたと政策決定次第です。

よろしく、

スティーブンアトキンソン

ゲートウェイサーバー開発者、Kaazing

3
nowucca