身份验证是确定客户端是谁的过程，通常确定客户端是否有资格访问资源。 HTTP 协议支持身份验证作为协商访问安全资源的方法。
来自客户端的初始请求通常是匿名请求，不包含任何身份验证信息。 HTTP 服务器应用可以在指示需要身份验证时拒绝匿名请求。 服务器应用发送 WWW-Authentication 标头来指示支持的身份验证方案。 本文介绍 HTTP 的多个身份验证方案，并讨论了它们在 Windows Communication Foundation（WCF）中的支持。
HTTP 身份验证方案
服务器可以指定多个身份验证方案供客户端选择。 下表描述了 Windows 应用程序中常见的一些身份验证方案：
| 身份验证方案 | DESCRIPTION |
|---|---|
| 匿名 | 匿名请求不包含任何身份验证信息。 匿名相当于向所有人授予对资源的访问权限。 |
| 基本 | 基本身份验证发送 Base64 编码的字符串，其中包含客户端的用户名和密码。 Base64 不是一种加密形式，应该被视为以明文形式发送用户名和密码。 如果需要保护资源，强烈建议使用基本身份验证以外的身份验证方案。 |
| 摘要 | 摘要式身份验证是一种质询响应方案，旨在替换基本身份验证。 服务器将名为 nonce 的随机数据字符串作为质询发送到客户端。 客户端使用哈希进行响应，该哈希包含用户名、密码和 nonce 以及其他信息。 通过此交换引入的复杂性以及数据的哈希处理，使得在此身份验证方案下窃取和重复使用用户凭据变得更加困难。 摘要式身份验证需要使用 Windows 域帐户。 摘要式“领域”是 Windows 域名。 因此，不能使用在不支持 Windows 域的操作系统（例如 Windows XP Home Edition）上运行的服务器来进行摘要式身份验证。 相反，当客户端在不支持 Windows 域的作系统上运行时，必须在身份验证期间显式指定域帐户。 |
| NTLM | NT LAN 管理器（NTLM）身份验证是一种质询响应方案，它是摘要式身份验证的更安全变体。 NTLM 使用 Windows 凭据转换质询数据，而不是未编码的用户名和密码。 NTLM 身份验证需要在客户端和服务器之间进行多次交换。 服务器和任何干预代理必须支持持久连接才能成功完成身份验证。 |
| 谈判 | 协商身份验证在 Kerberos 协议和 NTLM 身份验证之间自动选择，具体取决于可用性。 如果 Kerberos 协议可用，则使用它;否则，会尝试 NTLM。 Kerberos 身份验证相比 NTLM 有显著改善。 Kerberos 身份验证比 NTLM 更快，允许使用相互身份验证和将凭据委派给远程计算机。 |
| Windows Live ID | 基础 Windows HTTP 服务包括使用联合协议进行身份验证。 但是，WCF 中的标准 HTTP 传输不支持使用联合身份验证方案，例如Microsoft Windows Live ID。 目前可以使用消息安全性支持此功能。 有关详细信息，请参阅联合身份验证和颁发的标记。 |
选择身份验证方案
为 HTTP 服务器选择潜在的身份验证方案时，需要考虑的几个项包括：
考虑是否需要保护资源。 使用 HTTP 身份验证需要传输更多数据，并可以限制与客户端的互作性。 允许匿名访问不需要保护的资源。
如果需要保护资源，请考虑哪些身份验证方案提供所需的安全级别。 这里讨论的标准身份验证方案中，最弱的是基本身份验证。 基本身份验证不会保护用户的凭据。 最强的标准身份验证方案是协商身份验证，它使用 Kerberos 协议。
例如，服务器不应在 WWW-Authentication 标头中展示任何未准备好接受或无法充分保护受保护资源的方案。 客户端可以自由选择服务器提供的任何身份验证方案。 某些客户端默认为弱身份验证方案或服务器列表中的第一个身份验证方案。