web-dev-qa-db-ja.com

OAuth2暗黙的フロー：CORSを介した更新トークンの可能な攻撃ベクトル？

現在、単一ページアプリケーション（Angular2）を実装しているため、標準の「バックエンドAPIをどのように保護するか」という問題が発生しています。

これに対する標準的なソリューションは、OAuth2 Implicit Grant Flowを使用することですが、これで問題ありません。 Web SSOソリューション（Open AM/SAML）を使用して認証し、ライセンスをチェックして、API Gateway（Mashape Kong）経由でアクセストークンを発行するカスタム認証サーバーを実装しています。

アクセストークンは（OAuth2暗黙的フローで指定されているように）リダイレクトを使用してSPAに戻され、フラグメント（https://my.spa.com/#access_token=asdfasdf&token_type=bearer&expires_in=1800）でアクセストークンが提供されます。

これまでのところ、特産品はありません。現在：アクセストークンは短期間のみ有効で、更新トークンはありません。エンドユーザーが再び承認サーバーにリダイレクトされることは望ましくありません（見た目が悪い/ちらつき/ ...）。私たちのアイデアは、Authorization Server（上記を参照）との既存のセッションを使用して、Authorization Serverの特別なエンドポイントへのCORS呼び出しを介してアクセストークンを更新（新しいトークンを作成）することです（これを/heartbeat）。

明らかに、これにはいくつかのことを行う必要があります。

  • Originは呼び出し元のアプリケーションのホストとまったく同じである必要があり、認証サーバーはそれを確認してプリフライト応答に反映する必要があります
  • クライアントアプリケーションは、withCredentials: trueをアクティブにしてCORS呼び出しを行う必要があります（FetchにはXMLHttpRequest、credentials: includeを使用）

私たちはこれのテスト実装を行いましたが、それは非常にうまく機能しているようですが、これについて専門家として皆さんに尋ねたいと思います：この種類の更新を有効にするときに（追加の）攻撃ベクトルがありますか？暗黙の付与の通常の容疑者に加えて、それはです。

よろしく、マーティン

javascriptapioauth2corsapi-gateway
3
donmartin

あなたが言及したようにセキュリティの観点からより徹底的なレビューを保証するであろう完全に異なるアプローチで行く代わりに、OpenID Connectですでに指定されているものを利用することをお勧めします-Prompt=noneの使用による即時認証モードのサポート。

SPAはリフレッシュトークンを使用できませんが、同じ機能を提供する他のメカニズムを利用できます。 ユーザーエクスペリエンスを向上させるための回避策は、Prompt=noneエンドポイントを呼び出すときに/authorizeを使用することです。ログインダイアログや同意ダイアログは表示されません。それに加えて非表示のiframeから/authorizeを呼び出し、親フレームから新しいアクセストークンを抽出すると、リダイレクトが発生しているのがユーザーに表示されません。

（ソース： Auth0-どちらを使用するかOAuth 2.0フローを使用する必要がありますか？ ;強調は私のものです）

許可サーバーは、この追加の要求パラメーターをサポートする必要があり、ユーザーによって既に許可された要求/スコープの自動承認もサポートする必要があります。

このアプローチの主な利点は、既存のほとんどの方法を利用しているため、まったく新しい異なるアプローチの場合と同様に、攻撃対象領域を大幅に増やすことはありません。

Auth0.jsライブラリ を参照して、このタイプのサイレント認証を実行する方法のリファレンス実装を確認してください。

2
João Angelo