OAuthコンシューマシークレットを安全に保つ方法、および侵害された場合の対応方法
この質問は、Androidのようなモバイルプラットフォームにoauthを実装することに伴うセキュリティリスクを理解しようとすることに関するものです。ここでは、Androidコードに埋め込まれたコンシューマキー/シークレット。
消費者の秘密が侵害され、ハッカーがそれを手に入れていると仮定すると、これの結果は何ですか？
妥協された消費者秘密の仮定
侵害されたコンシューマシークレット自体がユーザーのセキュリティ、またはユーザーが操作していたOAuthが有効なプロバイダーに保存されているデータ）に影響を及ぼさないことを私は正しく述べていますか。データ自体は危険にさらされておらず、ハッカーが取得することはできません。
ハッカーは有効なユーザーアクセストークンを取得する必要がありますが、その取得は非常に困難です。
ハッカーが侵害された消費者秘密で何ができるのか？
私はまた、次のように述べることで正しいですか？
- ハッカーは、私のアプリを模倣したアプリケーションをセットアップ/公開できます。
- ハッカーは、OAuthフローを通過するユーザーを引き付けることができ、ハッカーを介してアクセストークンを取得しますOAuthダンス（侵害されたコンシューマキー/シークレットを使用））。
- 承認プロセス中におなじみの名前（コンシューマキー）が表示されるため、ユーザーは私のアプリを扱っていると思うかもしれません。
- コンシューマーがハッカーを介してリクエストを発行すると、ハッカーはアクセストークンを簡単に傍受でき、コンシューマーシークレットと組み合わせて、自分に代わってリクエストに署名し、リソースにアクセスできます。
エンドユーザーへの影響
という前提で
- ハッカーがコンシューマシークレットを使用してアプリケーション/サイトを設定した
- ユーザーの1人がそのアプリケーション/サイトへのアクセスを許可するように騙されました
以下が発生する可能性があります。
- エンドユーザーは、怪しいことが起こっていることに気づき、悪意のあるアプリについてサービスプロバイダー（Googleなど）に通知する可能性があります。
- サービスプロバイダーは、コンシューマキー/シークレットを取り消すことができます
OAuthコンシューマー（アプリケーション）への影響：
私のアプリ（コンシューマーシークレットを含む）を更新する必要があります。そうしないと、すべてのクライアントが自分の代わりにアプリケーションがリクエストに対して行うことを承認できなくなります（私のコンシューマーシークレットは無効になるため）。 。
すべて委任OAuthトラフィック
ただし、OAuthインタラクションを中間ウェブサーバー経由で委任することは可能です（OAuthダンスを行い、アクセストークンを送信する各リクエストに署名するためにコンシューマキー/シークレットが必要であるため、すべてのサービスインタラクションもプロキシする必要があります。これは、モバイルアプリの外部でコンシューマキー/シークレットを保持し、中間ウェブサーバー上のより安全な場所ですか？
代替
このプロキシの代替手段はありますか？中間のWebサーバーにコンシューマシークレットを保存し、Androidアプリケーション（市場で公開され、適切に署名されている））が中間に安全な要求を行うことができるようなメカニズムがあるかコンシューマシークレットを取得してアプリの内部に保存するウェブサーバー？中間のウェブサーバーがこれが公式であることを「認識」するメカニズムを実装できますAndroidアプリがコンシューマシークレットの取得をリクエストしている、そして中間ウェブサーバーはその特定のAndroid app？
概要：リスクを冒して、クライアントアプリに秘密を保持します。
プロキシサーバーの代替：
以下にリストする問題を合理的に軽減してプロキシを機能させる唯一の方法は、9ヤード全体を移動することです-サードパーティのWebサービスのリソースを処理するためのすべてのビジネスロジックをプロキシサーバーに移動します。リッチなUIを備えたクライアントアプリのダム端末を作成します。このように、悪意のあるアプリがプロキシに代わって実行できるアクションは、ビジネスロジックが合法的に必要とするものだけです。
しかし、今では、信頼性とスケーラビリティを処理する必要がある他の多くの問題の領域に入ります。
単純なプロキシが機能しない理由についての長い議論：
一部の人々は、問題に直面したとき、「わかっています。自分のプロキシサーバーを追加します」と思います。今、彼らには2つの問題があります。 （ジェイミー・ザウィンスキーへの謝罪）
あなたの仮定はほとんど正しいです。自分のサーバーについて考え始めるところまで、それは秘密を守り、クライアントアプリの呼び出しをプロキシするか、それともアプリが正当であるかどうかを判断して秘密を与えようとするかです。どちらのアプローチでも、「このリクエストは私が書いたコードからのものか」という問題を解決する必要がありますか？
繰り返しましょう-特定のソフトウェアが実行されていることをネットワーク上で区別する方法はありません。メッセージ内のデータが正しいように見える場合、そのメッセージを送信している別のアプリであることを証明できるものはありません。
結局のところ、悪意のあるアプリを作成している場合、それを知っている人に代わって動作させることができる限り、実際の秘密を実際に知っていてもかまいません。悪意のあるアプリがサードパーティのアプリになりすましている可能性があると思われる場合は、OAuthサーバーにアプリを偽装できないのはなぜですか？
しかし、待ってください。まだまだあります。プロキシサービスが配置されているドメインは、クライアントとOAuthプロバイダーの両方に対するIDです（OAuthプロバイダーによってエンドユーザーに示されるように）悪意のあるアプリがサーバーに悪影響を及ぼす可能性がある場合、キーが取り消されるだけでなく、パブリックWeb IDも信頼されなくなります。
私は明白から始めます-特定のソフトウェアが実行されていることをネットワーク上で区別する方法はありません。メッセージ内のデータが正しいように見える場合、そのメッセージを送信している別のアプリであることを証明できるものはありません。
したがって、アプリ側に保存されたシークレットに依存するアルゴリズムは、偽装される可能性があります。 OAuthの強みは、ユーザーの資格情報をアプリに決して提供しないことです。代わりに、アプリが独自の一時的な資格情報を提供し、必要に応じてユーザーが取り消すことができます。
もちろん、ここでの弱点は、十分に優れたアプリは、悪質な行為を終える前に、ユーザーがそれを信頼し、資格情報を取り消すことができないことです。
ただし、これを軽減する方法の1つは、標準の2-leggedではなく3-legged OAuthを使用するGoogleのアプローチです。 3-legged OAuthでは、事前に割り当てられたシークレットはありませんが、すべての認証で、各アクセストークンとともに新しいアクセストークンシークレットが発行されます。最終的にこれには同じ欠点がありますが、悪いアプリはプロセスから良いアプリのトークンシークレットを読み取ることができるため、ユーザーは新しいアクセストークンが必要になるたびにアプリアクセスを承認する必要があります。
そしてもちろん、これはユーザーにとって少し不便で面倒なことでもあります。