IDプロバイダーは偽装できますか？ （FacebookはStack Overflowの質問を私の名前で投稿できますか？）

Question

サービスB（アイデンティティプロバイダー/ IdP）によって付与されたトークンを使用してサービスA（証明書利用者/ RP）にアクセスできるようにする複数のメカニズム（現在は機能しなくなったもの）があります。通常、これらはユーザー名とパスワードのログインを置き換えます。 IdPプロトコルの例は次のとおりです。

• OpenID 2.0
• OpenID Connect
• IndieAuth
• Mozillaペルソナ
• ポーティエ
• ...そして明らかにGoogleサインインとFacebookログイン

IdPがRPのアカウントにアクセスできないのはなぜですか。確かに、IdPでsysadmin特権を持つ悪質なアクターは次のことができます。

1. サービスAでログインを試みます。
2. ... AからBへのトークンリクエストの開始
3. サービスBでトークンを生成する（資格情報は必要ありません）
4. ...有効な応答をAに返す
5. 今すぐAで私のアカウントにアクセスします

私は一般的な質問をしていますが、具体的な例として、悪意のあるFacebook管理者が私の名前でStack Exchangeの質問を投稿しないようにするにはどうすればよいですか？

大まかなスケッチ：

（スケッチは https://developers.google.com/identity/protocols/OAuth2 から変更されましたが、参照されているプロトコルはの例にすぎないことに注意してください。）

Answer 1

はい、できます。

簡単な答え：通常、ユーザー名とパスワードを使用して、IDプロバイダーに対して何らかの方法で認証します。悪い管理者は、送信された資格情報を保存して、それらを再利用することができます。この攻撃は、バックエンドの実装方法には依存しません。

一般に、IDプロバイダーのパスワードは、サードパーティのサービスへの認証にはまったく使用されません。つまり、IDプロバイダーは実際にログインキーを持っています（そして、まったく持っていません）。

パスワードを暗号化せずに保存せずにパスワードを認証プロセスに組み込むスキームを考えることができますが、実際にはそのようなスキームは知りません。

Answer 2

TL; DR：Facebookログインを偽装できる悪質なFacebook管理者は、悪質なものをあなたの名前でFacebookに投稿することができ、通常は投稿よりも悪いと考えられていますStack Exchangeに関する質問。

私の詳細回答は OAuth 2. に焦点を当てています-=これはこのユースケースの業界標準であり、Googleの承認スケッチの背後にありますOPで¹。

OAuth 2.0フレームワークは本来、認証のみを目的としたものではなく、より一般的な承認のユースケースを対象としています。サービスAは、サービスBのユーザーが所有するリソースにアクセスしたいと考えています。

たとえば、ユーザーはサービスA（写真編集アプリ）とサービスB（Googleドライブ）の両方のアカウントを持っています。 OAuth 2.0の場合、ユーザーはアプリにGoole Driveの写真にアクセスする権限を付与します。いくつかの注意点：

• サービスAはサービスBの登録済みアプリである必要があります。例では、開発者は写真編集アプリを Google Developer に登録する必要がありました。承認フローを開始すると、サービスAは、クライアントIDとクライアントシークレット（サーバー側のフローの場合）またはクライアントIDとホスト名（クライアント側のフローの場合）を介して、サービスBに対して自身を識別します。
• サービスAはユーザーをサービスBの承認エンドポイントにリダイレクトし、ユーザーはサービスBでのみサービスBの認証情報を入力する必要があります。サービスAはサービスBのログインを偽装できません。承認エンドポイントを制御しません。ユーザーが提供していないため、サービスBはサービスAのログインを偽装できません。
• サービスAがサービスB上のユーザーのリソースにアクセスするために使用できる最後のトークン応答には、スコープが付属しています。サービスBは、サービスAに承認されたスコープ内のリソースのみへのアクセスを許可します。スコープは、リダイレクト先の認証ウィンドウでユーザーに説明されます。この例では、Googleドライブの認証ウィンドウに「この写真編集アプリはドライブ上の写真を表示および変更できます」のような説明が表示されます。その後、Googleはアプリが写真にアクセスすることを許可しますが、承認された範囲内にないため、Google Plusに何かを投稿することはできません。

サードパーティログインは非常に一般的な特殊なケースで、ユーザーが所有するリソースはサービスBの基本的なアカウント情報です。ユーザーに彼女のサービスに登録すると、開発者はGoogleにユーザーのIDの確認を依頼することを選択しました。

システムが機能するのは、

1. サービスAはサービスBを信頼します
2. ユーザーはサービスBを信頼する

良い点は、ユーザーがサービスAを信頼する必要がないことです。

ただし、ユーザーがサービスAをサービスBよりも信頼している場合、サードパーティのログインを使用してサービスAに登録しないでください（オプションが利用可能な場合）。

^{1 元の投稿}

Answer 3

はい、できます。マリオはそれが技術的にどのように機能するかを説明しました。ここではtrustの部分に焦点を当てます。

あなたがコンピュータ上で行うどんな行動も、信頼を意味します。あなたはあなたのシステムとあなたの電話のOSエディタを信頼しています。インストールしたプログラムのすべてのエディターを信頼します。使用するすべてのオンラインサービスを信頼している。そして、あなたはあなたの銀行があなたの口座で何もしないと信頼します（これは情報学を超えています...）。

しかし、信頼レベルにはある程度のレベルがあります。私は飛行機の予約システムを信頼して何かを購入するのに十分ですが、銀行の信用証明を提供するまでは信頼していません。とにかく、私は自分のパスワードボールトプログラムを十分に信頼しています。

したがって、信頼チェーンで重要なのは次のとおりです。チェーンのアクターの1つは、全体的なアクションよりも低い信頼レベルにしか値しませんか？ SOにFacebookアカウントを使用することはおそらく問題ありません。攻撃のリスクと起こり得る結果は、私がFacebookで持っている信頼と私見で互換性があります。しかし、私は自分の銀行にFacebookアカウントを使用することは決してありません（とにかく提供していません）。そしてもちろん、システムを信頼することは、その管理者のいずれかに対する信頼を意味します。