.NET Web/Windows Forms与IIS Forms认证关系及旧认证机制问询

1. Forms Authentication与Web Forms的关联，以及新旧框架认证配置差异原因 #

二者名称共带"Forms"字段并非巧合，存在明确的技术传承关系，Windows Forms则与该IIS模块无任何关联：

• IIS面板中的Forms Authentication是IIS原生集成、面向.NET Framework时代System.Web技术栈的认证模块，最早就是为Web Forms模型设计的：Web Forms是.NET初代Web开发框架，其默认表单登录能力直接对接该IIS模块实现，登录Cookie校验、用户身份上下文构建都由IIS模块完成。Windows Forms是桌面应用开发框架，和Web场景的这个认证模块没有技术交集，名称重合只是因为二者都用"Forms"指代"窗体/表单"的通用概念。
• 基于.NET Framework开发的旧版ASP.NET MVC（MVC5及更早版本），整个运行时复用Web Forms同款的IIS经典集成管道，认证逻辑与IIS原生模块深度绑定。当时默认搭配的认证方案底层依赖IIS Forms Authentication模块拦截请求、校验凭证，因此部署时必须在IIS中启用该选项，否则认证逻辑根本不会执行。
• 你当前使用的.NET 6属于ASP.NET Core技术栈，整个Web运行时完全重写，彻底移除了对System.Web和IIS原生管道的依赖。包括ASP.NET Core Identity在内的所有认证逻辑，都是作为应用内中间件运行的，IIS在部署场景下仅承担反向代理、请求转发的角色，不需要参与任何认证流程，因此只需要开启匿名访问，保证所有请求都能进入应用的中间件管道即可，不需要开启IIS自带的Forms Authentication，错误开启反而可能导致IIS提前拦截请求，触发意外的认证跳转。

2. Identity框架之前的官方认证机制正式名称 #

ASP.NET Core Identity并不是直接替换了单一的"Forms auth framework"，在它之前微软官方推出过多代Web认证方案：

• 最早随.NET Framework 1.0/2.0发布、和IIS Forms Authentication深度绑定的整套用户管理认证体系，正式名称是ASP.NET Membership，配套角色管理模块为ASP.NET Roles。大家常说的"Forms Auth"本质是这套体系依赖的IIS底层认证模块，不是整套用户认证方案的正式名称。
• 在ASP.NET Membership之后、ASP.NET Core Identity发布前，微软在.NET Framework 4.x阶段先后推出过两代过渡方案：首先是轻量的ASP.NET Simple Membership，后续是基于OWIN（Katana）的认证中间件，后者已经实现了OAuth、第三方登录等能力，开始尝试脱离IIS原生模块的绑定，但仍然运行在.NET Framework的IIS管道上。

内容的提问来源于stack exchange，提问作者variable