“Basic” HTTP 认证方案

这是一个互联网标准轨道文档。

本文档是互联网工程任务组 (IETF) 的产物。它代表了 IETF 社区的共识。它已接受公开审查并已获互联网工程指导小组 (IESG) 批准发布。有关互联网标准的更多信息，请参阅 RFC 5741 第2节。

有关本文档的当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc7617 查询。

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

本文档定义了“Basic”超文本传输协议 (HTTP) 认证方案，该方案以 user-id/password 对的形式传输凭据，并使用 Base64 进行编码（HTTP 认证方案的定义见 [RFC7235]）。

除非与某种外部的安全系统（例如 TLS（传输层安全，[RFC5246]）结合使用，否则该方案不被认为是安全的用户认证方法，因为 user-id 和 password 在网络上传输时以明文形式存在于编码前的数据中。

“Basic” 方案先前在 RFC 2617 第 2 节 中定义。本文更新了该定义，并通过引入 'charset' 认证参数（第 2.1 节）来处理国际化问题。

其它更新 RFC 2617 的文档包括 "Hypertext Transfer Protocol (HTTP/1.1): Authentication"（[RFC7235]，定义了认证框架）、"HTTP Digest Access Authentication"（[RFC7616]，更新了 “Digest” 认证方案的定义）以及 "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields"（[RFC7615]）。这四份文件合并起来废弃了 RFC 2617。

Basic 认证方案基于这样的模型：客户端需要为每个保护空间（"realm"）使用 user-id 和 password 对自身进行认证。realm 的值是一个自由格式的字符串，只能与该服务器上的其他 realm 做相等性比较。只有当服务器能够为应用于所请求资源的保护空间验证 user-id 和 password 时，服务器才会处理该请求。

Basic 认证方案采用认证框架（Authentication Framework），其细节如下。

在挑战中：

• 方案名称为 "Basic"。
• 认证参数 'realm' 是 REQUIRED（参见 [RFC7235]，第 2.2 节）。
• 认证参数 'charset' 是 OPTIONAL（见 第 2.1 节）。
• 未定义其他认证参数 — 未知参数接收方 MUST 忽略，新参数只能通过修订本规范来定义。

另见 RFC 7235 第 4.1 节，其中讨论了正确解析挑战的复杂性。

请注意，scheme 和参数名称的比较均不区分大小写。

对于凭据，使用了 RFC 7235 第 2.1 节 中定义的 "token68" 语法。其值按下文基于 user-id 和 password 的方式计算。

当接收到针对保护空间内某个 URI 的请求但缺少凭据时，服务器可以使用 401 (Unauthorized) 状态码（参见 [RFC7235]，第 3.1 节）和 WWW-Authenticate 头字段（参见 [RFC7235]，第 4.1 节）来响应。

例如：

HTTP/1.1 401 Unauthorized
Date: Mon, 04 Feb 2014 16:50:53 GMT
WWW-Authenticate: Basic realm="WallyWorld"

其中 "WallyWorld" 是服务器为标识该保护空间而分配的字符串。

代理可以使用类似的挑战来响应，但使用 407 (Proxy Authentication Required) 状态码（参见 [RFC7235]，第 3.2 节）和 Proxy-Authenticate 头字段（参见 [RFC7235]，第 4.3 节）。

为获得授权，客户端应当：

1. 从用户处获取 user-id 和 password，
2. 通过将 user-id、一个单冒号 (":") 字符以及 password 连接起来来构造 user-pass，
3. 将 user-pass 编码为一个八位字节序列（关于字符编码方案的讨论见下文），
4. 并通过 Base64（参见 [RFC4648]，第 4 节）将该八位字节序列编码为一系列 US-ASCII 字符（参见 [RFC0020]）。

原先对该认证方案的定义未明确指定用于将 user-pass 转换为八位字节序列的字符编码方案。实际上，大多数实现选择了区域相关的编码（例如 ISO-8859-1）或 UTF-8。为保持向后兼容性，本规范继续把默认编码保持未定义，只要其与 US-ASCII 兼容（将任何 US-ASCII 字符映射为与该 US-ASCII 字符码相同的单字节）。

user-id 和 password MUST NOT 包含任何控制字符（参见 RFC 5234 附录 B.1 中的 "CTL"）。

此外，包含冒号字符的 user-id 是无效的，因为 user-pass 字符串中的第一个冒号将 user-id 和 password 分隔开；第一个冒号之后的文本属于 password。包含冒号的 user-id 无法在 user-pass 字符串中编码。

注意，许多用户代理在生成 user-pass 字符串时并不检查用户提供的 user-id 是否包含冒号；接收方在这种情况下会将用户名输入的一部分当作密码的一部分来处理。

如果用户代理希望发送 user-id "Aladdin" 和 password "open sesame"，它将使用如下头字段：

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

