[解決済み] OAuth 2.0におけるクライアントシークレット

質問

google drive apiを使用するために、OAuth2.0を使用した認証を行う必要があります。また、これに関していくつか質問があります。

1. Client id と client secret は、私のアプリが何であるかを識別するために使用されます。しかし、クライアント アプリケーションである場合、これらはハードコードされていなければなりません。そのため、誰でも私のアプリを逆コンパイルして、ソースコードからそれらを抽出することができます。 悪いアプリが、良いアプリのクライアントIDとシークレットを使って、良いアプリのふりをすることができるということでしょうか？ つまり、悪いアプリに許可を求められても、良いアプリに許可を求める画面が表示されるのでしょうか？もしそうなら、私は何をすべきですか？ または、実際にはこのことについて心配する必要はないのでしょうか？

2. モバイルアプリケーションでは、アプリにWebビューを埋め込むことができます。そして、許可を求めるアプリは実際にはブラウザであるため、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 . 全体として、サードパーティライブラリの使用には特に注意が必要です（実際には常識ですが、トークンのハイジャックが大きな懸念事項である場合は、さらにもう1つ注意が必要です）。

2. 私はかなり長い間、ポイント2についてわめき散らしてきました。私は、同意ページを修正するために、アプリでいくつかの回避策を実行しましたが (たとえば、アプリに合わせてズームやデザインを変更する)、ユーザー名とパスワードで Web ビュー内のフィールドから値を読み取ることを止めるものは何もありませんでした。したがって、私はあなたの2番目のポイントに完全に同意し、OAuth仕様の大きなバグであることを発見しました。つまり、OAuth仕様にある「アプリがユーザの認証情報にアクセスできない」というのは夢物語であり、ユーザに誤った安心感を与えてしまうということです...また、アプリがFacebookやTwitter、Dropboxなどの認証情報を聞いてきたら、普通は怪しむと思います。OAuthの仕様書を読んで「これで安心」と言う人はあまりいないと思いますが、常識的に考えて、信用できないアプリは使わないのが一般的でしょう。