iframe基本認証またはトークンセキュリティ
2つのサイトがあり、どちらも信頼されています。
Site1では、site2のユーザーのユーザー名とパスワードを保存します。
basic auth（すべてHTTPS経由）を介して、site1のバックエンドでsite2にAPI呼び出しを行います。
暗号化されていないパスワードを保存することは安全ではありませんが、データ侵害がないと仮定すると、この通信はバックエンドで安全です。 しかし、フロントエンドはどうですか？保存されたユーザー名とパスワードをフロントエンドに送信する人を見てきましたが、これは誰かがあなたのパスワードを入手する簡単な方法のようです。
バックエンドで認証トークンを生成し、それをフロントエンドに渡すの方が良いようですが、まだセキュリティ上の問題が発生する可能性があるので、少し心配しています。
私はoauthサーバーをsite2に必要に応じて実装することに問題はありませんが、これまでのところ、基本認証はより単純であり、可能であればそれを使用したいと思います。
あなたが提案しているものは非常に危険であり、セキュリティのベストプラクティスに反しています。これの1つの問題は、ユーザーが異なるサービス間で同じパスワードを再利用する傾向があることです。つまり、漏洩したパスワードが1つあると、アカウントの多くが脆弱なままになる可能性があります。 （例： 最近のMark Zuckerberg hack ）。これは、SQLインジェクションなどの欠陥が原因でデータベースの内容が時々リークするという事実と相まって。
これらのパスワードの再利用者を保護するために、違反は多くのサイトを脆弱にするため、ウェブサイトはパスワードの値を保護するために非常に努力する必要があります。
つまり、安全で元に戻せない形式でのみパスワードを保存します。 パスワードを安全にハッシュする方法は？ で科学について読むことができますが、デフォルトのパラメーターでbcryptを使用する場合はおそらく良いでしょう。
ユーザー名/パスワード認証のみをサポートするサードパーティのサイトと統合していて、そのサイトが安全な認証メカニズムを提供することを望まない場合、リモートサイトのパスワードを保存することは理にかなっているでしょう（リモートサイトではパスワードを安全に暗号化する必要があります）使用する）。しかし、あなたはリモートサイトを所有しているので、正しいことを行い、パスワードよりも優れたログインモデルをサポートしてください。
いくつかの可能な戦略は次のとおりです。
- OAuth（おそらく OpenID 経由）、SAML 2、またはシングルサインオンをサポートするその他の既存のシステム。
- SSL相互認証 を使用すると、site2は登録時にクライアント証明書を生成し、それをsite1に渡すことができます。次に、site1のデータベース違反は証明書のみを公開し、ユーザーのパスワードは公開しません（他のサイトでも同じパスワードを使用することに注意してください）。
- なりすまし （おそらく誰かがコメントにもっと良い参照を追加できるでしょうか？）は、site1とsite2の間に強い信頼モデルがある場合に機能します。基本的に、サイトに同じ作成者とデプロイヤーがいる場合、資格情報なしで
JoeUserによって呼び出されているように見せかけるように、site1にsite2に指示することができます。 Site1は、悪意のあるユーザーがこの機能を使用できないようにするために、site2に対して安全に認証する必要があります。 - Site1で必要なときはいつでも、ユーザーにsite2パスワードをsite1に入力してもらいます。
解決策は他にもあると思いますが、パスワードをリバーシブル形式（暗号化など）で保存することはお勧めできません。また、パスワードをクリアテキストとして保存することは許されません。