2

2 つの部分に分割された Web アプリがあります。

  1. JavaScript フロントエンド。(myfrontend.com)
  2. API バックエンド (node.js)。(mybackend.com)

これら 2 つの部分は異なるドメインでホストされています。最終的には同じバックエンド (つまり、モバイル Web アプリなど) のフロントエンドをさらに構築するため、このようにする必要があります。

私が今認証している方法:

  1. ユーザーが myfrontend.com からログインすると、資格情報が mybackend.com に (ajax) 送信され、DB に対してチェックされます。彼らがチェックアウトしない場合、何も起こらず、mybackend.com はエラー コードで応答します。

  2. 彼らがチェックアウトする場合、express.js の Cookie セッションを使用し、mybackend.com は Cookie (mybackend.com ドメイン用) で応答します。サーバーは、DB から取得したユーザー ID をセッションにリンクします。

  3. それ以降、mybackend.com へのすべてのリクエストには Cookie が含まれ、バックエンドは Cookie を使用してセッションを見つけ、セッション内のユーザー ID 情報を使用して正しく応答します。

最初はこれに CORS の問題がたくさんありましたが、すべての適切なヘッダー (withCredentials など) を設定した後、すべてのブラウザーですべてがうまく機能しています。

これは非常に洗練されたソリューションだと思いました。すべてのユーザー情報はバックエンドで厳重に隔離されており、フロントエンドはユーザー データをまったく受信せず、有効期間が短い Cookie のみを受信するためです。

だから私は2つの質問があります:

  1. これは、この種のことを行う正しい方法ですか?OAuth はこれとはどのように実装されていますか? また、利点はありますか?

  2. Chrome でサードパーティの Cookie をオフにすると、これが機能しなくなります。ただし、サファリでサードパーティの Cookie をオフにしても、これは正常に機能します。どうしたんだ?「mybackend.com」に ajax を実行すると、「mybackend.com」の Cookie がサードパーティの Cookie と見なされるのはなぜですか? iframe などを使用してもよろしいでしょうか。これについて心配する必要がありますか?

4

1 に答える 1

1
  1. はい、これは使用するのに適したパターンです。http://hackhall.com ( https://github.com/azat-co/hackhall )でも同じアプローチを使用しました。OAuth は、消費者、サービス プロバイダー、およびアプリの 3 方向の認証に適しています。OAuth 1.0 では、時間に敏感なアクセス トークンを取得するために「oauth dance」が必要です。OAuth 2.0 は、消費者が初めてトークンを取得した後、パスワードとして機能する永続的なベアラーと交換できるため、より簡単です。OAuth Echo は、委任された呼び出し/要求用です。

  2. ブラウザーや Cookie ヘッダーの厳密さと関係がありますか?

于 2013-09-01T00:10:20.280 に答える