モバイルアプリのOAuthシークレット

OAuthプロトコルを使用する場合は、委任先のサービスから取得した秘密の文字列が必要です。これをWebアプリで実行している場合、シークレットをデータベースまたはファイルシステムに格納できますが、モバイルアプリ（またはその点ではデスクトップアプリ）でシークレットを処理するための最良の方法は何ですか？

文字列をアプリに保存することは、誰かが簡単に見つけて悪用する可能性があるため、明らかに良いことではありません。

別のアプローチは、それをサーバーに保存し、アプリを実行するたびにフェッチし、電話に保存しないことです。アプリにURLを含める必要があるため、これはほぼ同じです。

私が思いつくことができる唯一の実行可能な解決策は、最初に通常どおりにアクセストークンを取得し（できればアプリ内のWebビューを使用して）、次にすべての通信をサーバー経由でルーティングすることです。これにより、要求データにシークレットが追加されて通信しますプロバイダーと。繰り返しになりますが、私はセキュリティの初心者なので、これについて知識のある人々の意見を本当に聞きたいです。ほとんどのアプリは、セキュリティを保証するためにこれらの長さにしようとしているようには見えません（たとえば、Facebook Connectは、アプリ内の文字列にシークレットを挿入すると想定しているようです）。

もう1つ、秘密が最初にアクセストークンを要求することに関係しているとは思わないので、それは私たち自身のサーバーを関与させることなく実行できます。私は正しいですか？

はい、これは私たちが直面しているOAuth設計の問題です。私たちはすべての呼び出しを自分のサーバー経由でプロキシすることを選択しました。デスクトップアプリに関しては、OAuthが完全に洗い流されたわけではありません。OAuthを変更せずに私が見つけた問題に対する完全な解決策はありません。

あなたがそれについて考えて、なぜ私たちに秘密があるのか​​と質問した場合、それは主にアプリのプロビジョニングと無効化のためです。私たちの秘密が侵害された場合、プロバイダーは本当にアプリ全体を取り消すことができるだけです。私たちは秘密をデスクトップアプリに埋め込む必要があるため、ややこしいです。

解決策は、デスクトップアプリごとに異なる秘密を持つことです。OAuthはこの概念を容易にしません。1つの方法は、ユーザーが自分でシークレットを作成し、自分でキーをデスクトップアプリに入力することです（一部のFacebookアプリは、長い間似たようなことを行っており、ユーザーはFacebookを作成してカスタムクイズをセットアップし、くだらない）。これはユーザーにとって素晴らしい体験ではありません。

OAuthの委任システムの提案に取り組んでいます。コンセプトは、プロバイダーから取得した独自の秘密鍵を使用して、独自の委任された秘密を自分のデスクトップクライアント（基本的にデスクトップアプリごとに1つ）に発行し、認証プロセス中にその鍵をトップレベルに送信することです。私たちにコールバックし、私たちと一緒に再検証するプロバイダー。そうすることで、各デスクトップクライアントに発行する独自の秘密を取り消すことができます。（SSLからこれがどのように機能するかを多く借りる）。このシステム全体は、サードパーティのWebサービスへの呼び出しを渡す付加価値Webサービスに最適です。

最上位のプロバイダーが新しい委任されたシークレットを生成して取り消すためのAPIを提供する場合、委任検証コールバックなしでプロセスを実行することもできます。Facebookは、ユーザーがサブアプリを作成できるようにFacebookアプリを許可することで、同様のことをしています。

オンラインで問題についていくつかの話があります：

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

TwitterとYammerのソリューションは認証ピンソリューションです：https : //dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

OAUth 2.0では、シークレットをサーバーに保存できます。サーバーを使用して、アプリに移動するアクセストークンを取得します。アプリからリソースに直接呼び出しを行うことができます。

OAuth 1.0（Twitter）では、API呼び出しを行うためにシークレットが必要です。シークレットが侵害されないようにするための唯一の方法は、サーバーを介した呼び出しのプロキシです。

