OAuth 2.0のクライアントシークレット

GoogleドライブAPIを使用するには、OAuth2.0を使用した認証を試す必要があります。そして私はこれについていくつか質問をしました。

1. クライアントIDとクライアントシークレットを使用して、アプリを特定します。ただし、クライアントアプリケーションの場合は、ハードコーディングする必要があります。したがって、誰でも私のアプリを逆コンパイルして、ソースコードから抽出できます。良いアプリのクライアントIDとシークレットを使用することで、悪いアプリが良いアプリのふりをすることができるということですか？それで、ユーザーは実際に悪いアプリから要求されたとしても、良いアプリに許可を与えることを求める画面を表示するでしょうか？はいの場合、どうすればよいですか？それとも私はこれについて心配する必要はありませんか？

2. モバイルアプリケーションでは、アプリにウェブビューを埋め込むことができます。そして、許可を求めるアプリは実際には「ブラウザ」なので、webviewのパスワードフィールドを簡単に抽出できます。では、モバイルアプリケーションのOAuthには、クライアントアプリケーションがサービスプロバイダーのユーザー資格情報にアクセスできないという利点がないのでしょうか。

私はあなたの質問にコメントを書き始めましたが、言うには多すぎることがわかったので、答えの主題に関する私の見解を以下に示します。

1. はい、これには本当の可能性があり、これに基づくエクスプロイトがいくつかありました。アプリでアプリを秘密にしないことをお勧めします。仕様には、配布されたアプリがこのトークンを使用してはならないという部分さえあります。さて、あなたは尋ねるかもしれませんが、XYZが機能するにはそれが必要です。その場合、彼らは仕様を適切に実装していないので、Aはそのサービスを使用しない（そうでない可能性が高い）か、Bいくつかの難読化メソッドを使用してトークンを保護し、サーバーをプロキシとして見つけたり使用したりすることを困難にする必要があります。

   たとえば、トークンがログにリークされていたAndroidのFacebookライブラリにいくつかのバグがありました。詳細については、http：//attack-secure.com/all-your-facebook-access-tokens-are-belongをご覧 ください。 -to-us およびここhttps://www.youtube.com/watch?v=twyL7Uxe6sk。概して、サードパーティライブラリの使用には特に注意が必要です（実際には常識ですが、トークンのハイジャックが大きな懸念である場合は、さらに注意が必要です）。

2. 私はかなり長い間、ポイント2について怒っていました。私は同意ページを変更するために私のアプリでいくつかの回避策（たとえば、アプリに合わせてズームとデザインを変更する）をしましたが、ユーザー名とパスワードでWebビュー内のフィールドから値を読み取ることを妨げるものは何もありませんでした。したがって、私はあなたの2番目の点に完全に同意し、OAuth仕様に大きな「バグ」があることを発見しました。仕様で「アプリがユーザーの資格情報にアクセスできない」というのは単なる夢であり、ユーザーに誤った安心感を与えます…また、アプリがFacebook、Twitter、Dropboxまたはその他の資格情報を要求する場合、人々は通常疑惑を抱いていると思います。多くの一般の人がOAuth仕様を読んで「今は安全です」と言っているのではないかと思いますが、代わりに常識を使用し、一般に信頼できないアプリを使用しません。

私はここの質問1と同じ質問を持っていて、最近自分自身でいくつかの調査を行いましたが、私の結論は、「クライアントの秘密」を秘密にしないことは大丈夫だということです。クライアントの秘密を守らないタイプのクライアントは、OAuth2仕様では「パブリッククライアント」と呼ばれています。悪意のある誰かが認証コードを取得してからトークンにアクセスできる可能性は、以下の事実によって防止されます。

1.クライアントは、サービスからではなく、ユーザーから直接認証コードを取得する必要があります

ユーザーがクライアントを信頼するサービスをユーザーが指定した場合でも、クライアントIDとクライアントシークレットを表示するだけでは、クライアントはサービスから認証コードを取得できません。代わりに、クライアントはユーザーから直接認証コードを取得する必要があります。（これは通常、後で説明するURLリダイレクションによって行われます。）したがって、悪意のあるクライアントの場合、ユーザーが信頼するクライアントID /シークレットを知るだけでは十分ではありません。何らかの方法でユーザーを関与させるか、ユーザーになりすまして、認証コードを付与する必要があります。これは、クライアントID /シークレットを知るだけでは難しいはずです。

2.リダイレクトURLがクライアントID /シークレットに登録されている

悪意のあるクライアントがなんとかしてユーザーを巻き込み、サービスページの[このアプリを承認]ボタンをクリックするようにしたとします。これにより、認証コードとともにサービスからユーザーのブラウザーへのURLリダイレクト応答がトリガーされます。次に、認証コードがユーザーのブラウザからリダイレクトURLに送信され、クライアントはリダイレクトURLでリッスンして認証コードを受信することになっています。（リダイレクトURLもlocalhostにすることができます。これが「パブリッククライアント」が認証コードを受信する一般的な方法であることがわかりました。）このリダイレクトURLはクライアントID /シークレットを使用してサービスに登録されるため、悪意のあるクライアントは認証コードが与えられる場所を制御する方法があります。

2番目の質問への回答：セキュリティ上の理由から、Google APIは認証/サインインをアプリ内で行うことはできず（Webビューは許可されないなど）、セキュリティを強化するためにブラウザーを使用してアプリの外部で行う必要があり ます。 //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html