对于Web应用程序，服务器是否会决定验证方法就是要遵循或者是它的客户。
是身份验证方法，如NTLM和Kerberos特定浏览器。
在一个企业内部网的Web应用程序，哪里BASIC和Diget站相比，NTLM和Kerberos？
谢谢 ：）
Answer 1:
随着讨论的RFC 2617 ，它需要双方的合作。
当需要凭据访问资源时，服务器会发送回一个401与一个或多个响应WWW-Authenticate标头表明它支持的身份验证类型。 如果有一个以上的WWW-Authenticate头，客户端“必须选择使用基于这一挑战的最强的auth-方案，它理解并请求凭证。”
因此，一个反应可能是：
WWW-Authenticate: Basic realm="protected area"
WWW-Authenticate: Digest
realm="protected area"
qop="auth"
nonce="ea9c8142787af00ec11bd0eac248cac930"
opaque="cdc069ca3ffe57acff21c259deadbeef"
WWW-Authenticate: Negotiate
这表明，如所描述的服务器愿意接受基本和摘要机制RFC 2617使用如在“SPNEGO”（即协商机制）和NTLM或Kerberos RFC 4559 。
然后，客户机必须确定这些方案是最强的，然后重新发送请求。 这是达到所讨论的用户代理，但这些机制在额定假定弱变强（因此最优选的是最后的 ）：
基本不提供安全，明文密码可以平凡恢复。 当存在安全或使用TLS当该层已被加密的精确为零的期望只应使用。
摘要是一种挑战/响应机制，依靠的是，在这一点上，不被视为强加密的哈希算法。
NTLM是这种挑战/响应机制，一个家庭-甚至在其最强（NTLMv2的）依靠哈希算法不强加密。 到NTLM的优点，然而，就是在Windows计算机上的用户都登录在这样的过程中散列他们的密码，他们可以成为输入的算法，允许“单点登录”到网站，而无需重新输入密码。
的Kerberos提供使用可信密钥分发中心（KDC）的安全认证，是企业内部网的最佳选择，但不太可能是一个可行的机制，以在互联网上的所有客户端。
任何这些协议的弱点的影响可以通过保护会话使用TLS提供交通加密会减少，而且绝对应该对任何不受信任的网络（例如，在大型互联网）进行。
文章来源: Does Server decide what Authentication Method is to be followed?