どちらも、サーバーコンポーネントがそれを呼び出すクライアントであることをサーバーコンポーネントが認識している何らかのメカニズムを必要とします。これは、インストール時に行われ、プラットフォーム固有のメカニズムを使用してサーバーへの呼び出しで何らかのアプリIDを取得する傾向があります。

（私はOAuth 2.0仕様の編集者です）

1つの解決策は、OAuthシークレットをコードにハードコーディングすることですが、プレーンな文字列としてはできません。何らかの方法で難読化します-セグメントに分割し、オフセットによって文字をシフトし、回転します-これらのいずれかまたはすべてを実行します。クラッカーはバイトコードを分析して文字列を見つけることができますが、難読化コードは理解しにくい場合があります。

これは間違いのないソリューションではありませんが、安価なソリューションです。

エクスプロイトの価値に応じて、一部の天才クラッカーは、あなたの秘密のコードを見つけるためにより長い時間を費やすことができます。前述のサーバー側ソリューションのコスト、クラッカーがシークレットコードを見つけるためにより多くの労力を費やすインセンティブ、実装できる難読化の複雑さなどの要因を比較検討する必要があります。

シークレットをアプリケーション内に保存しないでください。

https（明らかに）を介してアプリケーションからアクセスできるサーバーが必要で、そのサーバーにシークレットを保存します。

誰かがモバイル/デスクトップアプリケーションを介してログインする場合、アプリケーションはリクエストをサーバーに転送し、サーバーはシークレットを追加してサービスプロバイダーに送信します。サーバーはアプリケーションが成功したかどうかをアプリケーションに通知できます。

次に、サービス（facebook、google、twitterなど）から機密情報を取得する必要がある場合、アプリケーションはサーバーに問い合わせ、サーバーが正しく接続されている場合にのみ、アプリケーションに情報を提供します。

サーバーに保存する以外にオプションはありません。クライアント側では何も安全ではありません。

注意

つまり、これは悪意のあるクライアントから保護するだけで、悪意のあるクライアントからは保護せず、他の悪意のあるクライアントからは保護しません（フィッシング）...

OAuthは、デスクトップ/モバイルよりもブラウザの方がはるかに優れたプロトコルです。

Authorization Code Grant Typeには、Proof Key for Code Exchange（PKCE）と呼ばれる新しい拡張機能があります。それを使用すると、クライアントシークレットは必要ありません。

PKCE（RFC 7636）は、クライアントシークレットを使用しないパブリッククライアントを保護する手法です。

主にネイティブアプリやモバイルアプリで使用されますが、この手法はどのパブリッククライアントにも適用できます。承認サーバーによる追加のサポートが必要なため、特定のプロバイダーでのみサポートされます。

https://oauth.net/2/pkce/から

詳細については、完全なRFC 7636またはこの短い紹介をご覧ください。

ここで考えるべきことがあります。GoogleはOAuthの2つの方法を提供しています...ドメインを登録して一意のキーを生成するWebアプリと、キー「anonymous」を使用するインストール済みアプリです。

多分私は読んで何かに目を通しました、しかしインストールされたアプリとあなたのウェブアプリのユニークなキーを共有することはおそらく公式のインストールされたアプリの方法で「匿名」を使用するよりも安全であるようです。

OAuth 2.0では、クライアント側のフローを使用してアクセストークンを取得し、このアクセストークンを使用して以降のすべてのリクエストを認証できます。その後、あなたはまったく秘密を必要としません。

これを実装する方法の良い説明はここにあります：https : //aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

OAuthの使用経験はあまりありませんが、すべてのリクエストでユーザーのアクセストークンだけでなく、アプリケーションのコンシューマーキーとシークレットも必要になるとは限りません。そのため、誰かがモバイルデバイスを盗んでデータを取得しようとした場合でも、実際に何かを実行するには、アプリケーションキーとシークレットも必要になります。

OAuthの背後にある意図は、マッシュアップを持ったすべてのトム、ディック、およびハリーがTwitterの資格情報を平文で保存する必要がないようにするためだといつも思っていました。制限にもかかわらず、それはその問題をかなりうまく解決すると思います。また、iPhoneを念頭に置いて実際に設計されたわけでもありません。

