RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication

Table of Contents

View Repo RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication - 图1 RFC7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication - 图2 

  1.                                                        PROPOSED STANDARD
  2.  
  3. Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
  4. Request for Comments: 7235                                         Adobe
  5. Obsoletes: 2616                                          J. Reschke, Ed.
  6. Updates: 2617                                                 greenbytes
  7. Category: Standards Track                                      June 2014
  8. ISSN: 2070-1721

摘要 / Abstract

The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.

超文本传输协议（HTTP）是一种无状态stateless的应用层协议，适用于分布式、协作式的超文本信息系统。本文档定义了 HTTP 的身份验证框架Authentication framework。

备忘状态 / Status of This Memo

This is an Internet Standards Track document.

这是一个 Internet Standards Track 文档。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

本文档是互联网工程任务组Internet Engineering Task Force（IETF）的产品。它代表了 IETF 社区的共识。它已经接受公众审核并且已经被互联网工程指导组Internet Engineering Steering Group（IESG）批准发布。有关互联网标准Internet Standards的更多信息，请参阅 RFC 5741 章节 2。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7235.

关于本文档的当前状态，任何勘误以及如何提供反馈的信息可以从 http://www.rfc-editor.org/info/rfc7235 获得。

Copyright Notice

Copyright © 2014 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.

1. 引言 / Introduction

HTTP provides a general framework for access control and authentication, via an extensible set of challenge-response authentication schemes, which can be used by a server to challenge a client request and by a client to provide authentication information. This document defines HTTP/1.1 authentication in terms of the architecture defined in "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing" [RFC7230], including the general framework previously described in "HTTP Authentication: Basic and Digest Access Authentication" [RFC2617] and the related fields and status codes previously defined in "Hypertext Transfer Protocol – HTTP/1.1" [RFC2616].

HTTP 提供了一个通用的访问控制和身份验证框架，经由一个可扩展的质询-作答challenge-response身份验证方案的集合，服务器可以使用这种身份验证方案对客户端的请求进行质询，而客户端可以使用这种谁方案来向服务器提供身份验证信息。本文档依据《超文本传输协议（HTTP/1.1）：消息与路由》【RFC7230】所定义的架构来定义了 HTTP/1.1 的身份验证，包括：之前在《HTTP 身份验证：基础与数字访问身份验证》【RFC2617】有所描述的通用框架，以及之前在《超文本传输协议——HTTP/1.1》【RFC2616】所定义的相关的字段和状态码。

The IANA Authentication Scheme Registry (Section 5.1) lists registered authentication schemes and their corresponding specifications, including the "basic" and "digest" authentication schemes previously defined by RFC 2617.

IANA 身份验证方案登记表（章节 5.1）列出了已登记的身份验证方案及其对应的规范，包括之前由 RFC 2617 所定义的 "basic" 和 "digest" 身份验证方案。

1.1. 一致性和错误处理 / Conformance and Error Handling

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

本文档中的关键词 必须MUST、禁止MUST NOT、要求REQUIRED、必须SHALL、禁止SHALL NOT、应当SHOULD、不应当SHOULD NOT、推荐RECOMMENDED、可以MAY 和 可选OPTIONAL 的意义与【RFC2119】一致。

Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

关于错误处理的一致性标准以及注意事项已在【RFC7230】章节 2.5 中定义了。

1.2. 句法标记 / Syntax Notation

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix B describes rules imported from other documents. Appendix C shows the collected grammar with all list operators expanded to standard ABNF notation.

本规范使用了扩展巴科斯范式Augmented Backus-Naur Form（ABNF）标记法【RFC5234】，另外，出于定义的紧凑性的考虑，本规范对 ABNF 规则进行了扩展（见章节 7），允许使用一个 # 操作符（类似于 * 操作符，指代“重复”）来定义一种以逗号分隔的列表。附录 B 描述了从其他文档中引进的规则。附录 C 展示了所有已收集的包含列表扩展规则以及标准 ABNF 标记的语法。

2. 访问身份验证框架 / Access Authentication Framework

2.1. 质询和作答 / Challenge and Response

HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.

