2

今日の本格的な頭脳トレーニングのセッションの後、3-legged OAuth 認証をかなりよく理解しているように感じます。私がまだ理解に苦しんでいるのは、ユーザー ID の使用です。これまで見てきた例はすべて、サンプル スクリプトの先頭にユーザー ID を任意に割り当てて実行しているように見えます。それは私を混乱させます。

私が見たサンプル コードのほとんどは、OAuth「セッション」を管理するためにユーザー ID と OAuth サーバーのコンシューマ キーを使用するという概念を中心にしているようです (この用語をブラウザの「セッション」と混同しようとしていないため、引用符で囲んでいます)。 」）。たとえば、私が見たデータベース サンプル コードは、ユーザー ID とコンシューマ キー フィールドの値に基づいて、関連するトークンやその他の情報を格納および取得します。

私は今、いくつかの競合する理解の断片が競合し、対立している不確実な状態にあります。

1) OAuth セッションの詳細レコードまたは「OAuth ストア」ルックアップに関する私の理解が正しければ、コンシューマー キーとユーザー ID フィールドを介して、接続するアプリケーションを使用する各ユーザーに対して異なるユーザー ID を持っている必要はありませんか? OAuthサーバーと？

2) 1 が正しい場合、別のユーザー用に独自のユーザー アカウントを作成する必要がないようにするにはどうすればよいですか? OAuth 対応サービスのフロント エンドとして機能するソフトウェアを作成しようとしているので、自分のユーザー レコードと付随するメンテナンスの頭痛の種を持つ必要はありません。代わりに、OAuth サーバーにパズルの終わりを処理させます。ただし、私のアプローチの欠点は、セッションごとにユーザーを再承認する必要があることです。これは、自分の永続的なユーザー アカウント/ID がないと、以前に付与された「取り消し済み」アクセス トークンを検索できなかったためです。正しい？

3) 私が気になっているのは、一部の OAuth サーバーが、未承認のトークンの要求中に動的に指定されたコールバック URL の受け渡しを許可せず、コンシューマー キーとユーザー ID を自分自身に渡すことを不可能にしているという記事を読んだことです。代わりに、開発者/消費者として登録するときにコールバック URL を指定するだけです。幸いなことに、私が扱っている OAuth サーバーではその機能が許可されていますが、そうでないものを扱っていたとしても、コンシューマ キーとユーザー ID のペアを使用するというアイデア全体に巨大なモンキー レンチが投げ込まれるのではないでしょうか。 OAuth セッションの詳細をインデックス化するには?

4

2 に答える 2

2

これは、Lode による質問に対する回答です。

プロバイダーがユーザー ID を持つ必要があるだけでなく (論理的に聞こえます)、クライアントも持つ必要があるというのは正しいですか? そのため、クライアント (ログイン システムとして OAuth を使用) は、OAuth サーバー経由でユーザーを正常に認証する前に、(ID を使用して) ユーザーを作成する必要があります。認証が失敗したり、アクセスが許可されない場合に、多くの空のユーザー アカウントを作成します。

コンシューマ アプリケーションでローカル アカウントを使用せずに OAuth を使用してユーザーの認証を行うことは可能ですが、内部セッション表現を保持するために何らかの種類のセッション メカニズム (cookies/get params) が必要です。 oauth_token.

たとえば、誰かがあなたの Web アプリケーションにたどり着き、あなたのアプリケーションが何らかの OAuth プロバイダーのコンシューマーである場合、エンド ユーザーのためにサイトでローカル セッションを作成する必要があります。たとえば、Cookie を使用します。次に、トークンの承認のためにエンドユーザーを OAuth プロバイダーに送信し、アプリケーションがプロバイダーから保護されたリソースを取得できるようにします。現在、あなたはユーザーについて何も知らず、彼の身元を気にしません。プロバイダーからの保護された情報を使用したいだけです。

認証が成功した後にユーザーがプロバイダーから戻ってきて、oauth_token を戻したら、ユーザー用に以前に作成したセッションにこのトークンを保存する必要があります。セッションを維持している限り (さらにリソースのリクエストにトークンが必要な場合はトークンも)、エンドユーザーがログインしていると見なすことができます。セッションを削除するか、トークンの有効期限が切れた瞬間に、エンドユーザーを考慮することができます。ログインしなくなりました。この方法では、独自のユーザー DB テーブルまたはストレージ メカニズムを作成する必要はありません。

