Windows、Forms、Passport、Claims 等。身份验证是BROWSER 身份验证方案。它们是浏览器与服务器通信以提供凭据的机制。它们与数据库或任何其他存储机制(嗯,主要是......)无关。这些只是实现细节。
FormsAuthentication 使用 cookie 存储一个加密值,告诉服务器用户已通过身份验证。如果最终结果是颁发了 FormsAuthentication cookie,那么如何验证用户(无论是通过将事物与数据库进行比较、使用服务等)都无关紧要。
WindowsAuthentication 有点不同,浏览器和 Web 服务器通信以共享 Kerberos 票证以验证身份,或者用户在服务器请求浏览器弹出的框中输入用户名密码。在这种模式下,服务器本身管理身份验证发生的方式,而不涉及应用程序。
BasicAuthentication 使用 HTTP 标头以明文形式发送密码,从技术上讲,它是一个编码密码,但它众所周知,因此任何人都可以取消编码。同样,它存储数据的实际方法取决于服务器,而服务器在没有应用程序知识的情况下执行此操作。重要的部分是它是通过 HTTP Header 完成的。
其他类型的身份验证也是如此,它们都只是 cookie 和/或标头机制的变体。
这里的重点是,身份验证是关于任何给定的 HTTP 请求如何识别用户对服务器的身份,并最终确定应用程序。不是数据的存储方式或验证方式。因此,由于您没有告诉我们服务器和浏览器如何通信,我们无法告诉您身份验证是如何定义的,尽管几乎可以肯定它是 FormsAuthentication 的一种变体。
编辑:
只是一点历史课。之所以称为 FormsAuthentication,是因为身份验证系统不使用浏览器中的弹出对话框来输入凭据,而是通常网页提供一个 HTML 表单供用户输入凭据。除了根据请求传递 cookie 之外,浏览器根本不参与身份验证过程。
它应该更准确地称为“CookieBasedAuthentication”,但名称已卡住,可能会保持原样。 ASP.NET 提供了一个称为 FormsAuthentication 的特定实现,但是您可以对任何基于 cookie 的身份验证方案执行相同的操作(尽管我不建议您自己滚动,但您几乎肯定会犯安全错误)。
有些人认为在 Session 中存储一个标志就足够了。在任何情况下都不要使用 Session 来存储身份验证信息。会话 cookie 没有加密,很容易被窃取和/或欺骗。使用众所周知的方法。