包含 US-ASCII 字符集以外字符的 user-id 或 password 将导致互操作性问题，除非通信双方就使用哪种字符编码方案达成一致。服务器可以使用新的 'charset' 参数（见 第 2.1 节）来指示对 "UTF-8" 的偏好，从而增加客户端转换为该编码的概率。

'realm' 参数携带的数据可以被视为文本；然而，[RFC7235] 并未定义可靠传输非 US-ASCII 字符的方法。这是一个已知问题，需要在该规范的修订中加以解决。

Basic 认证方案并不是一种安全的用户认证方法，也不会以任何方式保护被传输的实体——这些实体在物理网络上传输时以明文形式存在（在 Base64 解码前的八位字节序列）。HTTP 并不阻止对 Basic 认证进行增强（例如使用一次性密码的方案）。

Basic 认证的最严重缺陷在于它导致用户密码在物理网络上以明文形式传输（在 Base64 解码前）。许多其它认证方案可以解决此问题。

由于 Basic 认证涉及密码的明文传输，除非配合诸如 HTTPS（参见 [RFC2818]）等增强，否则不应将其用于保护敏感或有价值的信息。

Basic 认证的一个常见用途是用于识别——要求用户提供 user-id 和 password 以便收集准确的使用统计数据等。当以此方式使用时，可能会误认为如果受保护文档的非法访问不是主要问题，则使用该方法没有危险。只有当服务器向用户发放 user-id 和 password 且特别是不允许用户自行选择密码时，这种观点才基本成立。危险在于天真的用户常常为了避免管理多个密码而重复使用单一密码。

如果服务器允许用户自行选择密码，那么威胁不仅是对服务器上文档的未授权访问，还可能是对用户用同一密码保护的其他系统资源的未授权访问。此外，如果服务器的密码数据库泄露，许多密码可能是用户在其他站点使用的密码。系统的所有者或管理者因此可能把所有用户暴露于其他站点的未授权访问风险中，这既有安全也有隐私方面的影响（见 [RFC6973]）。如果相同的 user-id/password 组合也用于访问例如电子邮件或健康门户等账户，个人信息可能会被泄露。

Basic 认证还易受伪造服务器的欺骗攻击。如果用户被误导以为自己正在连接到包含受 Basic 认证保护信息的主机，而实际上连接的是恶意服务器或网关，那么攻击者可以请求密码、保存以备后用并伪装成错误返回。服务器实现者应当防范此类伪造；尤其是能够接管现有连接上消息框架的软件组件需要谨慎使用或根本不使用（例如：RFC 3875 第 5 节中描述的 NPH 脚本）。

实现 Basic 认证的服务器和代理需要以某种形式存储用户密码以便认证请求。这些密码应以即使泄露也不易被恢复的方式存储。特别是当允许用户设置自己的密码时，这一点尤为重要，因为用户往往选择弱密码并在不同认证域间重复使用。尽管本文无法详尽讨论良好的密码哈希技术，服务器运营者应尽力在密码数据泄露时将对用户的风险降到最低。例如，服务器应避免以明文或未加盐的摘要形式存储用户密码。关于现代密码哈希技术的更多讨论，请参见 "Password Hashing Competition"（<https://password-hashing.net>）。

使用 UTF-8 字符编码方案和规范化带来了额外的安全考虑；详见 RFC3629 第 10 节 和 RFC5198 第 6 节。

IANA 维护 “Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry”（见 [RFC7235]）于 <http://www.iana.org/assignments/http-authschemes>。

“Basic” 认证方案的条目已更新以引用本规范。

方案定义已重写，以与较新的规范（如 [RFC7235]）保持一致。

新增了 'charset' 认证参数。该参数仅供参考，因此现有实现无需更改，除非希望利用此前不可用的附加信息。

本规范接管了先前在 RFC 2617 中定义的 “Basic” HTTP 认证方案的定义。我们感谢 John Franks、Phillip M. Hallam-Baker、Jeffery L. Hostetler、Scott D. Lawrence、Paul J. Leach、Ari Luotonen 和 Lawrence C. Stewart 在该规范上的工作，本文大量借用了他们的文本。更多致谢见 RFC 2617 第 6 节。

关于用于 user-pass 的字符编码方案的国际化问题早在 2000 年就作为 Mozilla 的 bug 报告提出（见 <https://bugzilla.mozilla.org/show_bug.cgi?id=41489>，以及最近的 <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>）。提出使用新 auth-param 来解决该问题的想法归功于 Andrew Clover。

我们也感谢 HTTPAUTH 工作组成员及其它审阅者，尤其是 Stephen Farrell、Roy Fielding、Daniel Kahn Gillmor、Tony Hansen、Bjoern Hoehrmann、Kari Hurtta、Amos Jeffries、Benjamin Kaduk、Michael Koeller、Eric Lawrence、Barry Leiba、James Manger、Alexey Melnikov、Kathleen Moriarty、Juergen Schoenwaelder、Yaron Sheffer、Meral Shirazipour、Michael Sweet、和 Martin Thomson 对本修订版的反馈。