オープンソースのデスクトップTwitterクライアントのOAuth v1コンシューマキーとシークレットをユーザーに公開せずに保存するにはどうすればよいですか？

シッククライアント、デスクトップ、オープンソースのツイッタークライアントを作りたいです。言語として.NETを使用し、OAuth / TwitterラッパーとしてTwitterizerを使用しているため、アプリがオープンソースとしてリリースされる可能性があります。

OAuthトークンを取得するには、4つの情報が必要です。

1. アクセストークン（twitterユーザー名）
2. アクセスシークレット（twitterパスワード）
3. 消費者キー
4. 消費者の秘密

PGP秘密鍵のように、2番目の2つの情報は共有されません。ただし、OAuth認証フローの設計方法により、これらはネイティブアプリ上に存在する必要があります。アプリケーションがオープンソースではなく、コンシューマキー/シークレットが暗号化されていたとしても、かなり熟練したユーザーはコンシューマキー/シークレットペアにアクセスできます。

だから私の質問は、この問題をどのように回避するのですか？デスクトップTwitterクライアントが消費者の鍵と秘密を保護するための適切な戦略は何ですか？

私は色相を下ろすことを考えていた道を反映した答えを見つけました。記事「OAuth Web Redirection Flowを超えて」にはいくつかの提案があり、その1つはトークン交換プロセスをプロキシするWeb URLです。アプリがこのプロキシページへの認証を要求していることを適切に認証する方法を考え出さなければなりません。しかし、それは可能です。

私は間違っているかもしれませんが、デスクトップまたはモバイルアプリにキーをバンドルすると、オープンソースかどうかに関係なく、それらにアクセスできます。TwitterやTumblrなどのサービスがOAuth専用APIの使用を強制する場合、2つのオプションがあります。

• すべてのアプリに認証プロキシサービスを設定する
• アプリにキーをバンドルする

前者は、より困難で費用がかかりますが、小規模でオープンソースのアプリでは必ずしも維持できません。後者は、スパマーがキーを盗むと、アプリがブロックされる可能性があることを意味します。TwitterとTumblrはまだ良いオプションを提供しておらず、すべてのデスクトップクライアント、オープンソースクライアントを含めて、「Big Fish」キーを配布し、それらをフォールバックとして使用する提案があります。

最後に、すべてのユーザーにAPIキーの取得を強制するオプションがあります。

OAuth 1を定義するRFC 5849のセクション4.6では、Twitterが実際に使用しているにもかかわらず、コンシューマシークレットがデスクトップコンシューマによって使用されることは意図されていないと述べています。Nelson Elhageが「Dear Twitter」で指摘したように、Twitterがデスクトップクライアントのコンシューマキーを終了できるのは、クライアントが失敗するほど大きくない場合です。ただし、デスクトップアプリケーションまたはモバイルアプリケーションでOAuth 1を使用できるようにする2つの回避策があります。

1つの方法は、操作するサーバーを介してTwitterプロトコル全体をプロキシすることです。このように、消費者の秘密はサーバーに残ります。これは、OAuth 1仕様のエディターであるDick Hardtが推奨する回避策です。この回避策は、このサーバーの運用コストに対処するものではありません。

もう1つの方法は、Raffi KrikorianによるTwitter開発トークGoogleグループへの投稿およびChris SteippによるWikipediaメーリングリストへの投稿で示唆されているように、「各ユーザーにデスクトップアプリケーションのコピーを独自のコンシューマーとして登録させる」ことです。次に、ユーザーは新しく登録されたコンシューマキーとコンシューマシークレットをコピーしてアプリケーションに貼り付けます。アプリケーションのマニュアルには、Twitterの開発者サイトで新しいアプリケーションを登録する方法の詳細な手順を含める必要があります。この公式の制限には、いくつかの実際的な問題があります。

• あなたのクライアントは、有名なプロプライエタリなクライアントと比べて使い勝手が悪いという問題に直面します。
• 新しいアプリを作成するためのフォームが必要なフィールドを事前移入する方法を提供するためには表示されません。つまり、Twitterがアプリの登録手順を変更するたびに、マニュアルの登録手順を更新する必要があります。
• 開発者契約では、ユーザーが拘束力のある契約を結ぶには法定年齢である必要があります。つまり、13〜17歳のアプリケーションのユーザーは、ユーザーに代わって親に同意を承諾してもらう必要があります。
• Twitterの開発者ポリシーでは、アプリケーションの一括登録と「名前のしゃがみ」を禁止しています。これは、「異なる名前で同じ機能を持つ複数のアプリケーションを送信する」と定義されています。私は、Twitterが1つのアプリケーションの個別のコピーを「名前不法占拠者」として登録した無関係のユーザーを扱ったかどうかについての先例を知りません。

私は答えますが、私自身はこれに対処していないことに注意してください。ベストプラクティスと既存の関連する経験から脱却します。

私はそれについてあまり心配しません。クライアントがオープンソースである場合、クライアントはソースにアクセスできます。プログラムでクライアントが行うことを制御しようとすると、いずれにしてもオープンソースの性質に反します（重要なことは、あなたがしようとしていることはそうではありません）。

プログラムをデバッグしてキーを抽出するのに十分な知識がある人は、それ以上の方法を知っている可能性が高いため、さらにロックダウンしようとして時間を浪費している可能性があります。

予防措置として、キーを頻繁に変更します（可能な場合）が、できるのがプログラムであるふりをするだけの場合、それはあまり深刻ではないようです。

完全な開示、私はTwitter API、twitterizerのAPI、oauth要件、または私が疑わしいと言った他の何かに精通していません;）

コンシューマキーとシークレットはアプリケーションにバインドされており、ユーザーにバインドされていません。これにより、OAuthプロバイダーは、どのアプリケーションを扱っているかを認識します。最初の手順が完了すると、残り、アクセストークン、シークレットが取得されます。

プロトコルがどのように機能するかを示す詳細については、このブログ投稿を参照してください。