認証にサードパーティ（つまり、Google、Facebook、Twitter）を使用するRESTful Webサービスをどのように設計すればよいですか？

私の仕事のために、私たちが持っているいくつかのウェブサイトを動かすために使用する素敵なRESTfulウェブサービスがあります。基本的に、Webサービスを使用すると、サポートチケットを作成および操作でき、Webサイトがフロントエンドを担当します。Webサービスリクエストでは、認証ヘッダーを使用します。このヘッダーを使用して、呼び出しごとにユーザーとパスワードを検証します。

今年は、Webサイト上のユーザーがGoogle、Twitter、Facebook（おそらく他のユーザー）経由でログインできるように、ログインオプションを拡張することを検討しています。ただし、Webサービスがサードパーティの認証プロバイダーを使用して、ユーザーが本人であることを確認できるように、これをどのように設計するかについて多くの問題を抱えています。これを行うためのベストプラクティスはありますか？

現在、Webサイトでユーザー自身の認証を処理してから、現在のセッションをWebサービスバックエンドに登録する新しいsetSessionId呼び出しを使用することを考えています。Webサービスへの追加の各リクエストは、そのセッションIDを渡し、検証します。これらは大丈夫のように見えますが、私はこれを考えていないという私の頭の後ろの感覚を持っています、そして私のすべてのフォーラムの閲覧とoauthとopenidの仕様を読んでいるだけでもっと混乱させられます。これに取り組む方法のヒントはありますか？

次の2つの目標があるようです。

1. エンドユーザーが既存のソーシャルアカウントで簡単に認証できる
2. Webサービスを使用する開発者にとって簡単

サイトのリソースを使用することを人々に許可すると、クライアントライブラリの人気と可用性により、OAuth2が推奨されるメカニズムになります。

1.エンドユーザーが既存のソーシャルアカウントで簡単に認証できる

エンドユーザーは、APIを使用するサイトにアクセスし、ログインすることを選択します。OAuthログインページに送信されます。ログインページには、サイトで管理されているアカウントの通常のユーザー名とパスワードのプロンプトと、Facebookなどのサイト経由でクリックしてログインできるソーシャル認証ボタンのセットが表示されます。ユーザーがFacebookを選択すると、Facebookにリダイレクトして選択を承認します（facebook認証フローを開始します）。エンドユーザーがFacebookでログインを完了すると、エンドサイトにリダイレクトされます。

ユーザーがFacebookからサイトにリダイレクトされると、そのユーザーの情報をデータベースのユーザーレコードに保存し、そのユーザーの新しいセッションを生成します。oauth access_tokenを使用して、すぐにエンドユーザーを元のダウンストリームサイトにリダイレクトし、元のoauthフローを完了します。

2. Webサービスを使用する開発者にとって簡単

承認のプロバイダーである場合、oauthを完全に実装していない新しいアップストリーム認証プロバイダーを追加するたびに変更されない、依存する開発者向けのシンプルなインターフェイスを作成する必要があります。これが、OAuth2プロバイダーサイトを実装する必要があり、そのサイトがソーシャル認証サイトのコンシューマーであるべきだと思う理由です。

nice rest APIを使用する開発者にとっては、セッションキャプチャポスト（たとえば）でヒントを提供することを選択しない限り、Facebookの相互作用を認識しません。

TL; DR

OAuth2を実装し、ソーシャル認証の複雑さを隠すことで、あなたのようなAPIを利用できるようにします。ダウンストリームサイトのoauthフロー中に、facebookで追加のoauthフローをトリガーできます。

画像==単語* 1000のための画像：

これをoauth2-piggy-backと呼ぶことはできますか？

段階的な流れ

1. エンドユーザーがAPIを使用するサイトにアクセスします
2. エンドユーザーがサイトに送信され、承認またはサインアップされます（oauth2）
3. エンドユーザーがソーシャル認証を選択し、Facebookのログインボタンをクリックします
4. サイトはcookieを設定するかstate、facebookのoauthに設定して、ユーザーがどこから来たかを知る
5. Facebookにリダイレクトされ、Facebookサイトでの接続を受け入れるエンドユーザー
6. Facebookの認証プロセスを完了するためにサイトにリダイレクトされたエンドユーザー
7. データベースでユーザーを検索または作成します
8. サーバーで新しいセッションを作成します
9. セッショントークンを使用してユーザーを元のサイトにリダイレクトします

拡張可能にする方法

