単一のアプリケーション用の複数のコンシューマーキーを持つOAuthプロバイダー

Question

OAuthを使用するappengineアプリで作業しています。当然ながら、私は同時に複数のバージョンのアプリケーションを扱っています - 開発のためのローカルバージョン、ステージングバージョン、およびデプロイメントバージョンです。これらと連携する

認証のコールバックは、プロバイダのサイト上で定義された通り、私はOAuthの消費者の鍵/秘密の3つの別々のセットが必要です。

プロバイダーが特定のアプリケーションのための複数の鍵/秘密を提供するための方法がある場合、私は思っていた - これは、毎回新しいアプリを設定するよりも多くの意味をなすように思われます。 （もちろん、プロバイダにはこれを実装する必要がありますが、実装するのは当然のようですが、私はそれを見ていません）。

は、より一般的には、標準どのようなアプローチはこれに対処するために使用されている - 私の推測では、複数のアプリを登録し、それが開発モード、ステージングまたは展開中かどうかを決定するために、アプリケーションのロジックを持っています。どんな考えも大歓迎です。

Answer 1

これは、OAuth APIクライアント開発者にとって最も迷惑な部分の1つであることがわかりました。プロバイダが開発者にテスト用のリダイレクト（コールバック）URIを登録させないようにする理由はありません。

私が見てきた標準的なアプローチは、あなたがコールバック/リダイレクションのために1つまたは複数のドメインをホワイトリストに登録することができるようにすることです。 Facebookには、アプリケーションプロファイルのさまざまなリンクに異なるドメインを使用することによって、複数のドメインを「登録」できるいくつかの狂った設定があります。私はそれにあまり運がなかった。 Twitterはそのための優れた実装の1つであり、複数のドメインを登録することができます。

OAuth 2.0（ドラフト18以降）では、このトピックでははるかに優れた治療法が得られます。要求時に複数のコールバックを登録し、動的に必要なコールバックを選択することができる完全なURIの登録が推奨されます。

考慮すべき主な側面は、ステージングセットアップでアクセス許可を処理する方法です。既存の承認を再利用できるようにしたいのですか、それとも別の承認を保持したいのですか？また、APIがクライアントストレージや管理ツールなどの特別なクライアント専用呼び出しを提供している場合は、ステージバージョンで共有したり、独自のものを保持したりします（テストによって生産が乱されることはありません）。

終わりには、プロバイダは、完全な開発環境を提供する必要があり、それがAPIクライアント用の試験設備を含んでいます。ほとんどはしません。

Answer 2

APIプロバイダの観点からは、アプリは単にAPIを使用するアプリです。通常、生の制作データを扱わない「ステージング」APIはありません。テストしているものは何でも、実際のデータでテストしていますか？

あなたは、例えば、異なるコールバックを持つ複数の異なるアプリケーションを登録することができるならば、私はあなたの問題はかなり解決だと思います。私の見解では、これらのことを分けておくことは消費者の責任でなければならないということです。