多くの大規模な組織がこれを行っていますが、これは非常に重要な Web パターンであるため、この質問に対する回答が他にないのは残念です。
私は、あなたが独自の OAuth 2.0 プロバイダーを最初から開発しているのではないと推測します。
現在、OAuth 2.0 には次のエンティティがあります。
- Web サイトに登録されているユーザー
- Web サイトに登録されているアプリケーション (oauth2 にサブスクライブしているユーザー)
- ユーザーが「許可」したアプリケーションのリストであるユーザー権限
- 開発者 (認証 API / ウィジェットを使用し、アプリケーションを構築する人)
最初に注意すべきことは、各アプリケーションに関連付けられたドメイン名が必要なことです。そのため、開発者が Web サイトで API トークン/シークレットを登録すると、開発者が作成したアプリケーションは一意のドメインにマップされます。
これで、アプリケーションが Web サイトを介してユーザーを認証するための流れはすでに明らかになっていると思います。そうは言っても、これが機能するために多くのことをする必要はありません。
アプリケーションが (サインインするために) ユーザーを Web サイトに送信すると、ユーザーのコンピューターにセッション Cookie が配置されます。これを「Cookie-X」と呼びましょう。
これで、ユーザーは Web サイトによって認証され、アプリケーションに戻ります。そこで、そのユーザーに関する情報を含むカスタム ウィジェットを表示します。
開発者は、コードをコピーしてこのアプリに貼り付ける必要があります。
流れは次のようになります。
コードには、Web サイトにアプリケーションを登録するときに取得したアプリケーション ID (秘密ではない) を含む Web サイトへの URL が含まれます。
そのコードが実行されると、彼の appId を使用して Web サイトに ping が送信されます。その AppID をデータベースで確認する必要があります。さらに、リファラー URL が、その AppID の Web サイトに登録されているドメインと同じドメインからのものであることを確認する必要があります。編集:代わりに、または追加で、コードはそれをチェックしdocument.domain
て Web サイトへの ping に含めることができ、指定された AppID に登録されているドメインからリクエストが送信されたことを確認できます。
それが正しければ、JS コードを返信します。
JS コードは、ユーザーがサインインしたときに Web サイトが設定したセッション Cookie を探します。その Cookie が見つかった場合、セッションで Web サイトに ping を返し、Web サイトはカスタム ビュー コンテンツで応答します。
編集:コメントで正当に言及されているように、一般的な XSS 攻撃から保護するために、Cookie は HttpOnly である必要があります。
その他の注意事項
これが安全なアプローチである理由:
AppId とドメイン名は、他の人がこの情報を取得していないことを確認するのに十分な組み合わせです。appId がアプリケーションの html ソースに表示されていても、ドメイン名は、他人の AppID を使用しようとする人によってスプーフィングされる必要があります。
誰かが自分のものではない AppID を取得し、ウィジェットを要求するときにリファラーのドメイン名を偽装するコードを書いていると仮定しても、彼はまだ情報を見ることができません。ユーザー固有の情報を表示しているため、Web サイトがユーザーのブラウザーに配置したセッション Cookie を実際にはスプーフィングできない場合にのみ、ウィジェットがレンダリングされます。セッションハイジャックなどの方法がありますが、それはこの質問の範囲を超えていると思います。
その他の方法
Facebook のソーシャル プラグインを見れば、他にも選択肢があることがわかります。
たとえば、Iframe を使用することもできます。開発者に iframe をアプリケーションに追加するように依頼すると、上記の手順のいくつかを減らすことさえできます。しかし、正しいドメインなどを取得するために、JS を (iframe の外側に) 一緒に追加する必要があります。もちろん、アクセシビリティとインターフェイスの観点から、私は Iframe についてあまり知りません。