私の理解が正しければ、デスクトップ アプリケーションから API 呼び出しを行うには (OAuth2 標準のように今から「クライアント」で呼び出しましょう)、アプリケーション ID とユーザー ID の両方を組み合わせた識別子である access_token を取得する必要があります。誰のデータにアクセスしたいのか、id (「リソース所有者」)。
認証ガイド ( developers.facebook.com/docs/authentication/ )のクライアント フローに従ってください。 ://example.com&response_type=token. その結果、ページは h**p://example.com/#access_token=XXX にリダイレクトされます。クライアントが純粋なデスクトップ アプリの場合、redirect_uri は h**p://www.facebook.com/connect/login_success.html になります。クライアントは Web コントロールを所有しているため、リダイレクトされたアドレスから access_token を簡単に抽出できます。
クライアント側のフローは、次の 3 つの OAuth ステップで構成されます。
- ユーザー認証。リソース所有者が Facebook にログインしていない場合、Facebook 資格情報を求めるダイアログが表示されます。リソース所有者がログインしている場合、セッションは Facebook のサーバーの Cookie を使用して認証されます。セキュリティ - チェック V !
- アプリの承認。リソース所有者がまだアプリにアクセス許可を与えていない場合、アクセス許可ダイアログはリソース所有者にアプリにアクセス許可を付与するように求めます。リソース所有者が以前に必要なすべてのアクセス許可を削除していた場合、アクセス許可ダイアログは表示されません。セキュリティ - CHECK V!
- アプリ認証 - さて、ここが厄介なところです。ガイドには、「アプリ認証は、redirect_uri がデベロッパー アプリで構成されたサイト URL と同じドメインにあることを確認することによって処理されます」と記載されています。セキュリティ - 私の意見では - FAIL !
最後のステップがセキュリティの失敗だと思うのはなぜですか? まず、app id と redirect_uri はどちらも誰でも取得できる公開情報です。次に、redirect_uri は h**p://www.facebook.com/connect/login_success.html にすることができます。
次のシナリオを見てみましょう。デスクトップ アプリの EVE は、ユーザーが facebook にログインして EVE にいくつかの基本的なアクセス許可を付与する Web コントロールをユーザーに表示します。リソース所有者は、何かを疑う理由はありません。次に、EVE は Web コントロールを非表示にして、ロードを試みます。 .html&response_type=トークン. アプリは、最も人気のある Facebook アプリのアプリケーション ID を使用して、この URL を試して読み込むことができます。ログイン ダイアログと権限ダイアログの両方が表示されないため、ユーザーが以前に OTHER_APP を承認した場合、アプリは成功メッセージを受け取ります。これにより、リソース所有者が EVE ではなく OTHER_APP に許可したリソース所有者のすべてのリソースにアクセスするための access_token が EVE に与えられます。
それで、これはセキュリティホールですか？次の何かを見逃しましたか？
（アップデート）
明らかにデスクトップ アプリの場合、アプリには既にユーザー名と facebook セッション、さらにはユーザー名とパスワードさえあるため、セキュリティの問題は関係ありません。ユーザー アカウントを使用して何でも実行できます。
(更新) Web ブラウザーで実行される JavaScript アプリの場合、redirect_uri は実際に機能します! （hnrtによる回答とコメントを参照）。
現在の質問: 唯一残っている謎は、クライアント認証が iPhone および Android アプリでどのように機能するかということですか? セキュリティ全体は、デスクトップ アプリケーションを使用する場合と似ていますか? ジェイルブレイクされたiPhoneまたはルート化されたAndroidに違いはありますか?
乾杯！