OAuth v1コンシューマキーとオープンソースデスクトップTwitterクライアントのシークレットをユーザーに公開せずに保存するにはどうすればよいですか？
シッククライアント、デスクトップ、オープンソースのTwitterクライアントを作成したいと考えています。言語として.NETを使用し、OAuth/Twitterラッパーとして Twitterizer を使用しているため、アプリがオープンソースとしてリリースされる可能性があります。
OAuthトークンを取得するには、4つの情報が必要です。
- アクセストークン（Twitterユーザー名）
- アクセスシークレット（Twitterパスワード）
- 消費者キー
- 消費者秘密
2番目の2つの情報は、PGP秘密鍵のように共有されません。ただし、OAuth承認フローの設計方法により、これらはネイティブアプリ上にある必要があります。アプリケーションがオープンソースでなく、コンシューマキー/シークレットが暗号化されている場合でも、適度に熟練したユーザーは、コンシューマキー/シークレットのペアにアクセスできます。
だから私の質問は、この問題をどうやって回避するのですか？デスクトップのTwitterクライアントがコンシューマキーとシークレットを保護するための適切な戦略は何ですか？
hueniverse に行くことを検討していたパスを反映する答えを見つけました。記事 Beyond the OAuth Web Redirection Flow ）はいくつかの提案を提供しており、そのうちの1つはトークン交換プロセスをプロキシするWeb URLです。私は解決する必要があります私のアプリがこのプロキシページへの認証を要求しているものであることを正しく認証する方法ですが、それは可能です。
私は間違っているかもしれませんが、デスクトップまたはモバイルアプリにキーをバンドルしている場合、オープンソースであるかどうかに関係なく、それらにアクセスすることは可能です。 TwitterやTumblrなどのサービスでOAuthのみのAPIを使用する必要がある場合、2つのオプションがあります。
- すべてのアプリに認証プロキシサービスを設定する
- アプリにキーをバンドルする
前者はより難しく、コストがかかり、小規模でオープンソースのアプリでは必ずしも保守可能ではありません。後者は、スパマーがキーを盗むと、アプリがブロックされる可能性があることを意味します。 TwitterとTumblrはまだより良いオプションを提供しておらず、すべてのデスクトップクライアント（オープンソースクライアントを含む）を台無しにしているため、 「Big Fish」キーを配布し、それらをフォールバックとして使用する の提案があります。
最後に、everyユーザーにAPIキーの取得を強制するオプションがあります。
RFC 5849のセクション4.6 （OAuth 1を定義）は、Twitterが実際に使用されているにもかかわらず、コンシューマシークレットがデスクトップコンシューマによる使用を意図していないことを示しています。 Nelson Elhageが " Dear Twitter "で指摘したように、クライアントが失敗するほど大きくなければ、Twitterはデスクトップクライアントのコンシューマキーを終了できます。ただし、デスクトップまたはモバイルアプリケーションでOAuth 1を使用できるようにするには、2つの回避策があります。
1つの方法は、操作するサーバーを介してTwitterプロトコル全体をプロキシすることです。このようにして、コンシューマシークレットはサーバーに残ります。これはOAuth 1仕様の編集者である Dick Hardtが推奨する回避策 です。この回避策は、このサーバーの運用コストには対応していません。
Raffi Krikorianによる投稿 でTwitter開発トークのGoogleグループに、そして Chris Steippによる投稿 でウィキペディアのメーリングリストに提案されているように、「それぞれにユーザーはデスクトップアプリケーションのコピーを独自のコンシューマーとして登録します。」次に、ユーザーは新しく登録されたコンシューマキーとコンシューマシークレットをコピーしてアプリケーションに貼り付けます。アプリケーションのマニュアルには、Twitterの開発者サイトに新しいアプリケーションを登録する方法の詳細な手順を含める必要があります。この公式の制限には、いくつかの実用的な問題があります。
- クライアントは、有名なプロプライエタリクライアントと比較して、使いやすさに不利になります。
- 新しいアプリを作成するためのフォーム は、必須フィールドに事前入力する方法を提供していないようです。これは、Twitterがアプリの登録手順を変更するたびに、マニュアルの登録ウォークスルーを更新する必要があることを意味します。
- 開発者契約では、ユーザーは法的拘束力のある契約を結ぶ年齢に達している必要があります。つまり、13歳から17歳のアプリケーションのユーザーは、ユーザーに代わって同意書に同意する必要があります。
- Twitterの 開発者ポリシー は、アプリケーションの大量登録と、「同じ機能を持つ複数のアプリケーションを異なる名前で送信する」と定義されている「名前の不法占拠」を禁止しています。 Twitterが1つのアプリケーションの個別のコピーを登録した無関係のユーザーを「名前不法占拠者」として扱ったかどうかについては、前例はありません。