まず、これらすべてのapiがログインに同じメカニズムを使用していることに注意してください。これらはすべて、認証にOAuthを使用します。これは、一般的なOAuthライブラリから始めて活用する必要があります。認証に独自のライブラリを使用しないでください。これらは他のプロバイダーでは使用できません。OAuth2のコツをつかめば、プロバイダーを追加するのは非常に簡単です。

ツイッターはまだOAuth2の時流に乗っていないため、残念ながら2つ必要です。

OAuthでは、認証者用のインターフェースを作成する必要があります。トークンはサーバー間で交換されます。すべての通信を処理できる1つのエントリポイントを作成します。

トークンは、アカウントとは別のテーブルに保存する必要があります。これは、トークンが複数のトークンおよび複数のリンクされたプロファイルになる可能性があるためです。一部のサービスは2つのトークンを提供しますが、そのうちの1つは更新トークンです。

次に、必要な他の機能をカプセル化するインターフェースを設計します。私はこれのために個別のRESTサービスを個人的にセットアップします。これにより、認証を他の場所に簡単に拡張できます。
通信にJSONを使用するサービスもあれば、XMLを使用するサービスなどもあります。フロントユーザーの場合、すべてを統合する必要があります。これは非常に苦痛なプロセスですが、ここでいくつかの共通の根拠を導き出すことは可能です。

ここでの別の問題は、すべてのサービスが同じ機能を提供するわけではないということです。これは、指定したとおりにサービスが完全なAPIを提供できないことを意味します。ここで戦略を立てる必要があります。これにより、アプリケーションを適切にダウングレードできます。

これにより、新しいサードパーティプロバイダーを簡単に追加できるようになります。

トークンの問題

トークンには時間が限られているため、トークンがまだ使用可能かどうかを確認できるcronジョブがいくつか必要です。そうでない場合は削除する必要があります。このメカニズムによってトークンを更新することもできます。

ユーザーがトークンを撤回することが時々起こります。これに備えてください。

データストレージ

この設計がある場合、必要なデータについて考える必要があります。これは、作成したばかりのインターフェイスに一部従います。このためにいくつかのテーブルを設計し、データが実際に取得可能かどうかを確認します。一部のサービスでは、大量のデータを取得できません。また、必要なデータが多いほど、プライバシーメッセージが大きくなることも考慮する必要があります。必要に応じて控えめにしてください。さもないと、ユーザーは使用しません。

追加の検証のために、プロファイルを別個のユーザーにリンクされたテーブルに保存できます。これにより、誰かに関するより多くの情報が提供されます。

また、現地の法律を確認してください。一部のデータについては、追加の予防措置が必要です。

最後 に、自分のサービスでアカウントを作成しないという過ちを犯さないでください。ユーザーがfacebookから禁止された場合、ユーザーは事実上サービスにログインできなくなります。これは、作成したくない状況です。これはしばしば見落とされます。

私は間違いなくあなたがすでに理解しているように聞こえる解決策に行きます：クライアントに面したウェブサイトにサードパーティ認証を実装し、それらのサードパーティ認証トークンをウェブサイトのユーザーアカウントに関連付けてから、最後にsetSessionID呼び出しをトリガーしますログイン。

Webサイトのアーキテクチャによっては、EveryAuthやPassportなどのライブラリを使用すると非常に役立つ場合があります。

私の2セント：FB、Twitter、Googleのログインメカニズムがどのように機能するのか、これまでに一度もやったことがありませんが、質問を読んですぐにいくつかの問題が頭に浮かびました。

• 複数ログイン：ある日Facebookアカウントでログインし、翌日Googleアカウントでログインするとどうなりますか？または同時に？これらの2つのアカウントを一意の個別のアカウントとして扱いますか、それとも2つのアカウントを関連付けてチケットにアクセスできるようにする方法が必要ですか？
• 外部識別子に依存： FacebookまたはTwitterがアカウント識別子の表示方法を変更することを決定するとどうなりますか？たとえば、BazLoginがコード{4382-af56}を使用して一意のアカウントを表しているが、8個では不十分だったため、今後12桁のアカウントを使用すると決定した場合、{0000-4382から{1234-4382-af56} -af56}？

セッションIDだけでなく、外部アカウントを内部アカウントに関連付けることにより、これら2つの問題に対処できます。次に、外部ログインは、内部アカウントを作成するための単なるゲートウェイになります。複数のログイン方法で認証する場合、すでにログインしていると言うことができます。外部認証プロバイダーが依存するものを変更した場合、ユーザーに内部アカウントの名前とパスワードを入力して、将来のログインのための新しい関連付け。

あなたが念頭に置いていた問題に対処したかどうかはわかりませんが、具体的な懸念については本当に言及しませんでした。どちらにしても、私の答えが役立ったことを願っています。