HTTP 提供了一种简单的质询-作答challenge-response身份验证框架，服务器可以使用它来对客户端请求进行质询，而客户端可以使用它来提供身份验证信息。它使用一个不区分大小写的标记token来作为一种标识身份验证方案authentication scheme的方法，这个标记之后紧跟的是通过这种方案来获取身份验证所必要的额外信息。这些额外信息要么是一个以逗号分隔的参数列表，要么是一个可以持有 base64 编码信息的字符序列。

译注：质询-作答，就好比一个答题游戏，主持提问参赛者一个问题，参赛者答对了就可以进入下一个环节，如果答错了就挑战失败了。又好比一个开门暗号，暗号由房间内的人设置，门外的人需要回答这个暗号。也有人将其译为“挑战-响应”。

Authentication parameters are name=value pairs, where the name token is matched case-insensitively, and each parameter name MUST only occur once per challenge.

身份验证参数是 name=value 键值对，其中 name 标记是按不区分大小写的方式来匹配的，并且在每一次质询当中，每个参数名称 必须 仅出现一次。 

  1. auth-scheme    = token
  2.  
  3. auth-param     = token BWS "=" BWS ( token / quoted-string )
  4.  
  5. token68        = 1*( ALPHA / DIGIT /
  6.                      "-" / "." / "_" / "~" / "+" / "/" ) *"="

The token68 syntax allows the 66 unreserved URI characters ([RFC3986]), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, with or without padding, but excluding whitespace ([RFC4648]).

token68 句法允许【RFC3986】所规定的 66 个未保留的 URI 字符，再加上一些其他的字符，以便它能够持有一个 base64、base64url（URL 和文件名安全的字母）、base32、或者 base16 (hex) 编码，带有或者不带有填充字符padding，但是排除空白whitespace（【RFC4648】）。

译注：【RFC3986】中规定的未保留字符共有以下这些： unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

译注：base64 与 base32 编码方案一般使用等号 "=" 作为填充字符。

A 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent, including a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.

源服务器使用一个 401 (Unauthorized) 响应消息来向用户代理质询身份验证，其中带有一个 WWW-Authenticate 头字段包含至少一个适用于所要请求的资源的质询。

A 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client, including a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.

代理使用一个 407 (Proxy Authentication Required) 响应消息来向客户端质询身份验证，其中带有一个 Proxy-Authenticate 头字段包含至少一个适用于代理去请求资源的质询。 

  1. challenge   = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

Note: Many clients fail to parse a challenge that contains an unknown scheme. A workaround for this problem is to list well-supported schemes (such as "basic") first.

注意： 许多客户端无法解析包含一种未知方案的质询。对于这种问题的一种变通方法是先列出良好支持的方案（比如 "basic"）。

A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 (Unauthorized) — can do so by including an Authorization header field with the request.

在接收到一个 401 (Unauthorized) 以后，如果用户代理希望通过源服务器来证明自身身份（通常但并非必然），可以通过在请求中带有一个 Authentication 头字段来达到。

A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) — can do so by including a Proxy-Authorization header field with the request.

在接收到一个 407 (Proxy Authentication Required) 以后，如果用户代理希望通过代理来证明自身身份（通常但并非必然），可以通过在请求中带有一个 Proxy-Authorization 头字段来达到。

Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the user as appropriate. Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 6.1.

