4

私の e コマース サイトでは、ユーザーに openid ログインを提供しています。Facebook を除くすべての主要プロバイダーは、この openid エンドポイントを提供しました。Facebook は oauth 2.0 のみを提供していました。

その例外のために、ユーザーが facebooks oauth を使用してログインできる openid エンドポイントを自分でセットアップしました。

つまり、ユーザーが facebook を使用してログインする仲介サイトを作成し、そこから openid を使用して e コマース サイトにシームレスにログインします。これには、ヘッダーのリダイレクトのみが含まれ、エンド ユーザーに対して透過的に機能します。

現在、Amazonはシングル サインオン プロバイダーのリーグに参加しています。それらは oauth 2.0 のみをサポートします。

全体として、oauth 2.0 が最有力候補であり、openid ではないようです。これは、私が関心を持っているすべてのプロバイダーが今では oauth もサポートしているためです。

そこで、e コマース サイトに直接 oauth を実装することを考えました。

ただし、実装手順はプロバイダーによって大きく異なります。

ほとんどの場合、サイトに外部の JavaScript をロードする必要があります。サポートしたいすべての oauth プロバイダーに外部 JavaScript をロードすることは、避けたいオプションです。

Facebook は、javascript を含まない、完全にサーバー側の方法を提供します。

アマゾンはしません。

しかし、それはすべて oauth 2.0 ではないでしょうか?

標準が非常に緩和されているか、一貫して実装されていないように見えます。

プロバイダーに固有の構成とエンドポイントを渡してログインを達成するだけの一般的な oauth 2.0 クラスを持つことは可能ですか?

Zend の実装を見てみましたが、本当に巨大です... facebook の JavaScript を使用しない実装は本当に小さいです...

私はここで少し迷っています。誰かが私を正しい方向に向けることができますか?

複数の oauth プロバイダーを実装したいと考えています。確かにグーグル、フェイスブック、アマゾン、ツイッター。

これを同じコードベースで作成することは可能ですか、それとも sdk クラスと JavaScript を使用して個別に実装する必要がありますか?

私は問題なくそれを行うことができましたが、いくつかの理由（メンテナンス、柔軟性、新しいプロバイダーの追加など）で私の根性は本当に好きではありません..

そして、その中でoauth 2.0標準はどこにありますか?

どんな助けでも感謝します。

個人的な余談

この場を借りて、Oauth が好きではないことを簡単に指摘してしまったことをお詫びします。それを使用するすべてのサイトが oauth プロバイダーに登録する必要があります。また、これらのプロバイダーは、サイトとの協力に同意しない場合があります。私はその権限が好きではありません。openid の方が好きです。私はそれが完璧ではないことを知っていますが、私はそれを好みます. また、openid と oauth は、悪意のあるサイトがユーザーにログイン ボタンをクリックさせ、ユーザーがプロバイダー サイトにログインしていると信じ込ませてログインする偽のプロバイダー側​​を開くという攻撃に対して設計上脆弱です。ユーザーは URL を見て、それが本当に目的のサイトかどうかを確認する必要があります。これは根本的な問題であり、扱いが難しいことは承知していますが、指摘したいと思います。

4

2 に答える 2

4

プロバイダー間には多くの類似点があり、基本的なフローは同じです。多くの場合、ブラウザーで Javascript は必要ありません。各プロバイダーが提供するものは、物事を簡単にするためのヘルパーにすぎません (それらを気にするだけの場合)。

Webサイトの制作をされているようです。そのために、実装する必要がある OAuth 2 フローはAuthorization Code Flowと呼ばれます。要するに、非常によく似たパターンに従ういくつかの http(s) リクエストにすぎません。

  1. ユーザーをプロバイダーにリダイレクトする
  2. ログインと同意ページ
  3. あなたのサイトに (登録されたコールバック アドレスに) リダイレクトします。code
  4. ステップ #3 と/ (基本的には Web サーバーの資格情報access_token) を使用して、プロバイダーからを要求する Web サイト。codeclient_idclient_secret
  5. #4 で取得したを使用してaccess_token、プロバイダー API を呼び出します。

詳細をご覧になりたい場合は、こちらに書いています。これは私が取り組んでいる製品のコンテキストにありますが、原則は同じです。

物事がもう少し複雑になるのは、次の場合です。

  • scopeプロバイダーごとに異なるアクセス許可。例: Facebook には多くのオプションがあり、ユーザーに開示を要求する内容 (友人、写真など) を非常にきめ細かく制御できます。LinkedIn は少ない (プロファイル、ネットワーク、通知など)。Amazon には (name、post_code) が 2 つしかありません。

これらはすべて、管理しているリソースに関連しているため、プロバイダー固有です。OAuth は本質的に認可プロトコルであることに注意してください (認証によく使用されます)。多くの場合、API を呼び出さない場合は、最小限のスコープで問題ありません。

  • ユーザー プロファイル情報。ほとんどのプロバイダー/userprofileには、ログインしているユーザーの属性を取得するためのエンドポイントがあります。しかし、多くの場合、通常はそれぞれが異なるスキーマを実装emailしていemailaddressます。last_namevsなどと同じfamily_nameです。プロファイルを一般的なセマンティクスを持つものに正規化するのはあなた次第です。

openid connect私たちのシステムでは、可能であればすべてをuserinfo標準クレームにマッピングすることを選択しました。通常、プロバイダーはより多くの情報を提供するため、常に可能であるとは限りません。（実際に提供するものはこちら）

あなたの補足事項について：あなたは正しい、SSLを常に使用する正当な理由です。また、一部のプロバイダーが多要素認証を追加している理由もあります.

于 2013-06-06T14:51:05.187 に答える
1

実際、OAuth クライアントを実装するのに JavaScript はまったく必要ありません。OAuth 2.0 (または 1.0) は標準であるため、OAuth を実装するサイトに接続するには、同じ手順に従う必要があります。

PHP では、このライブラリを使用しましたが、OAuth 2.0 に適合するかどうかはわかりませんが、1.0 と 1.0a を使用しました。

接続する必要があるすべてのサーバーに適合する必要があります。また、OAuth プロトコルの「理論」に関するいくつかの読み物が役立ちます: http://oauth.net/2/

于 2013-06-06T13:29:21.187 に答える