外部oauth2プロバイダ（facebook）を使用しているときに自分のアクセストークンを自分のアプリで発行する必要がありますか？

Question

私は、ユーザーにいくつかの外部oauth2プロバイダー（facebook）と私のアプリでログインする可能性を与えたいと思います。クライアントの一部は、ネイティブアプリでモバイルデバイス上で実行されています。
以下のアプローチのどちらを好むべきですか？
A）クライアントはとFacebookのユーザーのアクセストークンをそれぞれリクエストで送信する必要がありますか？各リクエストでバックエンドはfacebookにアクセストークンの妥当性を確認します。検証の結果に基づいて、バックエンドは承認を実行し、対応する結果をクライアントに返します。
OR B）バックエンドは、ユーザログオンでのみアクセストークンを検証するように要求し、独自のアクセストークンを発行し、アクセストークンをクライアントに返し、クライアントはこのアクセストークンを使用してサーバに要求します各リクエストでfacebookをconntactingしないようにするには？

私はfacebookでauthを実装する方法についていくつかの質問を読んできました。ほとんどの開発者はBを使用していますが、なぜAを使用するのが良い/悪いのか説明していません。私は、ソリューションの利点として見る何

：
A）バックエンドは、発行さわやかな、これが唯一のFacebookの認可サーバによって行われますので、アクセストークンの検証を気にする必要はありません。
B）このソリューションは、リクエストごとにFacebookに接続する必要がないため、より効果的であるようです。

Answer 1

Facebookによって発行されたセキュリティトークンは、digital signatureで署名されています。 APIサーバーは、署名を検証するために公開鍵にアクセスする必要があります。ユーザーの認証後にFacebookに連絡する必要は全くありません。

ユーザーがFacebookにサインインした後で独自のトークンを発行する理由は、トークンにクレームを追加することです。しかし、明らかに独自の認証サーバーを使用することはコストがかかります。長所と短所を勘案するのはあなた次第です。

独自の認証サーバーを使用する場合は、独自の認証サーバーを作成しないでください。 Thinktecture IdentityServerのようなオープンソースオプションがあります。

Answer 2

私はあなたのAPIがアクセスして、このような場合、誰に、外部プロバイダトークンすることはできませんいくつかの認証トークン、との要求を毎回承認する必要があり

1. 、オプションBに投票し、ここで私の説明であるだろう他のプロバイダのトークン（例えば、他の開発者）があなたのAPIにアクセスすることができます。基本的にここには認証はありません。

2. あなたのサーバの問題のアクセストークン、それが検証するのは簡単ですし、必要なとき（例：パスワードのリセットに）簡単に取り消すことができ

3. 認証が、サーバーが完全にアクセストークンを発行することを制御しているので、検証は1回だけ行われるため、APIを呼び出すたびに検証を行う必要はありません。