Authentication 的字段值和 Proxy-Authorization 字段值都包含有客户端对所要请求的资源领域的凭证，根据（可能在过去的某个时候）接收自一个响应里的一个质询。当创建它们的值的时候，用户代理应该选择其理解的并认为是最安全的那一种 auth-scheme 质询，从用户那里适当地获得凭证。在头字段值里传输凭证意味着底层连接机密性方面的重大安全注意事项，正如章节 6.1 所描述的。 

  1. credentials = auth-scheme [ 1*SP ( token68 / #auth-param ) ]

Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server SHOULD send a 401 (Unauthorized) response that contains a WWW-Authenticate header field with at least one (possibly new) challenge applicable to the requested resource.

如果源服务器接收到一个访问保护资源的请求，一旦这个请求缺少凭证，或者包含有一个无效的凭证（比如，一个错误的密码），或者不完整的凭证（比如，当身份验证方案要求超过一个以上回合的时候），那么，源服务器 应当 发送一个 401 (Unauthorized) 响应，其内包含有一个 WWW-Authenticate 头字段，该字段至少带有一个（可能是新的）适用于所请求的资源的质询。

Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy that requires authentication SHOULD generate a 407 (Proxy Authentication Required) response that contains a Proxy-Authenticate header field with at least one (possibly new) challenge applicable to the proxy.

同样，如果代理接收到一个请求，一旦这个请求缺少代理凭证，或者包含有无效或不完整的代理凭证，那么，要求身份验证的代理 应当 生成一个 407 (Proxy Authentication Required) 响应，其内包含有一个 Proxy-Authenticate 头字段，该字段至少带有一个（可能是新的）适用该代理的质询。

A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code (Section 6.5.3 of [RFC7231]).

服务器接收到有效凭证但并不足以授权其访问资源时，应该回应一个带有 403 (Forbidden) 状态码的响应（【RFC7231】章节 6.5.3）。

HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, such additional mechanisms are not defined by this specification.

HTTP 并没有将对这个简单的质询-作答challenge-response框架上的应用限定为访问身份验证。可以使用其他额外的机制（比如在传输层上的身份验证，或者经由消息封装的身份验证），以及带有额外头字段所指定的身份验证信息。然而，本规范并没有定义这些额外的机制。

2.2. 保护空间（领域） / Protection Space (Realm)

The "realm" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.

realm 是一个保留的身份验证参数，某些身份验证方案authentication schemes如果希望去表明保护范围的话，可以使用它来实现目的。

A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI; see Section 5.5 of [RFC7230]) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different realms.

保护空间protection space是由被访问的服务器的规范化根 URIcanonical root URI（即实际请求 URI 的 scheme 和 authority 组件，见【RFC7230】章节 5.5），并结合 realm 的值（如果有出现的话）来进行定义的。这些领域realms使得在服务器上要保护的各种资源可以划分为一系列的保护空间protection spaces，每一个保护空间都有自己的身份验证方案以及/或者身份验证数据库。realm 的值是一个字符串，通常由源服务器所赋值，可以具有对应身份验证方案所特有的额外语义。需要注意的是，一个响应可以有多个具有相同 auth-scheme 但不同 realm 的质询。

The protection space determines the domain over which credentials can be automatically applied. If a prior request has been authorized, the user agent MAY reuse the same credentials for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preferences (such as a configurable inactivity timeout). Unless specifically allowed by the authentication scheme, a single protection space cannot extend outside the scope of its server.

保护空间决定了哪一种凭证可以被自动执行。某个之前的请求假如已经经过授权，那么，对于这个保护空间内的所有其他请求，用户代理 可以 在一段时间内复用同一个凭证，而这个具体时间为多久，取决于身份验证方案authentication scheme、参数，以及/或者用户的偏好设置（比如一个可配置的闲置超时时间）。除非身份验证方案明确允许，单个保护空间的范围不能超出它的服务器的范围。

For historical reasons, a sender MUST only generate the quoted-string syntax. Recipients might have to support both token and quoted-string syntax for maximum interoperability with existing clients that have been accepting both notations for a long time.

出于历史遗留的原因，发送端 必须 仅生成 quoted-string 句法。而为了最大化与现存的很早就接受两种标记法的客户端的可交互性，接收端可能得同时支持 token 和 quoted-string 两种句法。

3. 状态码定义 / Status Code Definitions

3.1. 401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

401 (Unauthorized) 状态码表明：请求未被执行，因为它缺少目标资源的有效身份验证凭证。服务器在生成一个 401 响应的时候，必须 发送一个 WWW-Authenticate 头字段（章节 4.1），其包含至少一个适用于该目标资源的质询challenge。

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

如果该请求带有身份验证凭证（一个或多个），那么，这个 401 响应表明服务器拒绝授权给这些凭证。用户代理 可以 重新发起这个请求，带有一个新的或者替换过的 Authorization 头字段（章节 4.2）。重新发起请求之后，如果仍然返回的是 401 响应，且响应带有与之前的 401 响应相同的质询，而且用户代理已经试过至少一次身份验证了，那么，用户代理 应当 将响应内的表示形式展示给用户，因为这种响应通常包含有相关的诊断信息。

3.2. 407 Proxy Authentication Required

The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy MUST send a Proxy-Authenticate header field (Section 4.3) containing a challenge applicable to that proxy for the target resource. The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 4.4).

