1. 暗号化された通信と暗号化されていない通信の両方をどのように処理しますか? スパで https という 1 つのプロトコルに固執していませんか?
1 つのプロトコルにこだわる必要はありません。スパでは、ajax を使用して、http または https のいずれかをいつでも選択して通信できます。人の名前、生年月日、ログイン資格情報などの機密情報を送信するときはいつでも https を使用します。
ユーザーが https 経由でサイトにログインすると、サーバーはそのユーザーのフォーム認証 Cookie を設定できます。この Cookie は、セッションをサーバーに結び付ける暗号化された値である必要があります。サイトの残りの部分で http を使用している場合、この Cookie がプレーン テキストで送信されるリスクがあることに注意してください。選択した暗号化アルゴリズムを使用して Cookie の内容を暗号化することはできますが、悪意のある人物がこの Cookie を盗み、ユーザーのセッションをジャックする可能性があります。
ただし、サイトの閲覧とショッピング カートの作成のみが許可されている場合、これは大したことではないかもしれません。ユーザーがチェックアウトする準備ができたら、悪意のあるユーザーではないことを確認するための一種の二重チェックとして、https 経由でユーザーを再認証する必要があります。アマゾンはこれを行います。
2. どのような認証を使用すればよいですか?
まあ、それはあなたのサイトにどんな機能を持たせたいかという問題です.
OAuth他のサイトが委任されたアクセスで呼び出すことを許可できる Web サービスを公開するためのものです。これが意味することは、別のサイト (サイト x) が自分のプロファイルでサイトの機能にアクセスできるようにしたいユーザーがいる場合です。サイト x は、ユーザーを認証するサイトの oauth エンドポイントにユーザーをリダイレクトできます。oauth エンドポイントは、特定の機能がサイト x と共有されても問題ないかどうかをユーザーに尋ねます。ユーザーが同意すると、トークンが生成されます。ユーザーはこのトークンをサイト x に渡します。サイト x は、サイトに対してサーバー間呼び出しを行います。サイト x は呼び出しでトークンを提示するため、サービスへの呼び出しは委任されたアクセス呼び出しになります。OAuth は、サービスへの委任アクセスを作成するために他のサイトをプロビジョニングする方法です。私はそれを明確に説明できたことを願っています.. 私はいつもこれが得意というわけではありません.
OpenIDは、認証を処理するための安全な方法ではありません。ユーザーがサイトにアカウントを登録するのに煩わされる必要がないように、より便利です。OpenID は完全にオープンであるため、別のプロバイダーを信頼してユーザーを検証することになります。サード パーティ プロバイダーのユーザー ストアが侵害された場合、ユーザーも侵害されます。これは、OpenID プロバイダーに保証してもらうことができれば、基本的にあなたが誰であるかを信頼すると言っているバウチャー システムの例です。
別のソリューションはWS-Federationです。WS-Federation は、複数のサイトがあり、信頼できる 1 つの認証プロバイダーが必要な場合に使用します。この認証プロバイダーはあなたのものである可能性があり、基本的にすべてのサイトは、私のサイトにアクセスしたい場合は、最初に私の認証プロバイダーで認証を受ける必要があると言います. この認証プロバイダーは、別のドメインに存在することができ、選択した任意の認証メカニズムを選択できます。あなたは、この認証プロバイダーがユーザー アカウントを管理するために最善を尽くしてくれることを信頼しています。
ただし、サイトでの認証のみが必要で、複数のサイトがない場合は、WS-Federation はやり過ぎになる可能性があります。その場合、フォーム認証を行うことをお勧めします。これは簡単に実行できるはずです。これを行う方法の例はたくさんあり、マイクロソフトはこれを行う方法について多くのソリューションを提供しています。カスタム メンバーシップ プロバイダーの作成を検討する必要があります。
ユーザーがサイトで認証されたら、フォーム認証 Cookieを作成する必要があります。この Cookie は、ユーザーをサーバー上のセッションに関連付けます。これは、上記のすべてのシナリオに当てはまります。MVC 4 は、上記のすべてのシナリオもサポートしています。
ありがとうございます。私が十分に明確でない場合は、お気軽にさらに質問してください。
** 編集 12/1/2017 ** 数年後、この質問に戻って、REST ベースの API を Cookie に依存するのは得策ではないことを知りました。アプリのスケーリングが難しくなるため、Web アプリケーションでセッションを作成したくありません。そのため、認証が必要な場合は、何らかの形式の認証 (BASIC、DIGEST、トークン ベースなど) で HTTPS を使用します。そのため、SPA クライアント アプリはすべての http 要求に Authorization ヘッダーを設定し、Web サーバー アプリはすべての要求を再認証します。