Authentication

HTTP为访问控制和身份验证提供了一个通用框架。最常见的HTTP认证方案是“基本”认证。本页面介绍了一般HTTP验证框架，并展示了如何使用HTTP基本验证来限制对服务器的访问。

一般的HTTP认证框架

RFC 7235定义了HTTP认证框架，服务器可以使用该框架挑战客户端请求，并由客户端提供认证信息。挑战和响应流程如下所示：服务器响应具有401（未授权）响应状态的客户端，并提供有关如何使用WWW-Authenticate至少包含一个挑战的响应标头进行授权的信息。然后，想要使用服务器进行身份验证的客户端可以通过Authorization在凭证中包含请求标头字段来完成此操作。通常，客户端会向用户显示密码提示，然后发出包含正确Authorization标题的请求。

在如图所示的“基本”认证的情况下，交换必须通过HTTPS（TLS）连接进行以确保安全。

代理认证

代理验证可以使用相同的质询和响应机制。在这种情况下，它是需要认证的中间代理。由于资源认证和代理认证可以共存，因此需要一组不同的标题和状态代码。对于代理服务器，具有挑战性的状态代码是407（需要代理服务器认证），Proxy-Authenticate响应标头至少包含一个适用于代理服务器的挑战，并且Proxy-Authorization请求标头用于向代理服务器提供凭证。

访问被禁止

如果（代理）服务器接收到的有效凭证不足以获取给定资源的访问权限，则服务器应该使用403 Forbidden状态代码进行响应。不像401 Unauthorized或者407 Proxy Authentication Required，这个用户不可能进行身份验证。

WWW-Authenticate and Proxy-Authenticate headers

WWW-Authenticate和Proxy-Authenticate响应标头定义应该被用来获得对资源的访问的验证方法。他们需要指定使用哪种认证方案，以便希望授权的客户端知道如何提供凭证。这些标题的语法如下所示：

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

这里<type>是认证方案（“基本”是最常见的方案，下面介绍）。该领域用于描述保护区域或指示保护范围。这可能是“访问登台站点”或类似消息，以便用户知道他们试图访问哪个空间。

Authorization和Proxy-Authorization标题

所述Authorization和Proxy-Authorization请求报头包含凭证与一个（代理）服务器进行认证的用户代理。在此，需要再次输入凭证，凭证可以根据使用的认证方案进行编码或加密。

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

认证方案

一般的HTTP认证框架被多个认证方案使用。方案可以在安全强度和客户端或服务器软件的可用性方面有所不同。

最常见的认证方案是下面更详细介绍的“基本”认证方案。IANA维护认证方案列表，但还有其他由主机服务提供的方案，例如Amazon AWS。常见的认证方案包括：

• 基本（请参阅RFC 7617，base64编码凭证，请参阅下面的更多信息。），

• 承载（请参阅RFC 6750，承载令牌访问受OAuth 2.0保护的资源），

• 摘要（请参阅RFC 7616，Firefox中只支持md5散列，请参阅SHA加密支持的bug 472823），

• HOBA（参见RFC 7486（草案），ħ TTP ö rigin- 乙 ound 甲 uthentication，数字签名系），

• 相互（见draft-ietf-httpauth-mutual），

• AWS4-HMAC-SHA256（请参阅AWS文档）。

基本认证方案

“基本”HTTP身份验证方案在RFC 7617中定义，该身份验证方案将凭据作为用户ID /密码对发送，并使用base64进行编码。

基本认证的安全性

由于用户标识和密码以明文形式传递（它是base64编码，但base64是可逆编码），因此基本认证方案不安全。HTTPS / TLS应与基本认证一起使用。如果没有这些额外的安全增强功能，则不应使用基本身份验证来保护敏感或有价值的信息。

使用Apache和基本身份验证限制访问

要在Apache服务器上密码保护目录，您需要一个.htaccess和一个.htpasswd文件。

该.htaccess文件通常如下所示：

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

该.htaccess文件引用一个.htpasswd文件，其中每行包含由冒号（“：”）分隔的用户名和密码。您看不到加密的实际密码（本例中为md5）。请注意，.htpasswd如果您喜欢，您可以以不同的方式命名文件，但请记住，任何人都无法访问此文件。（Apache通常配置为阻止访问.ht*文件）。

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

使用nginx和基本身份验证来限制访问

对于nginx，你将需要指定一个你将要保护的位置，以及auth_basic为密码保护区域提供名称的指令。auth_basic_user_file然后该指令指向包含加密用户凭证的.htpasswd文件，就像上面的Apache示例一样。

location /status {                                       
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

使用URL中的凭据进行访问

许多客户端还可以通过使用包含用户名和密码的编码URL避免登录提示：

https://username:password@www.example.com/

这些URL的使用已被弃用。在Chrome中，出于安全原因username:password@，URL中的部分甚至被删除。在Firefox中，检查网站是否实际需要身份验证，如果不是，Firefox会提示用户提示“您将用用户名”username“登录到网站”www.example.com“，但是网站不需要认证，这可能是企图诱骗你。“

扩展内容

• WWW-Authenticate

• Authorization

• Proxy-Authorization

• Proxy-Authenticate

• 401, 403, 407