407 (Proxy Authentication Required) 状态码类似于 401 (Unauthorized)，但它表明：为了使用代理，客户端需要证明自身身份。代理 必须 发送一个 Proxy-Authenticate 头字段（章节 4.3），其包含至少一个适用于代理去请求资源的质询。客户端 可以 重新发起这个请求，带有一个新的或者替换过的 Proxy-Authorization 头字段（章节 4.4）。

4. 头字段定义 / Header Field Definitions

This section defines the syntax and semantics of header fields related to the HTTP authentication framework.

本章节定义了 HTTP 身份验证框架相关的头字段的句法和语义。

4.1. WWW-Authenticate

The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.

WWW-Authenticate 头字段指出了适用于目标资源的（一个或多个）身份验证方案及其参数。 

  1. WWW-Authenticate = 1#challenge

A server generating a 401 (Unauthorized) response MUST send a WWW-Authenticate header field containing at least one challenge. A server MAY generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials) might affect the response.

服务器在生成一个 401 (Unauthorized) 响应的时候，必须 发送一个 WWW-Authenticate 头字段，其包含至少一个质询。服务器 可以 在其他响应消息中生成一个 WWW-Authenticate 头字段来表明：提供凭证（或者不同的凭证）可能会响应到这个响应。

A proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response.

代理在转发一个响应的时候，禁止 修改响应里的任何 WWW-Authenticate 字段。

User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur multiple times.

建议用户代理在解析这个头字段值的时候要特别小心，因为它可能包含有超过一个以上的质询，并且每一个质询都能够包含有一个以逗号分隔comma-separated的身份验证参数列表。此外，这个头字段自身还能够在消息中出现多次。

For instance:

例如： 

  1. WWW-Authenticate: Newauth realm="apps", type=1,
  2.                   title="Login to \"apps\"", Basic realm="simple"

This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters "type" and "title", and another one for the "Basic" scheme with a realm value of "simple".

这个头字段包含有两个质询：一个是 "Newauth" 方案，它的领域 realm 为 "apps"，还有两个额外的参数 "type" 和 "title"；另一个是 "Basic" 方案，它的领域 realm 是 "simple"。

Note: The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice, this ambiguity does not affect the semantics of the header field value and thus is harmless.

注意： 质询的语法规则中还使用了列表句法。因此，号号序列、空白、以及逗号可被视为要么执行之前的质询，要么是质询列表中的一个空的条目。实践过程中，这种歧义并不会影响到这个头字段值的语义，因此它是无害的。

4.2. Authorization

The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Authorization 头字段让用户代理可以在（通常但并非必然）接收到一个 401 (Unauthorized) 响应以后，向源服务器证明自身身份。它的值由凭证credentials组成，这些凭证包含有对于被请求资源所在的领域realm的用户代理身份验证信息。 

  1. Authorization = credentials

If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

如果一个请求已经经过身份验证并指定了一个领域realm，那么同一个凭证可假定为有效于在这个领域中的所有其他请求（假设该身份验证方案自身并没有要求其他，比如凭证的值依赖质询的值或者同步时钟的变化而变化）。

A proxy forwarding a request MUST NOT modify any Authorization fields in that request. See Section 3.2 of [RFC7234] for details of and requirements pertaining to handling of the Authorization field by HTTP caches.

代理在转发一个请求的时候 禁止 修改这个请求里的任何 Authorization 字段。关于 HTTP 缓存如何处理 Authorization 字段的相关细节和要求，见【RFC7234】章节 3.2。

4.3. Proxy-Authenticate

The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this effective request URI (Section 5.5 of [RFC7230]). A proxy MUST send at least one Proxy-Authenticate header field in each 407 (Proxy Authentication Required) response that it generates.

