桥接表单身份验证和 OAUTH

Question

修改表单身份验证登录过程并不难，因此除了正常的表单身份验证外，WebClient 对象对使用 Thinktecture IdentityModel 设置的 Web Api DAL 提供的 api/token url 进行基本身份验证。然后可以将返回的会话令牌存储在会话字典中，以供以后调用 DAL 时使用。

问题是这些令牌有不同的寿命。

我可以重写应用程序以将凭据保存在 localStorage 中，以便根据需要重新创建会话令牌，但这很丑陋，从安全角度来看并不理想。

可能有一些方法可以为这些系统中的一个或两个配置令牌持久性，但我不知道要使用什么搜索词（我尝试搜索令牌持久性和令牌寿命，但结果没有帮助）。

我对如何最好地协调这两种网络应用安全性的哲学和实用建议都很感兴趣。如果还没有关于这个主题的答案，我会感到非常惊讶，只要我知道要搜索什么。

---

一点背景知识，因为有些人不清楚我在问什么。

有一个又大又丑的老式 ASP.NET Web 应用程序，它使用基于表单的安全性

我刚刚添加了新的东西作为使用 Thinktecture IdentityModel 的单独 DAL 应用程序。此 DAL 由两个应用程序使用，即 ASP.NET 应用程序和 Durandal SPA。

它们使用相同的数据库进行凭据检查，因此它们具有相同的身份空间。

我已修改旧应用程序的登录过程，以便它还向 Thinktecture IdentityModel 提供凭据并从其获取会话令牌。每当旧应用调用 DAL 时，此令牌就会被放入 Session 集合中。

如果您启动旧应用程序、进行身份验证、执行操作并关闭浏览器，然后重新打开浏览器，您将拥有一个已登录的 ASP.NET 应用程序没有发生登录，因此没有机会创建会话令牌。这就是问题。我需要这两个令牌具有相同的生命周期。

---

我想到了一种可能的方法。我将其作为答案呈现在下面，以便人们可以就其优点发表意见或提出改进建议。如果我想到任何其他想法，我会将它们作为答案提出来，我希望你也会这样做。

Answer 1

在服务器上，我知道用户 ID，无论是在生成会话令牌时还是稍后在没有它的情况下重新创建 ASP.NET 会话时。

我需要的是相当于 cookie 的服务器。快速搜索“服务器端 cookie”返回了几篇文章，其中一篇显然是我在 1999 年自己写的，所有这些都归结为“使用数据库”。

所以...我可以使用数据库。我们有一个用户表，我可以添加一列。或者我可以创建另一个包含三列的表：UID、SessionToken 和 CreatedAt。

CreatedAt 是一个日期时间，我可以从中确定令牌是否已过期，以及何时过期我可以使 ASP.NET 会话过期以强制重新登录。

---

我最终使用了一个变体。在我的具体情况下，使用 UID，可以从用户表中获取凭据。所以我将令牌和创建时间放入 Session 中，否则如上所述。当 Session 不包含令牌过期时间或令牌已过期时，我会获取凭据并请求令牌，然后更新令牌和过期时间。

所有这些都包含在一个异常处理程序中，该处理程序返回一个虚拟（无效）令牌，其最终结果是行为与具有相同持久性的令牌相同。

您会注意到我没有使用持久表。这样，故障点更少，并且不依赖于编辑数据库模式的能力。管理表中状态的成本至少与生成新令牌的成本一样高。