通常のフォーム認証に加えて、Thinktecture IdentityModel で設定された Web Api DAL によって提供される API/トークン URL に対して WebClient オブジェクトが基本認証を行うように、フォーム認証ログイン プロセスを変更することは難しくありません。返されたセッション トークンは、後で DAL を呼び出すときに使用するために、セッション ディクショナリに格納できます。
問題は、これらのトークンの寿命が異なることです。
必要に応じてセッション トークンを再作成するために、資格情報を localStorage に保持するようにアプリを書き直すこともできますが、それは見苦しく、セキュリティの観点からは理想的ではありません。
これらのシステムのいずれかまたは両方でトークンの耐久性を構成する方法がある可能性がありますが、使用する検索用語がわかりません (トークンの耐久性とトークンの寿命を検索してみましたが、結果は役に立ちませんでした)。
私は、2 種類の Web アプリケーション セキュリティを最適に調整する方法について、哲学的および実用的な提案に興味があります。何を検索すればよいかを知っていれば、このトピックに関する回答がまだなかったとしたら、非常に驚くでしょう。
一部の人々は私が何を求めているのかはっきりしていないので、少し背景を説明します。
フォームベースのセキュリティを使用する、醜い古い学校の ASP.NET Web アプリがあります。
Thinktecture IdentityModel を使用する別の DAL アプリとして新しいものを追加しました。この DAL は、ASP.NET アプリと Durandal SPA の 2 つのアプリで使用されます。
これらは資格証明チェックに同じデータベースを使用するため、同じ ID スペースを持ちます。
古いアプリのログイン プロセスを変更して、資格情報を提示し、Thinktecture IdentityModel からセッション トークンを取得できるようにしました。このトークンは、古いアプリが DAL を呼び出すたびに提示される Session コレクションに入れられます。
古いアプリを起動し、認証し、操作を行ってブラウザーを閉じ、後でブラウザーを再度開くと、ログインせずに ASP.NET アプリにログインしているため、セッション トークンを作成する機会がありません。これが問題です。同じライフサイクルを持つには、2 つのトークンが必要です。
1つの可能なアプローチを考えました。人々がそのメリットについて意見を表明したり、洗練された提案のコメントをしたりできるように、私はそれを答えとして以下に提示しています. 他のアイデアを思いついたら、答えとして投げます。あなたも同じことをしてくれることを願っています.