Proxy-Authenticate 头字段由至少一个质询组成，这些质询表明这个实际请求 URI（【RFC7230】章节 5.5）的代理所适用的身份验证方案及其参数。代理 必须 在它所生成的每一个 407 (Proxy Authentication) 响应中发送至少一个 Proxy-Authenticate 头字段。 

  1. Proxy-Authenticate = 1#challenge

Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate network, it is common for credentials to be generated by the user agent and passed through the hierarchy until consumed. Hence, in such a configuration, it will appear as if Proxy-Authenticate is being forwarded because each proxy will send the same challenge set.

不同于 WWW-Authenticate，Proxy-Authenticate 头字段只适用于响应链路中的下一个出站客户端outbound client。那是因为只有选择某个给定代理的那个客户才有可能有身份验证所必要的凭证。但是，当在同一个管理域内使用了多个代理的话，比如在一个大的企业网络内的办公室或区域性缓存代理，常常会见到用户代理生成凭证并将它在层次结构中传递直到它被使用。因此，在这种配置中，它看起来就像 Proxy-Authenticate 被转发了，因为每个代理将会发送同一个质询集合。

Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 4.1 for details.

需要注意的是，WWW-Authenticate 相关的解析注意事项parsing considerations同样也适用于本头字段，详细信息见章节 4.1。

4.4. Proxy-Authorization

The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication. Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the resource being requested.

Proxy-Authorization 头字段让客户可以向要求身份验证的代理验证自身（或它的用户）。它的值由凭证组成，每个凭证包含有客户端的身份验证信息，以及/或者被请求资源的领域realm。 

  1. Proxy-Authorization = credentials

Unlike Authorization, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.

不同于 Authorization，Proxy-Authorization 头字段只适用于响应链路中的下一个入站代理（其使用 Proxy-Authenticate 字段来要求身份验证）。当在一个链路中使用了多个代理，Proxy-Authorization 头字段由第一个期望接收凭证的入站代理所使用。代理 可以 将客户端请求里的凭证中转relay到下一个代理中，如果这是这些代理的合作验证一个给定的请求的机制的话。

5. IANA 注意事项 / IANA Considerations

5.1. 身份验证方案登记表 / Authentication Scheme Registry

The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and credentials. It has been created and is now maintained at http://www.iana.org/assignments/http-authschemes.

《HTTP 身份验证方案登记表》定义了质询和凭证方面的身份验证方案的命名空间，这份登记表已经创建，目前维护在 http://www.iana.org/assignments/http-authschemes。

5.1.1. 手续 / Procedure

Registrations MUST include the following fields:

  • Authentication Scheme Name
  • Pointer to specification text
  • Notes (optional)

登记条目 必须 包括以下字段：

  • 身份验证方案的名称
  • 指向到规范文本的引用
  • 备注（可选）

Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).

添加到 HTTP 状态码命名空间的值要求由 IETF 复审（见【RFC5226】章节 4.1）。

5.1.2. 新的身份验证方案的注意事项 / Considerations for New Authentication Schemes

There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:

  • HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 2.3 of [RFC7230]).
  • The authentication parameter "realm" is reserved for defining protection spaces as described in Section 2.2. New schemes MUST NOT use it in a way incompatible with that definition.
  • The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.

  • The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes.

    Note: The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be repeated for new parameters.

  • Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification" or "use this registry").
  • Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/or proxy authentication (i.e., using Proxy-Authenticate).

  • The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" Cache-Control response directive (Section 5.2.2.6 of [RFC7234]), within the scope of the request in which they appear.

    Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives (e.g., "no-store", Section 5.2.1.5 of [RFC7234]) or response directives (e.g., "private").

