現在、クライアント側の C# アプリケーションで OAuth 2.0 User-Agent Flow を使用しようとしていますが、リダイレクト URI に関連する混乱に直面しています。
クライアント側のアプリケーションを使用しているため、標準のリダイレクト URL を Web サーバーに提供できません。ただし、私が認証しようとしている人 (この例では Salesforce) によると、クライアント側のアプリケーションに使用するのは User-Agent Flow が正しいとのことです。
私の質問は、この状況でアクセストークンをキャッチするにはどうすればよいですか? どうやら「クライアントがアクセスできるローカル リソース」を作成できるようですが、この背後にある仕組みに慣れておらず、トピックに関するリソースが見つかりません (何を探すべきかわからないため)。
どこから探し始めるべきかについての指針は大歓迎です。
編集:さらに掘り下げると、次のstackoverflowの質問が明らかになりました:
OAuth に対してローカルで開発するにはどうすればよいですか?
私は彼らが提案したことをさらに調査していますが、他の提案も同様に素晴らしいでしょう.
編集:さらに検索すると、この記事が明らかになりました:
http://sarangasl.blogspot.com/2010/09/create-simple-web-service-in-visual.html
全体像を理解せずに暗闇の中でぶらぶらしているように感じますが、localhost を使用してローカル Web サービスをセットアップし、リダイレクト URI をそこに向ける必要があると思います。次に、Web サービスを使用して OAuth サーバーからの応答をアンラップし、アプリケーションが適切に応答するようにします。今後もアップデートが予定されています。
オーケー。そのため、収集できたものから、OAuth のコールバックとして提供するローカル Web サービスをセットアップする必要があります。上記のWebサービスを自分でリッスンし、コールバックをキャッチしてアプリに渡す必要があります。ただし、VS2010 が提供する既定の ASP.NET Web サービスは URL パラメーターをサポートせず、API 呼び出しのみをサポートしているため、代わりに WCF Rest スターター キットを使用する必要があるようです。
私はこのすべてに完全に慣れていないので、この時点でのヒントは天の恵みです. 一般的には、ローカルの WCF Rest サービスをセットアップし、そのローカル URI をコールバックとして OAuth に提供し、Rest サービスを使用してコールバック URL をキャッチすることを考えています。次に、URL を解析してアクセス トークンを抽出します。この時点で、私のアプリはアクセス トークンを要求しますか? それとも、私の Web サービスは私のアプリにトークンを「与える」ことができますか? つまり、制御の軌跡はどこにあるべきか?