ただし、ユーザーセッション (ログイン) 間で使用される、アプリケーション内のユーザーに関する永続的な情報が必要な場合は、情報を関連付けるユーザーを知るために、独自のユーザーを維持する必要があります。

openid と oauth の違いについては、ローカル アカウントの観点からは違いはありません。それはすべて同じです。違いは、openid では基本的なユーザー情報 (電子メールなど) をすぐに受け取るのに対し、oauth ではトークンを受け取り、基本的なユーザー情報 (電子メールなど) を取得するためにもう 1 つの要求を行う必要があることだけです。

ただし、OpenID または OAuth を使用する場合、ローカル アカウントに関しては違いはありません。

于 2012-08-28T09:27:10.617 に答える
1

あなたが提起した問題について私の見解を伝えようとし、それが少しでも解決することを願っています...

まず、サードパーティのアプリケーション (消費者) がアクセスしたい API またはデータを OAuth サーバーが保護しているという考え方です。

OAuth サーバーの背後にある API にユーザー アカウントやデータがない場合、コンシューマ アプリケーションはなぜサービスを使用する必要があるのでしょうか? サービスは何を取得するのでしょうか? そうは言っても、OAuth サーバーがあり、その背後にユーザー アカウントがないというシナリオは想像できません。

API を介してユーザー データを提供せずに、ユーザーのログインに OAuth を使用するだけの場合は、OpenID を使用することをお勧めしますが、ここでもユーザー アカウントが必要になります。

コンシューマー キーと (あなたの) ユーザー ID を介してルックアップを行うという点は正しいです。これは、プロトコルの設計によるものです。

一般的な流れは次のとおりです。

  1. OAuthサーバー（プロバイダー）がコンシューマーアプリに不正なリクエストトークンを発行
  2. コンシューマーは、OAuth サーバー (プロバイダー) でリクエスト トークンを承認するためにエンド ユーザーに送信します。
  3. エンドユーザーがトークンを承認した後、アクセス トークンが発行され、コンシューマーに渡されます (ここでは詳細と手順の一部を省略しました。これらは私が言いたいことにとって重要ではないためです。たとえば、コンシューマーは有効なアクセス トークンを終わり）
  4. 承認ステップでは、ペアとして作成して保存するのは OAuth サーバーです。どのローカル ユーザー (プロバイダーのローカル) がどのコンシューマー (コンシューマー キーとユーザー ID のペア) を承認したかです。
  5. その後、コンシューマー アプリケーションがプロバイダーからエンド ユーザーのデータまたは API にアクセスする場合、アクセス トークンを送信するだけで、ユーザーの詳細は送信しません。
  6. 次に、OAuth サーバー (プロバイダー) は、そのユーザーのユーザー データまたは API 機能をコンシューマーに返すために、そのトークンを以前に承認したローカル ユーザー ID であるトークンによってチェックできます。

あなたがプロバイダーである場合、あなたの側にローカルユーザーなしで行くことはできないと思います.

コールバックの質問については、コンシューマー キーとユーザー ID を使用して OAuth セッションを処理する方法に関して、動的または静的 (登録時) のコールバック URL を使用しても違いはないと思います。OAuth 仕様自体は、コールバック URL を持つことをまったく義務付けていません。これはオプションのパラメーターであり、毎回送信するか、最初に 1 回だけ登録するかはオプションです。OAuth プロバイダーは、使用するのに最適なオプションを決定します。そのため、さまざまな実装が存在します。

プロバイダーがデータベースに静的に定義されたコールバック URL を持ち、コンシューマーに接続している場合、エンドユーザーを「false」コールバック URL にリダイレクトできないため、より安全なアプローチと見なされます。

たとえば、悪人が GreatApp のコンシューマ キーを盗んだ場合、元の GreatApp になりすまして元の OAuth サーバーにリクエストを送信できるコンシューマ EvilApp にすることができます。ただし、OAuth サーバーが静的 (定義済み) コールバック URL のみを許可する場合、EvilApp のリクエストは常に GreatApp コールバック URL で終了し、EvilApp はアクセス トークンを取得できません。

于 2011-04-20T07:14:16.610 に答える