详解三种不同的身份验证协议( 二 ) _身份验证

ANONYMOUS，请求未经身份验证的访问；

CRAM-MD5和DIGEST-MD5是质询响应身份验证方案，它们试图避免传输未经加密的密码；

NTLM，windows NT LAN Manager身份验证机制；

GSSAPI，是指主要用于促成Kerberos身份验证的API（参见下文）。

如今，人们通常会使用SASL方法（例如PLAIN或LOGIN），这些方法通过安全通道（例如TLS）以明文形式传输密码。
客户端到应用程序的身份验证框架：HTTPHTTP定义自己的身份验证框架，并具有自己的方法集。可以说，HTTP避免SASL的原因在于其无状态性和SASL不太相称。由于HTTP设计的运行机制是让客户端发送单个请求块，然后由服务器发送单个响应，因此HTTP协议不适用于SASL设想的身份验证完成之前的来回数据交换。
此外，对于每个请求都必须重复这种交换。
服务器通过发送一个401 Authorization Required错误，和WWW-Authenticate标头来请求身份验证以访问资源。该标头包含：

所需的身份验证方法；
“域名称”，提供对身份验证域的描述；
必须为给定方法指定的其他参数。与SASL不同，一般来说一台给定服务器只有一个方法（虽说HTTP RFC确实允许服务器通过发送多个WWW- Authenticate标头来支持多个方法，每个方法一个标头，但这种情况很少见）。然后，客户端使用包含相同方法名称和方法特定身份验证数据的Authorization标头重新发出其请求。（请注意，HTTP使用术语authorization-授权，而不是authentication-身份验证。）

一些常见的HTTP身份验证方法有：

Basic（基本），以纯文本形式指定用户名和密码；
Digest（摘要），指定一个用户名并以质询-响应模式哈希密码；
Negotiate（协商），允许使用GSSAPI，并实质上在HTTP身份验证内称为SPNEGO的GSSAPI之上，重新实现了SASL风格的方法协商模式。因为它涉及来回交换，所以可能需要多个请求，直到身份验证成功为止。Windows通常将“Negotiate/SPNEGO”用于NTLM或Kerberos身份验证。

客户端到应用程序的身份验证框架：SSH【详解三种不同的身份验证协议】SSH还使用一组可扩展的方法定义了自己的身份验证框架。最常用的方法有：

keyboard-interactive（交互式键盘），通过任意终端提示登录；
public-key（公钥），客户端证明其握有指定私钥；
gssapi，通过Kerberos登录（参见下文）。

客户端到应用程序的身份验证方法：策略客户端到应用程序的身份验证方法通常可以分为几个基本的类别：

完全遵循上下文身份验证（例如TLS客户端证书或IP地址身份验证）（例如SASL EXTERNAL）。
以明文形式发送用户名和密码，其中安全性（如果有的话）由封装的安全通道提供，并且在任何情况下，应用程序服务器最终以明文形式获得密码（例如SASL PLAIN；HTTP Basic；SSH keyboard- interactive）。
质询-响应方案，其中服务器发出质询随机数，客户端将密码哈希或其他构造应用于随机数和密码来响应质询（例如SASL CRAM-MD5）。

如今这些策略都已经过时了，首先是由于人们常结合使用TLS与纯文本传输，其次是因为它们倾向于避免以哈希形式在服务器上存储密码，或者要求以与验证方案相关的特定方式对密码进行哈希处理。这样的话，密码哈希方法就会和身份验证方法高度耦合。

非对称密码方案，其中客户端在不传输私钥的情况下证明其拥有私钥（例如SSH public-key；TLS客户端证书）。
Shared-secret（共享秘密）方案，例如TLS-PSK 。
零知识证明方案，例如SRP 。这些加密方式整洁但很少使用，并且还是会将身份验证协议与服务器上哈希密码的方法紧密耦合。
单点登录协议的客户端到应用程序部分。

应用程序到身份验证服务器另一类身份验证协议与客户端到应用程序的身份验证协议完全无关，而是应用程序到身份验证服务器的协议，或称后端协议。后端验证协议是在应用程序服务器和验证服务器之间使用的（而不是在要验证的实体和对其进行验证的实体之间做一个协议），以便验证客户端提供的验证细节。
这些协议经常用于网络访问场景中，其中“应用程序”服务器是网络设备，如路由器、交换机或Wi-Fi接入点。由于我们不希望网络中的每个Wi-Fi接入点都保留身份验证数据库的副本，因此后端协议允许将身份验证决策外包给一个中心化授权源。因此，后端协议必须与某种客户端到应用程序的身份验证协议结合使用：在客户端和应用程序之间使用客户端到应用程序协议，在应用程序和身份验证服务器之间使用后端协议。