保護されたWebサービスにもアクセスするiOSアプリでのFacebook認証の設計

Question

目標：実行中の保護されたWebサービスへのアクセスを必要とするiOSアプリケーションへのFacebook認証をユーザーに許可します。

前提条件：サインインにFacebookを使用しないことを選択したユーザーには、ネイティブ認証（および登録）システムがあります。

詳細：

ユーザーがシステム用に別のアカウント/資格情報を作成せずにFacebookでサインインするオプションを提供したいとします。
独自のネイティブ認証メカニズム（ユーザー名とパスワード）をサポートしているため、独自のユーザーIDを持ち、最初の資格情報の検証後の対話に使用される認証トークンを発行します。

Facebookの開発者向けドキュメントには、このためのベストプラクティスがないことに驚いています。既存のドキュメントはすべて、FB認証をWebサイトに構築すること、または認証を必要とするサービスのないスタンドアロンモバイルアプリのいずれかを想定しています。

これがどのように設計されるかについての最初の考えですが、それが正しいかどうかの検証が必要です。

クライアントがFacebook iOSログインをポップします
UIユーザーはFacebookの資格情報でサインインし、アクセストークンを取得します
iOSアプリはアクセストークンをサーバーに渡します
サーバーは、アクセストークンを使用してFBグラフAPIと通信し、（a）トークンを検証し、（b）そのアクセストークンのFBユーザーIDを取得します。

例えば私たちのサーバーは https://graph.facebook.com/me/?access_token=XYZ を呼び出し、JSONオブジェクトでプロファイル情報を返します
有効であると仮定すると、サーバーはJSONオブジェクトからユーザーIDを抽出し、ユーザーが既にアカウントを持っているかどうかを確認します。その場合は、そのセッションで使用する独自の認証チケットをクライアントに発行します。ユーザーがアカウントを持っていない場合は、FacebookユーザーIDで新しいアカウントを作成し、独自の一意のUserIDを割り当てて、認証チケットを発行します。
その後、クライアントは、認証を必要とする後続の対話で認証チケットを返します。

これは私にとって正しいアプローチのように思えますが、めちゃくちゃ基本的なことを見落としていて、間違った（複雑な）道を進んでいるかどうかはわかりません。

Dan Ray · Accepted Answer

私はこれを自分で処理しましたが、ここに私が噛んだ部分があります：

ステップ5で...ユーザーが自分のFacebook IDとはまったく別のアカウントに登録することは可能ですか？その後、彼らがFacebookでログインするとき…。そして、あなたは彼らに2番目のアカウントを作成し、最初のアカウントを失った。

Webサービスにログインしてからfacebookにログインし、facebook IDとローカルアカウントの関連付けを取得する方法が必要です。

それとは別に、あなたの計画は堅実に聞こえます。

Update：Facebookはそのようなシナリオの概要を説明するドキュメントを追加しました HERE

zoomcrypt · Answer

Facebookで述べられているように、httpsを使用して認証トークンをサーバーに送信します

アクセストークンの共有

データポリシーでは、アプリのアクセストークンを他のアプリと共有することを明示的に禁止しています。ただし、HTTPSを使用して転送が行われる限り、開発者はネイティブ実装と同じアプリのサーバー実装間でトークンを共有できます（つまり、同じアプリIDを使用）。

ivant · Answer

この戦略で見られる問題の1つは、誰かが別のFacebookアプリ用に取得したアクセストークンを提供できることです。私の知る限り、アクセストークンがアプリケーション用であることを確認する方法はないため、そのまま使用します。

しかし、それはあまり有害ではありません。一般的に、人/アプリはアクセストークンを共有するのではなく、保護しようとします。

これを悪用する可能性があるのは、誰かが独自のサイトまたはモバイルアプリを作成し、ユーザーのアクセストークンを取得し、APIを使用して認証を試みることです。これが成功すると（ユーザーがサイトにFacebookアカウントを持っている場合）、悪意のあるサイトはユーザーを偽装するAPIを使用できるようになります。

少し長いショットですが、うまくいくと思います。

編集：結局、アクセストークンを検証する方法があるように見えます。質問に関する@Daanielの回答を参照してくださいユーザーアクセストークンからアプリケーションIDを取得する（またはトークンのソースアプリケーションを確認する）。

hamsterdam · Answer

ソリューションは完全に機能します。

代替案かもしれません：最初のソーシャルサービスリクエストからクライアントでメールを取得して、Webサービスに送信してみませんか？ Webサービスはメールを保存するだけで、social_providerを保存することもできます。あなたのウェブサービスはメールの発信元を検証できないことを理解していますが、あなたのウェブサービスとクライアントの間に高い信頼関係はありませんか？ある場合は、適切な場所からの電子メールに依存できるようです。誰かが私にメールベースのアプローチを愚かにしている明らかなことを教えてください...