iframeにOpenIDプロバイダをロードすると、プロバイダとRPが同じドメインにあると悪い考えですか？

Question

リダイレクトするのではなく、プロバイダが完全なルック&のログインページを制御するのではなく、iframeにOpenIDプロバイダのログインページをロードしたいという疑問がたくさんあります。非常に強固なセキュリティ上の理由（主にアンチフィッシング）の場合、これは大きなノー・ノーで禁止されており、ほとんどのOpenIDプロバイダはiframe内での読み込みを拒否します。

私はOpenIDが単一の組織のWebサイトとアプリケーションのセット内で使用されている状況を提示されています。 OpenIDプロバイダには、RPのホワイトリストがあり、それらのRPにのみ応答します。 RPがユーザにそれを送信したことに基づいて、プロバイダのログインページを広範囲にカスタマイズしたいという要望がある。 （これに反対する強力なセキュリティ上の議論がある場合は、そのことについても知りたいと思います）。

これは、RPがログインページをiframeに表示できるようにするためのものです彼らは彼らが望むログインボックスの周りにどんなデザインを置くことができます。このシナリオでは、「Username」「Password」フィールドと「Login」「Forgot Password」「Register New Account」ボタンのみがプロバイダでホストされ、残りのページはRPにあり、RPのアドレスはタイトルバー。最適ではありませんが、引数は「別のサブドメインですが、同じ第2レベルのドメインなので、それでも問題はありません」

これはどういう場合か分かりません。さまざまなアプリケーションでログインページが非常に異なるため、ユーザーはフィッシングやその他の攻撃に対して脆弱です。私はこの結論で間違っていますか？私が直面している反論は、これらの懸念が同じドメインのサイトに限定された民間プロバイダには適用されないということです。

Answer 1

のiframe内のOpenIDを持っていることについての一般的な懸念は、いくつかの妥当性も、あなたの場合役割独自のプロバイダを持っています。スクリプトインジェクションに脆弱なコンポーネントがある場合、親ウィンドウからiframeデータにアクセスできるため、ユーザーの資格情報が侵害される可能性があります。

リダイレクト（通常はpop-up）では、攻撃者がスクリプトインジェクションの欠陥がないと思われるOpenIDログインページに注入する必要があるため、このリスクは制限されます。

Answer 2

これは2年後のことで、現在のところ、これは悪い考えではないと思います。具体的には、iframeを使用するプロセスを詳述しているOpenId Connect仕様（現在ドラフト21）があるためです。 RPがiframeのOPと通信できるようにします。

http://openid.net/specs/openid-connect-session-1_0.html 

私は、これは批准になるまでそれがどのくらいかわからないが、それは、これはRPでのセッションを管理するための有効なアプローチとして検討中であることを示しています。