私はFelixyzに同意します。OAuthは基本認証よりも優れていますが、モバイルアプリの優れたソリューションになるまでにはまだ長い道のりがあります。私は、OAuthを使用して携帯電話アプリをGoogle App Engineアプリに対して認証することに取り組んできました。モバイルデバイスでコンシューマシークレットを確実に管理できないという事実は、デフォルトでは「匿名」アクセスを使用することを意味します。

Google App Engine OAuth実装のブラウザ認証ステップにより、「サイト<some-site>は以下にリストされている製品のGoogleアカウントへのアクセスを要求しています」のようなテキストを含むページに移動します。

YourApp（yourapp.appspot.com）-Googleと提携していません

等

カスタムスキームを使用してコールバックをインターセプトする場合、指定するコールバックURLで使用されるドメイン/ホスト名から<some-site>を取得します。したがって、「匿名」アクセスを使用する場合、またはコンシューマーシークレットが危険にさらされる場合、誰もがユーザーをだましてGAEアプリへのアクセスを許可するコンシューマーを作成する可能性があります。

Google OAuth認証ページには、「匿名」、コンシューマシークレット、公開鍵のいずれを使用しているかに応じて、3つのレベルの重大度の警告も多数含まれています。

技術に精通していない平均的なユーザーにとってはかなり怖いものです。そのようなことで、サインアップ完了率が高くなるとは思いません。

このブログ投稿では、コンシューマシークレットがインストール済みアプリで実際に機能しない方法を明らかにしています。 http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

また、モバイルOAuth認証のソリューションを考え出して、一般的にアプリケーションバンドル内にシークレットを保存しようとしています。

そして、クレイジーなアイデアが思いついたのです。最も単純なアイデアは、シークレットをバイナリ内に格納することですが、何らかの方法で難読化する、つまり、暗号化されたシークレットを格納します。つまり、秘密を解読するための鍵を保存する必要があるということです。ただし、OSにすでにあるキーを使用しないでください。つまり、アプリケーションではなくOSによって定義されています。

つまり、私の考えを明確にするために、OSで定義された文字列を選択するということですが、どちらを選択してもかまいません。次に、この文字列をキーとして使用してシークレットを暗号化し、それをアプリに保存します。次に、実行時に、キーを使用して変数を復号化します。これは単なるOS定数です。バイナリを覗き見しているハッカーは、暗号化された文字列を見ることができますが、キーは見えません。

うまくいきますか？

ここに私はあなたのoAuth情報をモバイルアプリケーションに保存する安全な方法に答えています

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebookは厳密には（まだ）OAuthを実装していませんが、iPhoneアプリに秘密を埋め込まない方法を実装しています：https : //web.archive.org/web/20091223092924/http : //wiki。 developers.facebook.com/index.php/Session_Proxy

OAuthに関しては、ええ、私はそれについてもっと考えるほど、私たちは少し詰まっています。多分これはそれを修正します。

これらのソリューションはどれも、モバイルデバイス（またはエミュレータ）から送信されたパケットを特定のハッカーが盗聴して、httpヘッダーのクライアントシークレットを表示することを防ぎます。

1つの解決策は、プライベート2ウェイ暗号化キーとアルゴリズムで暗号化されたタイムスタンプで構成される動的シークレットを持つことです。次に、サービスは秘密を復号化し、タイムスタンプが+/- 5分かどうかを判断します。

このようにして、シークレットが侵害されたとしても、ハッカーは最大5分間しかシークレットを使用できません。

他の人が述べたように、デバイスにローカルにシークレットを保存することには実際の問題はないはずです。

その上、いつでもAndroidのUNIXベースのセキュリティモデルに依存できます。ファイルシステムに書き込んだものにアクセスできるのはアプリケーションだけです。アプリのデフォルトのSharedPreferencesオブジェクトに情報を書き込むだけです。

シークレットを取得するには、Androidフォンへのルートアクセスを取得する必要があります。