1

WebAPI と AngularJs に基づくアプリケーションの承認メカニズムを作成したいと考えています。

BasicHttpAuthentication を使用する記事をいくつか見たことがありますが、すべてのリクエストでユーザー名とパスワードを送信するという全体的な考え方は本当に好きではありません。ユーザー名とパスワードのペアを持たない OpenId 認証を使用したいため、私には合いません。

解決策を考えていますが、それを実装する方法がよくわかりません。概念は、ユーザーが通常の Web アプリケーションのように認証されるということです - ユーザー/パスワードを含むフォームを投稿するか、OpenId プロバイダーを選択します。ユーザーが正常に認証されると、そのユーザーは静的オブジェクトに配置され、一定時間 User オブジェクトが格納されます。次に、usertoken が生成され、クライアント アプリケーションに渡されます。クライアントは、リクエストごとにトークンをサーバーに渡します。ユーザーが適切な認証トークンを持つ上記の静的オブジェクトに存在する場合、データを取得する権限があります。

まず、これは問題に対する良いアプローチだと思いますか? 第二に、Cookieを使用せずに認証トークンを渡すにはどうすればよいですか? BasicHttpAuthentication のように、リクエスト ヘッダーに配置する必要があると思いますが、それを処理する方法が本当にわかりません。

4

1 に答える 1

1

BasicHttp認証

ユーザー名とパスワードをクライアントにキャッシュし、リクエストごとに永久に転送することについて、私はあなたと一緒にいます。不利に働く可能性がある基本認証のもう 1 つの側面は、サインオフの欠如です。パスワードを変更する以外に、基本認証セッションを「無効化」することはできません。一方、トークンは通常、有効期限を提供します。サーバー側の無効化が必要な場合は、発行日を確認して、「発行日 xyz より古いトークンは無効です」と言うことができます。

サーバーの状態

「ユーザーが正常に認証されると、静的オブジェクトに配置されます」と述べています。しかし、これはトークンとは無関係ですか? これは、認証セッションのサーバー状態管理を実装したいように思えますが、これは厳密には必要ではありません。ユーザー認証にはトークン自体で十分なはずですが、サーバーの状態を管理することも潜在的な障害となります。アプリプールのリサイクルや Web ファーム環境を考慮すると、サーバーの状態の管理が難しくなる可能性があります (2 つのサービスで同じ認証トークンを共有するが、状態/セッションを保存するための中央の "認証サーバー" との通信を必要としない場合)。 ?)

認証トークンを渡す

ヘッダーは間違いなく良い場所です。本当に、他にどこがありますか？Cookie、ヘッダー、メッセージ。ブラウザー クライアント以外では、Cookie はあまり意味がありません。また、メッセージに Cookie を含めると、メッセージの書式設定が少し混乱する可能性があります。

クライアントの実装

指定していませんが、.NET からサービスを呼び出すことに興味があるのではないでしょうか? その場合、 System.Net.Http.HttpClientがあなたの友達になる可能性があります。特に、DefaultRequestHeadersコレクションです。これを使用して、認証トークンを保存するカスタム ヘッダーを追加できます。

サーバーの実装

最近 ASP.NET 認証について調べていたときに、Mixed Authentication Disposition ASP.NET Module (MADAM) を調べることで、カスタマイズについて多くのことを学びました。MADAM をそのまま使用することに興味はありませんでしたが、その記事から学び、ソース コードを調べると、独自の認証モジュールを Web スタックに挿入する方法について多くのアイデアが得られました。

于 2012-11-22T23:19:04.747 に答える