HTTP 身份验证框架的某些方面会对新的身份验证方案是否可行进行了约束：

  • HTTP 身份验证假定是无状态的，即验证一个请求的所有必要的信息 必须 提供在该请求当中，而不是依赖服务器记住之前的请求。身份验证基于或受限于底层连接方面的内容已超出本规范的范畴，以及除非采取措施来确保连接不能够被非验证的用户所使用，否则本质上是有缺陷的（见【RFC7230】章节 2.3）。
  • 身份验证参数 realm 是用作定义保护空间（章节 2.2）而保留的。新的方案 禁止 以其定义不相容的方式来使用这个参数。
  • token68 标记的引入是为了兼容目前已存在的身份验证方案，在每一个质询或凭证当中它只能使用一次。所以，新的方案应该使用 auth-param 句法来替代，否则将来不可能再扩展。
  • 对质询和凭证的解析是由本规范所定义的，新的身份验证方案不能够更改它。当使用了 auth-param 句法，所有参数应该都支持 token 和 quoted-string 两种句法，并且句法上的约束应该定义在解析后的字段值上（也就是说，quoted-string 处理）。为了接收端能够使用通用的解析器来应用到所有身份验证方案当中，这是非常必要的。 注意： 事实上将 realm 参数的值的句法限制为 quoted-string 确实是一个糟糕的设计选择，不应该在新的参数再重复使用这种设计。
  • 定义新方案时应该定义对未知的扩展参数的处置方式。通常情况下，“必须忽略must-ignore”的规则的优先级要高于“必须理解must-understand”的规则，否则的话在遗留的旧接收端面前引入新参数时将变得非常困难。还有，最好描述一下定义新参数的策略（比如“更新规范”或者“使用这个条目”）。
  • 身份验证方案需要注明它们是否可以用于源服务器的身份验证origin-server authentication（即，使用 WWW-Authenticate），以及/或者代理身份验证proxy authentication（即，使用 Proxy-Authenticate）。
  • Authorization 头字段所装载的凭证是特定于用户代理的，因此，与作为 "private" 的 Cache-Control 响应指令的 HTTP 缓存具有相同的效果，在它们出现的请求范围内。 所以，选择不在 Authorization 头字段中装载凭证（比如，使用一个新定义的头字段来装载）的那些新身份验证方案将需要显式地禁用缓存，可以通过使用 Cache-Control 请求指令（比如，"no-store"，【RFC7234】章节 5.2.1.5）或者响应指令（比如，"private"）。

5.2. 状态码登记表 / Status Code Registration

The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located at http://www.iana.org/assignments/http-status-codes has been updated with the registrations below:

《超文本传输协议（HTTP）状态码登记表》位于 http://www.iana.org/assignments/http-status-codes，已经更新了以下登记项。

Value Description Reference
401 Unauthorized Section 3.1
407 Proxy Authentication Required Section 3.2

5.3. 头字段登记表 / Header Field Registration

HTTP header fields are registered within the "Message Headers" registry maintained at http://www.iana.org/assignments/message-headers/.

HTTP 头字段被登记在《消息头部》登记表中，并维护在 http://www.iana.org/assignments/message-headers/。

This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]).

本文档定义了以下 HTTP 头字段，因此它们相关联的登记项已经根据以下永久登记条目进行更新（见【BCP90】）：

Header Field Name Protocol Status Reference
Authorization http standard Section 4.2
Proxy-Authenticate http standard Section 4.3
Proxy-Authorization http standard Section 4.4
WWW-Authenticate http standard Section 4.1

The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

主管以上条目的变更的是 "IETF (iesg@ietf.org) - Internet Engineering Task Force"。

6. 安全注意事项 / Security Considerations

This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP authentication. More general security considerations are addressed in HTTP messaging [RFC7230] and semantics [RFC7231].

本章节是为了告诉开发者、信息提供商、以及用户，HTTP 身份验证相关的安全注意事项。《消息句法和路由》【RFC7230】以及《语义和内容》【RFC7231】有更广泛的安全注意事项。

Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.

所有关于 HTTP 身份验证的话题可以概括为一种安全性的考虑，因此，下文中所列举的注意事项并不能囊括所有。再者，下文仅讨论身份验证框架authentication framework相关的宏观安全注意事项，而不是针对具体的身份验证方案specific authentication schemes来讨论其所有潜在的风险（这应该由定义该方案的规范文档来记录）。网络应用安全性相关（包括实现或者实践使用某种身份验证方案时常见的陷阱）的最新研究的专题信息和链接由许多组织共同维护（比如，【OWASP】）。

