リソースサーバーとログインサーバーを分離するのはなぜですか？
this リンクで説明されているように、OAuthは、ログインサーバーとリソースサーバーを分離する必要があることを指定します。リソースサーバーの1つがハッキングされても、パスワードデータが失われます。アプリケーションが使用するすべてのログイン資格情報が単一のサーバー上にあります。これにより、ログイン資格情報を保持するサーバーの数が減ります。これにより、アプリケーションの1つがハッキングされても、理論上は失われませんログイン資格情報ですが、これですべてです。認証サーバーがハッキングされた場合はどうなりますか？OAuthの仕様から何が起こるかはわかりません。あなたはすべてのことをしていませんか？このアーキテクチャを使用して1つのバスケットで？
これにより、アプリケーションの1つがハッキングされた場合でも、理論的にはログイン資格情報を失うことはありません。しかし、それで終わりです。
いいえ、追加の利点（またはおそらく主な利点）は、リソース所有者が資格情報を提供することなく、リソースのサブセットへの一時的なアクセスをクライアントに与えることができることです。リンクしたドキュメントから：
たとえば、エンドユーザー（リソース所有者）は印刷を許可できます
写真に保存されている保護された写真へのサービス（クライアント）アクセス-
共有サービス（リソースサーバー）、ユーザー名を共有せず、
印刷サービスのパスワード。代わりに、彼女は認証します
写真共有サービスが信頼するサーバーと直接
（承認サーバー）。印刷サービスの委任固有の資格情報（アクセストークン）を発行します。
初心者向けOAuthガイド では、これについてもう少し詳しく説明しています。
認証サーバーがハッキングされた場合はどうなりますか？
それは悪いことですが、リソースサーバーがハッキングされている可能性はほとんどありません。
実際、認証サーバーはリソースサーバーよりも複雑ではないため、一般的なWebの脆弱性へのオープン性が非常に低いため（データベースクエリが非常に限定的であるため、SQLインジェクションの可能性はほとんどないため、ユーザーがいないか、ほとんどないため） XSSの危険性が少ない、ファイルのアップロードがない、おそらくLFI/RFIの危険性がないなど）。もちろんまだあります 問題 。
したがって、OAuthの2番目の利点は、比較的扱いやすい機密データと、取り扱いが非常に複雑で保護が不十分な機密データから分離されることです。
このアーキテクチャを使用して、すべての卵を1つのバスケットに入れていませんか？
あなたも前にそうしていました。これで、少なくとも2つのバスケットがあります。
また、プロトコルでは、すべてのアプリケーションサーバーに対して認証サーバーを1つだけにする必要があるとは考えられていません。したがって、以前に複数の個別のアプリケーションサーバーがあった場合は、それぞれに認証サーバーを用意できます（コストがセキュリティ上のメリットに値する場合）。
いいえ、これはすべての卵を同じバスケットに入れるのではなく、一部の卵をセキュリティバスケットから取り出してリソースバスケットに入れます。より一般的なセキュリティ用語を使用すると、「攻撃対象を減らす」ことになります。
考えているのは、実行しているすべてのコードに潜在的な脆弱性があるということです。 （明らかに、完全なコードのみをデプロイしたいのですが、Webはその楽観主義の犠牲者でいっぱいです。）そこで、コードにいくつかの脆弱性がある場合に備えて、損傷の分離を検討します。
すべてのサーバーが同等であるとは限らないことを理解することが重要です。違反すると、一部のサーバーは他のサーバーよりも組織にリスクをもたらします。
攻撃者がリソースコンピュータに違反した場合、何が損害を受ける可能性がありますか？まあ、彼らはあなたのリソースにアクセスできます。彼らはあなたのネットワークで足掛かりを得ることができるかもしれませんが、それは脆弱性、あなたのサーバーがどのように構成されるか、彼が何を見つけるか等に依存します。
攻撃者が認証サーバーに違反すると、彼はすべての資格情報を取得し、正当なユーザーになりすますことでシステムのあらゆる側面をより簡単に違反できます。これにより、彼は環境内の他のサーバーに違反したり、注文を盗んだり、クライアントからの支払いを傍受するようにシステムを再構成したりすることができます。
認証サーバーへの違反は組織に全体的な損害を与える可能性があることを考えると、潜在的な脆弱性を減らすために、サーバーで実行するコードの量を最小限に抑えることが望まれます。別のサーバーでリソースをホストすることは、その重要なサーバーの攻撃面を減らす簡単な方法です。