ASP.NETMVCを中間に持つ3層のWebアプリケーションを構築しています。応答性のために、ストレートMVCとWebAPIの組み合わせを使用しています。バックエンドデータは、トークンベースのサービスを使用して保護されます。
私たちの目的は、システムにログインするユーザーごとに新しいトークンを要求することです。すべてのトークンは同じユーザー/パスワードの組み合わせを使用して生成されますが、トークンをユーザー名とセッションに関連付けることができれば、少なくともある程度の追跡可能性が得られると考えました。
単純さと柔軟性のために、生成されたトークンをセッション状態に保存しています。WebAPI呼び出しの場合でも、WebAPI呼び出しのトークンにアクセスできるように、セッション状態を要求する必要があります。RESTリソースにアクセスする前に認証が必要です。
私はこれが悪いアプローチであるように聞こえるようにするSOに関する多くの投稿を読みました。選択肢は何ですか？そして、このソリューションの本当の制限は何でしょうか？
よろしくお願いします
ASP.Netはセッション識別子を認証Cookieとは別のCookieとして保存するため、認証とセッションが分離されているためにシステムが危険にさらされる可能性があるかどうかを考える必要があります。
この非常に単純な例を見てください。
ユーザーの最初のログイン時に、例外なくユーザーにパスワードの変更を強制したいので、ログインで設定
Session["MustCheck"] = trueしたコードで。ユーザーは賢く、これがセッションによって制御されていることに気づきます。彼らはどうやってそれを回避するのですか？
彼らはセッションクッキーを削除し、それによって現在のセッションを削除し、まだログインしています。
「MustCheck」がなくなったため、ユーザーはこれを完全に回避できます
あなたがすべての基盤をカバーする何かをしたいなら、クッキーは行く方法です。
実証済みの方法を使用して値を暗号化するCookieの値を暗号化する線に沿って何かを使用できます（独自の方法は使用しないでください）。
検証されたユーザーID、またはキーとしてのユーザーに関連する不変（ID）。
のいずれかを使用することもできます
セッションは比較的簡単に侵害されます。セッション cookie の暗号化 (安全な cookie であることを指定できますが、これは役に立ちます) や有効性の検証はありません。これにより、盗みや攻撃が比較的容易になります。
さらに、セッションは他の多くの理由で理想的ではありません。たとえば、asp.net ワーカー プロセスがリサイクルされるたびに、セッションが失われます。これにより、ユーザーは再ログインを余儀なくされます。そのため、ワーカー プロセスがいつリサイクルされるかを制御できないため、いつでもセッションがランダムに失われる可能性があります (さまざまな理由でリサイクルされる可能性があります)。
あなたのトークン システムの詳細を本当に知らないので、代替案を提案するのは難しいですが、FormsAuthentication が認証 Cookie をベースとして生成する方法を見ることができます。FormsAuthentication を使用して、チケットのユーザーデータにトークンを保存することもできます。