6.1. 证书凭证的保密性 / Confidentiality of Credentials

The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying that user even if the content within credentials remains confidential.

HTTP 身份验证框架并没不是定义一种单一的机制来维护证书凭证的机密性，而是由每一种身份验证方案自己来定义证书凭证在传输之前是如何编码的。默认这种设计为未来开发新的身份验证方案提供了灵活性，但是，对于现有的自身没有设计保密机制的方案（或者没有足够能力对抗重放攻击replay attack的那些方案）来说，它并不能提供足够的保护。再者，如果服务器要求每一个独立用户都有专门的证书凭证，那么，在交换证书凭证的过程中，用户可能会因此被唯一标识出，即使证书的内容仍然具有保密性。

译注：重放攻击可看百度百科对它的解释。

HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of header fields. In other words, if a server limits access to authenticated users using this framework, the server needs to ensure that the connection is properly secured in accordance with the nature of the authentication scheme used. For example, services that depend on individual user authentication often require a connection to be secured with TLS ("Transport Layer Security", [RFC5246]) prior to exchanging any credentials.

HTTP 依赖以 transport- 为前缀的安全属性或者会话级别的连接session-level connection来为头字段提供保密传输。也就是说，如果一个服务器限制了对使用本框架的已验证用户的访问，服务器需要确保连接的安全性与所使用身份验证方案的性质一致。例如，依赖独立用户身份验证的服务通常会要求在交换任何证书凭证之前，使用 TLS 连接（"Transport Layer Security"，【RFC5246】）。

6.2. 身份验证证书凭证和空闲客户端 / Authentication Credentials and Idle Clients

Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.

现有的 HTTP 客户端和用户代理常常会无限期保留身份验证信息。HTTP 并没有提供任何机制来让源服务器去引导客户端丢弃那些缓存过的证书凭证，这是因为协议本身并不清楚用户代理是如何获得或者管理证书凭证的。对证书凭证的过期或者撤销机制可以作为一种身份验证方案定义的一部分。

Circumstances under which credential caching can interfere with the application's security model include but are not limited to:

  • Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.
  • Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.

以下证书凭证的缓存行为会妨碍到应用程序的安全模型，包括但不限于：

  • 客户端已经闲置了很长一段时间，随后服务器可能希望让客户端对用户重新认证。
  • 应用程序包含一种会话终止的指令（比如页面中的“退出登录”或者“提交”按钮），之后服务端程序“知道”客户端不再有保留证书凭证的必要了。

User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.

鼓励用户代理在缓存证书凭证的同时，可以提供一种便捷的撤销证书凭证的机制给到用户来控制。

6.3. 保护空间 / Protection Spaces

Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the same authentication credentials for other resources on the same origin server. This makes it possible for a different resource to harvest authentication credentials for other resources.

如果身份验证方案仅仅依靠 "realm" 机制来建立保持空间，那么证书凭证会暴露给源服务器里的所有资源当中。客户端向某一个资源发起身份验证请求成功以后，就可以使用同一个身份验证凭证访问同一个源服务器里的其他资源。这样使得一个不同的资源来收割其他资源的身份验证凭证成为可能。

This is of particular concern when an origin server hosts resources for multiple parties under the same canonical root URI (Section 2.2). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and separating protection spaces by using a different host name (or port number) for each party.

当一个源服务器在同一个规范化根 URIcanonical root URI （章节 2.2）上为多个团体托管资源的时候，上述这种现象更值得重视。可以缓解上述问题的策略包括：限制直接访问身份验证凭证（也就是说，不要公开 Authorization 请求头字段），以及为每一个团体分配一个不同的主机名称（或者端口号）来分隔保护空间。

7. 鸣谢 / Acknowledgments

This specification takes over the definition of the HTTP Authentication Framework, previously defined in RFC 2617. We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that specification. See Section 6 of [RFC2617] for further acknowledgements.

See Section 10 of [RFC7230] for the Acknowledgments related to this document revision.

8. 参考资料 / References

8.1. 规范性参考资料 / Normative References

  • [RFC2119]
  • Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
  • [RFC5234]
  • Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, January 2008.
  • [RFC7230]
  • Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, June 2014.
  • [RFC7231]
  • Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, June 2014.
  • [RFC7234]
  • Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, June 2014.

