5

OAuth 2.0 仕様では、リソース オーナーのパスワード クレデンシャル グラント タイプが定義されています。これにより、リソース オーナーのパスワード クレデンシャル (つまり、ユーザー名とパスワード) を承認グラントとして直接使用して、アクセス トークンを取得できます。

資格情報を直接提供する代わりに、ユーザーがクライアントで「Facebook 経由でログイン」できるようにしたいと考えています。その後、クライアントは、ユーザーの Facebook アクセス トークンを認証サーバーのアクセス トークンと交換できます。このスキームは OAuth2 のフレームワークに適合しますか?

4

1 に答える 1

2

その後、クライアントは、ユーザーの Facebook アクセス トークンを認証サーバーのアクセス トークンと交換できます。

2 つの認証サーバー (1 つは Facebook 用、もう 1 つはプライベート サーバー) を念頭に置いているということですか? はいの場合 - OAuth を悪用しているため、代わりに Authorization Code Grant スキームを使用する必要があります。

OAuth 2.0 仕様 (v25) の図 5 では、ワークフロー定義を見つけることができます。

  1. リソース所有者は、クライアントにユーザー名とパスワードを提供します。

  2. クライアントは、リソース所有者から受け取った資格情報を含めて、承認サーバーのトークン エンドポイントからアクセス トークンを要求します。リクエストを行うとき、クライアントは認可サーバーで認証します。

  3. 認可サーバーはクライアントを認証し、リソース所有者の資格情報を検証し、有効な場合はアクセス トークンを発行します。

これは Facebook http://developers.facebook.com/docs/guides/web/からの引用です。

ユーザーがサイトにログインするには、3 つのことが必要です。まず、Facebook はユーザーを認証する必要があります。これにより、ユーザーが本人であることが保証されます。第二に、Facebook はあなたのウェブサイトを認証する必要があります。これにより、ユーザーが他の誰かではなく、サイトに情報を提供していることを確認できます。最後に、ユーザーは Web サイトが自分の情報にアクセスすることを明示的に承認する必要があります。これにより、ユーザーはサイトに開示しているデータを正確に知ることができます。

どちらの場所にも、認証サーバーが 1 つだけあります。あなたの場合は Facebook です。

于 2012-05-24T13:57:32.723 に答える