ベアラートークンをiframeに保存したり、親ウィンドウに戻したりしても安全ですか？
私はセキュリティの専門家ではないので、私のWebアプリのセキュリティ設計に欠けている欠陥があるかどうかを教えてくれる人がいるかもしれないと期待しています。うまくいけば、私のポイントを理解させるのに十分なほどこれを明確に説明できるでしょう。
私のAPIを呼び出すWebサイトがあります。どちらもSSLを使用し、Azureでホストされていますが、ドメイン/サーバーが異なります。また、ASP .Net Identity 2.0およびOAuthベアラートークンを30日間の有効期限で使用して、ユーザーが「ログインしているかどうかを追跡します」.
ユーザーは、メインのWebサイト、またはサードパーティのサイトに追加できるウィジェットを使用してログインできます。
物事を安全に保つため、ウィジェットはAPIサーバー上のページを指すiframeを作成し、ログインやトランザクション処理などのすべての機能はこのiframe内で行われます。
親ページは、何かが発生する必要がある場合にpostMessageを使用してiframeと通信しますが、親ページ上の何かがそのトークンにアクセスできないようにするために、iframeのローカル/セッションストレージ内にのみ存在し、スタックに戻って通信されることはありません。
これまでのところ、すべてが意図したとおりに機能しているようですが、私は自分のWebサイトで実行されているコードのトークンを親に返す必要があるシナリオに遭遇しました。ただし、セキュリティホールが作成される可能性があるため、これを行うことをためらっています。
これが私が制御するコードにとって許容できるリスクかどうか、または私が取った一般的なアプローチに問題があるかどうかについて誰かが何か考えを持っていますか？
そのようにクリックジャッキング攻撃を防ぐことはできないため、認証/承認ページをIFrameに埋め込むことはできません。
から RCF6749、Section 10.13 "Clickjacking" ：
この形式の攻撃を防ぐために、ネイティブアプリケーションは、エンドユーザーの承認を要求するときに、アプリケーション内にブラウザーを埋め込むのではなく、外部ブラウザーを使用する必要があります（SHOULD）。最近のほとんどのブラウザーでは、iframeの回避は、（非標準の） "x-frame-options"ヘッダーを使用して許可サーバーによって実施できます。このヘッダーには、「deny」と「sameorigin」の2つの値を含めることができます。これにより、フレーミング、またはそれぞれ異なるオリジンを持つサイトによるフレーミングがブロックされます。古いブラウザでは、JavaScriptフレームバスティングテクニックを使用できますが、すべてのブラウザで効果があるとは限りません。
ここでの危険は、誰かがサイトのiframeの上に非表示のボタンをオーバーレイすることではなく、その逆です：攻撃者は「かわいい子猫を表示する」のような無害に見えるボタンを作成し、「このアプリにすべてのアクセスを許可する」をオーバーレイしますその上に "私のデータの"フレーム。ユーザーが「子猫」ボタンをクリックすると、実際には自分のアカウントへのアクセス権が攻撃者に与えられます。これを回避する唯一の方法は、iframeでフローを許可しないことです。または、リスクを負い、それと共存します。
それから、ベアラートークンには注意が必要です。トークンを持っている人は誰でも承認を得ており、すべての操作でネットワーク経由で送信されます。 access_tokenのようなものの30日間の寿命は悪い考えです。
あなた自身のアプリではそれを解決できますが、好きなように、oauth2は「リソース所有者の資格情報」フローを提供します。これは私見の良いオプションです。ただし、oauthここには本当に必要ありません。
サードパーティのウェブサイトの場合は、クライアント認証を必要とする（可能な限り）短命のaccess_tokensと長命のrefresh_tokensのサーバー側フローを使用する必要があります
ユーザーエージェント側のコンシューマー（ネイティブアプリ）の場合は、存続期間の短いトークンでクライアント側のフローを使用し、追加の予防策を講じる必要があります。または、oauthとは異なるものを使用します。oauthは非常にWeb中心です。
[〜＃〜] ps [〜＃〜]：質問に対する@HTLeeコメントが間違っていることも指摘しておきます。
これを行うことを検討している人にとっては、無記名トークンによるアプローチは避けるのが最善です。認証コード付与フローを利用できる場合、トークンはサーバー側に保存され、ブラウザに公開されることはありません（さらにセキュリティのため）。ベアラートークンアプローチでは、トークンをブラウザーに公開する必要があります
「ベアラー」はトークンのプロパティであり、「この文字列を所有している人は誰でも許可されている」ことを意味します。これは特定のフローに関連付けられておらず、実際、「承認コード」フローはaccess_token（およびオプションでrefresh_tokenと呼ばれる別のトークン）という無記名トークンを生成します。
「ベアラー」トークンの代替はMACトークンで、これはネットワーク経由で送信されることはありません。 oauth2のMACトークンの仕様はまだ標準化されていません。
それが Eran Hammerの投稿 についてであり、OPの質問に正接するだけです。