8.2. 信息性参考资料 / Informative References

  • [BCP90]
  • Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004.
  • [OWASP]
  • van der Stock, A., Ed., “A Guide to Building Secure Web Applications and Web Services”, The Open Web Application Security Project (OWASP) 2.0.1, July 2005, https://www.owasp.org/.
  • [RFC2616]
  • Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol – HTTP/1.1”, RFC 2616, June 1999.
  • [RFC2617]
  • Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication”, RFC 2617, June 1999.
  • [RFC3986]
  • Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax”, STD 66, RFC 3986, January 2005.
  • [RFC4648]
  • Josefsson, S., “The Base16, Base32, and Base64 Data Encodings”, RFC 4648, October 2006.
  • [RFC5226]
  • Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.
  • [RFC5246]
  • Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, August 2008.

附录 A：相对 RFC 2616 和 2617 的变化 / Appendix A. Changes from RFCs 2616 and 2617

The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.

HTTP 身份验证框架现在由本文档所定义，不再是 RFC 2617。

The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth parameters. (Section 2)

realm 参数不再总是要求无质询，因此，它的 ABNF 规则允许在没有任何 auth 参数的情况下的 challenges。（章节2）

The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". (Section 2)

为了与遗留的身份验证方案（比如，"Basic"）一致，添加了替换 auth-param 列表的 "token68"。（章节2）

This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes. (Section 5.1)

本规范引进了身份验证方案登记表，以及对于新的身份验证方案的注意事项。

附录 B：引进的 ABNF / Appendix B. Imported ABNF

The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).

本规范引用了以下定义在【RFC5234】附录 B.1 中的核心规则：ALPHA （字母）、CR （回车符）、CRLF （回车换行符）、CTL （控制字符）、DIGIT （十进制数字 0-9）、DQUOTE （双引号）、HEXDIG （十六进制数字 0-9/A-F/a-f）、HTAB （水平制表符）、LF （换行符）、OCTET （八位组字节）、SP （空白）以及 VCHAR （【USASCII】可见字符）。

The rules below are defined in [RFC7230]:

以下规则定义在【RFC7230】中： 

  1. BWS           = <BWS, see [RFC7230], Section 3.2.3>
  2. OWS           = <OWS, see [RFC7230], Section 3.2.3>
  3. quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
  4. token         = <token, see [RFC7230], Section 3.2.6>

附录 C：ABNF 集合 / Appendix C. Collected ABNF

In the collected ABNF below, list rules are expanded as per Section 1.2 of [RFC7230].

下列 ABNF 规则集合中，列表规则是在【RFC7230】章节 1.2 所扩充的。 

  1. Authorization = credentials
  2.  
  3. BWS = <BWS, see [RFC7230], Section 3.2.3>
  4.  
  5. OWS = <OWS, see [RFC7230], Section 3.2.3>
  6.  
  7. Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
  8.  challenge ] )
  9. Proxy-Authorization = credentials
  10.  
  11. WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
  12.  ] )
  13.  
  14. auth-param = token BWS "=" BWS ( token / quoted-string )
  15. auth-scheme = token
  16.  
  17. challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
  18.  OWS "," [ OWS auth-param ] ) ] ) ]
  19. credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
  20.  *( OWS "," [ OWS auth-param ] ) ] ) ]
  21.  
  22. quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
  23.  
  24. token = <token, see [RFC7230], Section 3.2.6>
  25. token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
  26.  *"="

索引 / Index

Authors' Addresses

  1. Roy T. Fielding (editor)
  2. Adobe Systems Incorporated
  3. 345 Park Ave
  4. San Jose, CA 95110
  5. USA
  6. Email: fielding@gbiv.com
  7. URI: http://roy.gbiv.com/
  1. Julian F. Reschke (editor)
  2. greenbytes GmbH
  3. Hafenweg 16
  4. Muenster, NW 48155
  5. Germany
  6. Email: julian.reschke@greenbytes.de
  7. URI: http://greenbytes.de/tech/webdav/
  1. 阿多（译者）