Forms身份认证虽然使用广泛，不过，如果是在 Windows Active Directory 的环境中使用ASP.NET， 那么使用Windows身份认证也会比较方便。 方便性表现为：我们不用再设计登录页面，不用编写登录验证逻辑。而且使用Windows身份认证会有更好的安全保障。
要使用Windows身份认证模式，需要在web.config设置：
<authentication mode="Windows" />
Windows身份认证做为ASP.NET的默认认证方式，与Forms身份认证在许多基础方面是一样的。 上篇博客我说过：我认为ASP.NET的身份认证的最核心部分其实就是HttpContext.User这个属性所指向的对象。 在接下来的部分，我将着重分析这个对象在二种身份认证中有什么差别。
在ASP.NET身份认证过程中，IPrincipal和IIdentity这二个接口有着非常重要的作用。 前者定义用户对象的基本功能，后者定义标识对象的基本功能， 不同的身份认证方式得到的这二个接口的实例也是不同的。
ASP.NET Windows身份认证是由WindowsAuthenticationModule实现的。 WindowsAuthenticationModule在ASP.NET管线的AuthenticateRequest事件中， 使用从IIS传递到ASP.NET的Windows访问令牌(Token)创建一个WindowsIdentity对象，Token通过调用context.WorkerRequest.GetUserToken()获得， 然后再根据WindowsIdentity 对象创建WindowsPrincipal对象， 然后把它赋值给HttpContext.User。
在Forms身份认证中，我们需要创建登录页面，让用户提交用户名和密码，然后检查用户名和密码的正确性， 接下来创建一个包含FormsAuthenticationTicket对象的登录Cookie供后续请求使用。 FormsAuthenticationModule在ASP.NET管线的AuthenticateRequest事件中， 解析登录Cookie并创建一个包含FormsIdentity的GenericPrincipal对象， 然后把它赋值给HttpContext.User。
上面二段话简单了概括了二种身份认证方式的工作方式。
我们可以发现它们存在以下差别：
1. Forms身份认证需要Cookie表示登录状态，Windows身份认证则依赖于IIS
2. Windows身份认证不需要我们设计登录页面，不用编写登录验证逻辑，因此更容易使用。
在授权阶段，UrlAuthorizationModule仍然会根据当前用户检查将要访问的资源是否得到许可。 接下来，FileAuthorizationModule检查 HttpContext.User.Identity 属性中的 IIdentity 对象是否是 WindowsIdentity 类的一个实例。 如果 IIdentity 对象不是 WindowsIdentity 类的一个实例，则 FileAuthorizationModule 类停止处理。 如果存在 WindowsIdentity 类的一个实例，则 FileAuthorizationModule 类调用 AccessCheck Win32 函数（通过 P/Invoke） 来确定是否授权经过身份验证的客户端访问请求的文件。 如果该文件的安全描述符的随机访问控制列表 (DACL) 中至少包含一个 Read 访问控制项 (ACE)，则允许该请求继续。 否则，FileAuthorizationModule 类调用 HttpApplication.CompleteRequest 方法并将状态码 401 返回到客户端。
在Windows身份认证中，验证工作主要是由IIS实现的，WindowsAuthenticationModule其实只是负责创建WindowsPrincipal和WindowsIdentity而已。 顺便介绍一下：Windows 身份验证又分为“NTLM 身份验证”和“Kerberos v5 身份验证”二种， 关于这二种Windows身份认证的更多说明可查看MSDN技术文章：解释：ASP.NET 2.0 中的 Windows 身份验证。 在我看来，IIS最终使用哪种Windows身份认证方式并不影响我们的开发过程，因此本文不会讨论这个话题。
根据我的实际经验来看，使用Windows身份认证时，主要的开发工作将是根据登录名从Active Directory获取用户信息。 因为，此时不需要我们再设计登录过程，IIS与ASP.NET已经为我们准备好了WindowsPrincipal和WindowsIdentity这二个与用户身份相关的对象。