クライアントは、ユーザーのFacebookアクセストークンを認証サーバーのアクセストークンに交換できます。
2台の認証サーバー(Facebookと他の1つ)を念頭に置いているということですか?はいの場合 - あなたはOAuthを酷使しており、代わりに認証コード付与スキームを使用する必要があります。あなたはワークフロー定義を見つけることができOAuth 2.0の仕様(V25)から図5に
:
リソースの所有者は、そのユーザ名とパスワードをクライアントに提供します。
クライアントは、リソース所有者から受信した資格証明を含めて、承認サーバーのトークン エンドポイントにアクセストークンを要求します。 要求を行うと、クライアントは許可サーバーで認証されます。
許可サーバーはクライアントを認証し、リソース所有者 資格情報を検証し、有効な場合はアクセストークンを発行します。
これはFacebookのhttp://developers.facebook.com/docs/guides/web/からの引用である:あなたのサイトにユーザーをログインさせるために
、三つのことが起こるする必要があります。まず、Facebookはユーザーを認証する必要があります。これにより、ユーザーは自分が誰であるかを確認できます。第二に、Facebookはあなたのウェブサイトを認証する必要があります。これにより、ユーザーは他のユーザーではなく自分のサイトに情報を提供します。最後に、ユーザーは情報にアクセスするためにWebサイトを明示的に承認する必要があります。これにより、ユーザーは自分のサイトにどのようなデータを開示しているのかを正確に知ることができます。
どちらの場合でも、あなたのケースではFacebookが1つしかありません。
はい、このスキームには実際に2つの認証サーバーがあります。最初の部分はAPIの部分で、2番目の部分はFBです。だから私は、クライアントがすでにユーザーのFBアクセストークンを持っていれば、ユーザーのクレデンシャルとしてトークンを使用することができると考えました(ログイン/パスワードを入力する必要はありません)。その後、認可サーバーはトークンが有効かどうかを確認し、新しいトークンを発行することができます(独自のサーバー用)。私はこれが意味をなさないことを願っています:) –
そして、私は私の回答で書いたように、認可コード助成金を使用することが理にかなっています。 –