Web applications 服务器是否决定采用何种身份验证方法？

对于Web应用程序，是由服务器决定采用何种身份验证方法，还是由客户端决定

身份验证方法（如NTLM和Kerberos）是特定于浏览器的

在intranet web应用程序中，与NTLM和Kerberos相比，BASIC和Diget的地位在哪里

谢谢：）

如中所述，这需要双方的合作

当访问资源需要凭据时，服务器将返回一个

401

响应，其中包含一个或多个

WWW-Authenticate

头，指示其支持的身份验证类型。如果有多个

WWW-Authenticate

头，则客户端“必须选择使用其理解的最强身份验证方案，并根据该质询请求凭据。”

因此，答案可能是：

WWW-Authenticate: Basic realm="protected area"
WWW-Authenticate: Digest
        realm="protected area"
        qop="auth"
        nonce="ea9c8142787af00ec11bd0eac248cac930"
        opaque="cdc069ca3ffe57acff21c259deadbeef"
WWW-Authenticate: Negotiate

这表示服务器愿意接受中所述的基本和摘要机制，并使用中所述的“SPNEGO”（协商机制）接受NTLM或Kerberos

然后，客户机必须决定这些方案中哪一个是最强的，并再次发送请求。这取决于所讨论的用户代理，但这些机制按假定的优缺点进行评级（因此最首选的是最后一个）：

不提供安全性，明文密码可以轻松恢复。仅当对安全性的期望值为零或层已使用TLS加密时才应使用

是一种挑战/响应机制，它依赖于散列算法，而散列算法在这一点上被认为在加密方面并不强大

是一系列挑战/响应机制，即使在其最强（NTLMv2）的情况下，也依赖于加密不强的哈希算法。然而，NTLM的一个优点是，Windows计算机上的用户在登录期间将密码散列，这样他们就可以成为算法的输入，从而允许“单次登录”网站，而无需重新键入密码

使用可信密钥分发中心（KDC）提供安全身份验证，是内部网的最佳选择，但不太可能是internet上所有客户端的可行机制

通过使用TLS保护会话以提供传输加密，可以减少这些协议弱点的影响，并且应在任何不受信任的网络（即，整个互联网）上执行绝对