レストエンドポイントの保護

Question

WCFを使用して実装されたRESTエンドポイントがあります。すべてのデータはSSLで暗号化されています。私は、サービスの機能を公開するためにWebフロントエンド（これは単純なHTMLとJavascriptを使用しています）を開発しています。しかし、私は認証をどのように扱うかについて少し混乱しています。

Fielding 5.1.3： "...クライアントからサーバーへの各要求には、要求を理解するために必要なすべての情報が含まれている必要があり、サーバー上の格納されたコンテキストを利用できません。それゆえ完全にクライアントに保持されます。

当然ながら、ユーザーに資格情報を入力させるためのアプリケーションのログインページを用意し、RESTサービスでそれらを「認証」し、それらが有効であることを確認します。しかし、私がRESTサービスをステートレスに保つと、クライアント側に認証情報をどこに格納するのでしょうか？私はOAuth 1.0や2.0のドラフトなどのソリューションを検討しましたが、これは私が必要とするものではないようです。

主に私の質問は、ユーザーが「正常に認証された」場合、どのようにクライアント側でこの状態を維持できますか？ここで

は、データの流れです：

ユーザーは、ログインページを表示---> ブラウザは返信用のRESTサービスと待機にAJAX要求を提出する---> サーバーが有効返す---> RESTサービスは現在ロックされており、現在ログインしているユーザーのスコープ内の現在の「セッション」にすぐに使用できます。

Answer 1

私は同様の状況にあり、OAuth 2.0を使用しています。私はいくつかのドメイン、すなわちアカウントを管理するドメイン、開発者のドメイン、APIのドメイン、アプリケーションのドメインを管理しています。他の第三者がREST APIを使用することを許可します。 dotnetopenauth 4ではかなり簡単です。

RESTサーバー自体には状態はありません。どのWebアプリケーションも、アカウントWebサイトから「トークン」を要求し、それはopenid 2.0を使用してユーザーを認証します。 RESTサーバーへの「トークン」は、呼び出しごとに検証されます。状態は、トークンがデータベース（永続性用）とセッション（キャッシュ用）に格納されているという点で、Webアプリケーションによって維持されます。これは、アプリケーションに「秘密」を明らかにする必要なく、他のアプリケーションからユーザーを偽装するのに最適です。このプロトコルは、トークンの有効期限と失効を処理します。このアプリケーションは、AJAXを含むブラウザ要求のプロキシとして機能します。これにより、セキュリティ上のクライアント上のjavascriptが簡素化されます。

代わりに、Amazonの方法を使用して、RESTサービスが持つ秘密の要求に署名することもできます。リクエストごとに、同じアルゴリズムを実行してリクエストに署名します。リクエストが同じであれば、そのリクエストは正当なものであることがわかります。これはOAuth 2.0より簡単ですが、その秘密を取り消すために独自のスキームを作成する必要があります。

Answer 2

ユーザーが正常にログインすると、認証トークンを生成してユーザーのためのクッキー。その認証トークンは、db内でユーザーのユーザー名にマップされます。

ユーザーはすべてのリクエストに応じて、残りのサービスに送信し、そのトークンをCookieから取得し、ヘッダーまたは要求の本文に送信します。サービスはそのトークンを検索し、それをユーザー名と照合します。

The Microsoft Enterprise Library Security Application Blockを使用してトークンを生成できます。

Answer 3

私が見る最も簡単な解決策は、ログイン情報を暗号化されたクッキーに入れることです。クッキーがRESTfulなサービスの一部であるかどうかについていくつかの議論があり、クッキーがRESTに属していないという主張を理解することができますが、これは確かにクッキーを使用する最も簡単な方法です。私が見ることのできる最も読み易い解決策は、あなたが（そして、おそらく各呼び出しで）返すログイン・ハッシュを持つことでしょう。