2

私は Web サービスを開発しており、新しいユーザーを登録する代わりに、既知の認証プロバイダー (facebook、google など) を使用してユーザーにログインしてもらいたいと考えています。

このようなサービスの例として、スタック オーバーフローを取り上げます。

O-Authチュートリアルを読んで理解したところ、フローは次のようになります。

1. A user log in for the first time to Stack Overflow
2. User is asked to log in via Google or Facebook.
3. Stack overflow redirects the user to Google along with Stack Overflow app ID and a Redirect URL (Callback)
4. Google ask the user: "Stack overflow wants to access your account" - allow/deny. 
5. Assuming the user allowed, Google will redirect the user back to Stack Overflow, and will send a Token back to stack overflow servers (the Callback URL) as well as a client ID (unique google id)
6. If this client id does not exists, Stack overflow creates a new user in its database with this client id, if it does exists, it will just return the user's data (e.g. questions asked)
7. Using the saved TOKEN, stack overflow servers can grab information from Google (if needed) without the user interaction (since the user allowed access to Google)

この流れは正しいですか？もしそうなら、ここに主な質問があります。

クライアント側

クライアントは、Stack Overflow との間で情報を送受信したいと考えています (例: 質問の投稿)。

  • これが実際にユーザーであることを確認するために、クライアントはどのような情報をスタックオーバーフローサーバーに送信する必要がありますか?

サーバ側

  • スタック オーバーフローはどのようにこのユーザーを検証しますか? (つまり、スタック オーバーフローは、ユーザーを識別するためにユーザーにどのような情報を保存しますか? Google/Facebook ID?)

  • スタック オーバーフロー サーバーは、ユーザーの Google アカウント (ユーザーがこの操作を許可した) から情報を取得しようとしています。この情報を取得するために、スタック オーバー フロー サーバーが Google に送信する必要があるのはどのような種類の情報ですか。

4

1 に答える 1

0

あなたの仮定はほとんど正確だと思います。ただし、例外が 1 つあります。

5) ユーザーが許可されていると仮定すると、Google はユーザーをスタック オーバーフローにリダイレクトし、スタック オーバーフロー サーバー (コールバック URL) とクライアント ID (一意の Google ID) にトークンを送信します。

通常、OAuth2 サーバーは clientId やユーザーの詳細を返さず、トークンのみを返します。実際には、oauth クライアント (つまり、この例では stackoverflow) は、ユーザー ID をまったく認識してはなりません。OAuth2 は、ユーザー ID を取得することなく、クライアントの制限付きリソースにアクセスできるように設計されています。

ただし、クライアント（stackoverflow）が（例のように）ユーザーアカウントへのアクセスを要求した場合、トークンを使用して、後でユーザーの詳細を照会できます。ユーザーの詳細 (識別子など) は完全に認証サーバー (Google など) 次第です。サーバーがクエリ結果でそのような内部詳細を提供する場合でも、(stackoverflow) は、一般に利用可能な、プロバイダーに依存しない情報のみに基づいて clientId を生成する必要があります。たとえば、電子メール アドレスを使用します。

これは、サーバー側の 2 つの質問にも答えているはずです。

これが実際にユーザーであることを確認するために、クライアントはどのような情報をスタックオーバーフローサーバーに送信する必要がありますか?

シナリオの残りの部分では、役割を完全に逆にする必要があります。Google は範囲外になり、Stackoverflow は OAuth2 SERVER になり、アプリケーションは CLIENT になります。アプリケーションで質問を投稿したり読んだりしたい場合は、stackoverflow ユーザーからの承認が必要です。承認が付与されると、トークンが返されます。アプリケーションはトークンを使用して、Stackoverflow の質問にアクセスする必要があります。したがって、答えは次のとおりです。何もありません。トークンのみです。

答えを正しく完成させるために、言及されたサイト（google、facebook、stackoverflowなど）の実装の詳細に精通していないことを告白する必要があります。ただし、OAuth2 標準に準拠している場合は、説明したとおりに動作するはずです。よく知っているユーザーの皆様、シナリオの実装方法がサイトごとに異なる場合はお知らせください。

于 2012-10-29T15:01:58.593 に答える