なぜiOSアプリフィードダイアログにサーバー側のフローoauthトークンを使用できないのですか？

Question

私はデスクトップWebサイトとネイティブiOSアプリケーションの両方を持つ製品を開発中です。私たちは、両方の状況において、ユーザーのログインオプションとしてFacebook Connectを提供しています。

私の意図は、両方のコンテキストで使用するために、安全なJSON APIを使用して同じFacebookトークンを共有することでした。ユーザーがWebにサインインすると、トークンがバックエンドに格納され、モバイルクライアントが次に実行されるときトークンをダウンロードして使用することもできますし、逆も同様です。 （*私は、質問の最後に説明し、このアプローチのための詳細な理由は、との質問には必須ではありません。）

問題：iOSのクライアントは、そのトークンがある場合は、feed dialogをプリセットするトークンを使用する場合、 server-side flowを使用してWebで生成され、ダイアログのWebViewがエラーをレンダリング：

「エラーは、後ほど再度お試しください{私のアプリ名}で発生しました。」

これは確実に再現性がある：

1. は、サーバー側のフローを使用して新しいアクセストークンを生成します。フィードダイアログを使用しているので、publish_actions権限をリクエストしてください。シークレットブラウザウィンドウを使用して
2. （空のクッキージャーを取得する）、iOSのフィードダイアログがWebViewのでレンダリングすることをm.facebook.comページビュー：あなたができる＃2にhttps://m.facebook.com/dialog/feed?access_token=SERVER_SIDE_FLOW_ACCESS_TOKEN&app_id=YOUR_APP_ID&redirect_uri=fbconnect%3A%2F%2Fsuccess&sdk=2&display=touchまた

をFacebook SDKを使ってダミーのiOSアプリを作成し、それを正しくインスタンス化してダイアログを表示するという作業（私がすでに行った作業）エラーを再現する目的で、m.facebook.comのフィードURLに直接進む方が簡単です。

サーバー側の認証フローではなく、ネイティブのFacebook iOS SDKによって開始された認証フローによってトークンが生成された場合、上記のフィードURLは正常に動作します。

さらに、トークン（モバイルまたはサーバー生成）は、グラフAPI経由でフィード項目を直接ポストするために問題なく動作します。問題は実際にはモバイルフィードのダイアログだけです。

Facebookは意図的にサーバー側で生成されたトークンがモバイルフィードのダイアログコンテキストで動作しないようにしていますか？

これはm.facebook.comのフィードダイアログエンドポイントのバグですか？

または、うまくいけば何か間違っていますか？

---

なぜトークンを共有したいですか？

• オフラインアクセス許可が削除されているため、各クライアント（Web対モバイル）は、ユーザーがアクティブなときに他のクライアントに同じトークンをリフレッシュさせることでメリットを得ることができます。これにより、トークンの有効期限のインスタンスが少なくなるため、ユーザーがゼロから再認証する必要が少なくなります。
• 同様に、各クライアントはもう一方の許可の恩恵を受けることができるので、ユーザーはあまり頻繁に追加の許可を承認する必要はありません。

Answer 1

サーバー側の認証から取得するトークンは、クライアント側のトークンとは異なります（私はクライアントとしてiOS/Androidを見ています）。 サーバーのトークンは1つ（60日）、クライアントは短期間（数時間）存続します。

サーバー側のフローでは、サーバーがフェイスブックサーバーに対して認証する別のセキュリティレイヤーが追加されます。このフローを使用すると、おそらく長生きのトークンが自動的に取得されます。

アクセストークンを使用してdebuggerを試すと、トークンの「発信元」などのトークンに関する情報が表示されます。 たとえば、クライアント側auth（jsを使用）から生成されたトークンには、 "Origin：Web"があります。 これは、実際にはFacebookがトークンを区別することを意味します。

私はこれについて100％は確信していませんが、facebookのように聞こえるのは、ダイアログボックスがユーザーにしてもらえないので、クライアントトークンの使用にUIを限定し、アプリケーションを必要とせずに権限を取得することができます。したがって、60日間のトークンを持っている場合、アプリはユーザーの代わりにそのトークンを使用して、自分の許可を得ずに自分のために行うことができます。 私はここで推測しています。

サーバートークンのみをサーバー側で使用し、iOSクライアントが自分のトークンを処理できるようにすることをお勧めします。 はHandling Invalid and Expired Access Tokensガイドによると、それは述べて：

iOS native applications

API errors are handled by the FBRequestDelegate interface. When you detect an access token is invalid or has expired, your application will need to multi-task over to the Facebook iOS app. Assuming the user has not deauthorized your app, they will be immediately multi-tasked back to your iOS application with a fresh, valid access token.

あなたはトークンがクライアント側で有効期限が切れを心配する必要がないことを意味します。