Skip to main content

RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication

Published (发布日期): June 2014
Status (状态): Standards Track
Authors (作者): R. Fielding (Ed., Adobe), J. Reschke (Ed., greenbytes)
Obsoletes (废弃): RFC 2616
Updates (更新): RFC 2617

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)是一个用于分布式、协作式超媒体信息系统的无状态应用层协议。本文档定义了HTTP认证框架。

Table of Contents (目录)​

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通过一组可扩展的质询-响应认证方案,提供了一个通用的访问控制和认证框架。服务器可以使用该框架质询客户端请求,客户端可以使用该框架提供认证信息。本文档根据"超文本传输协议(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.

本规范使用[RFC5234]的增强巴科斯-诺尔范式(ABNF)标记,并带有[RFC7230]第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提供了一个简单的质询-响应认证框架,服务器可以用它来质询客户端请求,客户端可以用它来提供认证信息。它使用不区分大小写的token作为标识认证方案的手段,后面跟着通过该方案实现认证所需的附加信息。后者可以是逗号分隔的参数列表,也可以是能够保存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 token不区分大小写匹配,并且每个参数名在每个质询中必须只出现一次。

auth-scheme = token

auth-param = token BWS "=" BWS ( token / quoted-string )

token68 = 1*( ALPHA / DIGIT /
             "-" / "." / "_" / "~" / "+" / "/" ) *"="

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语法允许66个未保留的URI字符([RFC3986])加上一些其他字符,因此它可以保存base64、base64url(URL和文件名安全字母表)、base32或base16(十六进制)编码,带或不带填充,但不包括空白字符([RFC4648])。

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头字段,其中包含至少一个适用于代理的质询,用于请求的资源。

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)之后 -- 可以通过在请求中包含Authorization头字段来实现。

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.

Authorization字段值和Proxy-Authorization字段值都包含客户端对请求资源的realm的凭证,基于在响应中收到的质询(可能在过去的某个时刻)。在创建它们的值时,用户代理应该通过选择它认为最安全且能理解的auth-scheme的质询来实现,并根据需要从用户获取凭证。在头字段值中传输凭证涉及关于底层连接机密性的重要安全考虑,如第6.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不限制应用程序仅使用此简单的质询-响应框架进行访问认证。可以使用其他机制,例如在传输层或通过消息封装进行认证,以及使用指定认证信息的额外头字段。但是,本规范不定义此类额外机制。

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"认证参数保留给希望指示保护范围的认证方案使用。

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.

保护空间由被访问服务器的规范根URI(有效请求URI的scheme和authority组件; 参见[RFC7230]的第5.5节)定义,如果存在realm值,则与realm值组合。这些realm允许服务器上的受保护资源被划分为一组保护空间,每个保护空间都有自己的认证方案和/或授权数据库。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.

保护空间确定可以自动应用凭证的域。如果先前的请求已被授权,用户代理可以在该保护空间内的所有其他请求中重用相同的凭证,持续时间由认证方案、参数和/或用户偏好(如可配置的不活动超时)确定。除非认证方案特别允许,否则单个保护空间不能扩展到其服务器范围之外。

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节),其中包含至少一个适用于目标资源的质询。

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响应包含与先前响应相同的质询,并且用户代理已经至少尝试过一次认证,则用户代理应该向用户呈现封闭的表示,因为它通常包含相关的诊断信息。

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"头字段指示适用于目标资源的认证方案和参数。

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.

建议用户代理在解析字段值时特别小心,因为它可能包含多个质询,并且每个质询可以包含逗号分隔的认证参数列表。此外,头字段本身可以多次出现。

For instance:

例如:

WWW-Authenticate: Newauth realm="apps", type=1,
                  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)响应之后。其值由包含请求资源realm的用户代理认证信息的凭证组成。

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,则假定相同的凭证对该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 Required)响应中发送至少一个Proxy-Authenticate头字段。

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头字段仅适用于响应链上的下一个出站客户端。这是因为只有选择给定代理的客户端才可能拥有认证所需的凭证。但是,当在同一管理域内使用多个代理时,例如大型企业网络中的办公室和区域缓存代理,用户代理通常会生成凭证并通过层次结构传递直到被消费。因此,在这种配置中,看起来好像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的解析考虑也适用于此头字段; 有关详细信息,请参见第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的客户端认证信息的凭证组成。

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头字段由期望接收凭证的第一个入站代理消费。如果这是代理协作认证给定请求的机制,则代理可以将凭证从客户端请求中继到下一个代理。

5. 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).

要添加到此命名空间的值需要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认证框架的某些方面对新认证方案的工作方式施加了约束:

  • 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]).

  • HTTP认证被假定为无状态的: 认证请求所需的所有信息必须在请求中提供,而不是依赖于服务器记住先前的请求。基于或绑定到底层连接的认证超出了本规范的范围,并且本质上存在缺陷,除非采取措施确保连接不能被除认证用户之外的任何一方使用(参见[RFC7230]的第2.3节)。

  • 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.

  • 认证参数"realm"保留用于定义第2.2节中描述的保护空间。新方案不得以与该定义不兼容的方式使用它。

  • 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.

  • "token68"表示法是为了与现有认证方案兼容而引入的,每个质询或凭证只能使用一次。因此,新方案应该使用auth-param语法,否则将来的扩展将不可能。

  • 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.

  • 质询和凭证的解析由本规范定义,不能被新认证方案修改。当使用auth-param语法时,所有参数都应该支持token和quoted-string语法,并且应该在解析后(即quoted-string处理)对字段值定义语法约束。这是必要的,以便接收方可以使用适用于所有认证方案的通用解析器。

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.

注意: "realm"参数的值语法限制为quoted-string这一事实是一个糟糕的设计选择,不应在新参数中重复。

  • 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).

  • 认证方案需要记录它们是否可用于源服务器认证(即使用WWW-Authenticate)和/或代理认证(即使用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.

  • Authorization头字段中携带的凭证特定于用户代理,因此在它们出现的请求范围内,对HTTP缓存具有与"private" Cache-Control响应指令([RFC7234]的第5.2.2.6节)相同的效果。

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").

因此,选择不在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://www.iana.org/assignments/http-status-codes的"超文本传输协议(HTTP)状态码注册表"已使用以下注册进行更新:

ValueDescriptionReference
401UnauthorizedSection 3.1
407Proxy Authentication RequiredSection 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 NameProtocolStatusReference
AuthorizationhttpstandardSection 4.2
Proxy-AuthenticatehttpstandardSection 4.3
Proxy-AuthorizationhttpstandardSection 4.4
WWW-AuthenticatehttpstandardSection 4.1

The change controller is: "IETF ([email protected]) - Internet Engineering Task Force".

变更控制者是: "IETF ([email protected]) - 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认证的已知安全问题。更一般的安全考虑在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认证主题的一切都是安全考虑,因此下面的考虑列表并非详尽无遗。此外,它仅限于关于认证框架的一般安全考虑,而不是讨论特定认证方案的所有潜在考虑(这些应该在定义这些方案的规范中记录)。各种组织维护有关Web应用程序安全性的主题信息和当前研究的链接(例如[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认证框架没有定义维护凭证机密性的单一机制; 相反,每个认证方案定义凭证在传输前如何编码。虽然这为未来认证方案的开发提供了灵活性,但对于本身不提供机密性或不能充分防止重放攻击的现有方案的保护来说是不够的。此外,如果服务器期望特定于每个单独用户的凭证,则即使凭证中的内容保持机密,这些凭证的交换也将具有识别该用户的效果。

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依赖于底层传输或会话级连接的安全属性来提供头字段的机密传输。换句话说,如果服务器使用此框架限制对认证用户的访问,则服务器需要确保根据所使用的认证方案的性质正确地保护连接。例如,依赖于单个用户认证的服务通常要求在交换任何凭证之前使用TLS("传输层安全",[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.

  • 包含会话终止指示(例如页面上的"logout"或"commit"按钮)的应用程序,之后应用程序的服务器端"知道"客户端没有进一步保留凭证的理由。

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.

当源服务器在同一规范根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.

本规范接管了先前在RFC 2617中定义的HTTP认证框架的定义。我们感谢John Franks、Phillip M. Hallam-Baker、Jeffery L. Hostetler、Scott D. Lawrence、Paul J. Leach、Ari Luotonen和Lawrence C. Stewart在该规范上的工作。有关进一步的致谢,请参见[RFC2617]的第6节。

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

有关本文档修订的致谢,请参见[RFC7230]的第10节。

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, http://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.

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参数的质询。(第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)

本规范引入了认证方案注册表,以及新认证方案的考虑事项。(第5.1节)

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(CR LF)、CTL(控制字符)、DIGIT(十进制0-9)、DQUOTE(双引号)、HEXDIG(十六进制0-9/A-F/a-f)、LF(换行)、OCTET(任何8位数据序列)、SP(空格)和VCHAR(任何可见的US-ASCII字符)。

The rules below are defined in [RFC7230]:

以下规则在[RFC7230]中定义:

BWS = <BWS, see [RFC7230], Section 3.2>
OWS = <OWS, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2>
token = <token, see [RFC7230], Section 3.2>

Appendix C. Collected ABNF​

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

在下面收集的ABNF中,列表规则按照[RFC7230]第1.2节进行扩展。

Authorization = credentials

BWS = <BWS, see [RFC7230], Section 3.2>

OWS = <OWS, see [RFC7230], Section 3.2>

Proxy-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS
 challenge ] )
Proxy-Authorization = credentials

WWW-Authenticate = *( "," OWS ) challenge *( OWS "," [ OWS challenge
 ] )

auth-param = token BWS "=" BWS ( token / quoted-string )
auth-scheme = token

challenge = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param ) *(
 OWS "," [ OWS auth-param ] ) ] ) ]
credentials = auth-scheme [ 1*SP ( token68 / [ ( "," / auth-param )
 *( OWS "," [ OWS auth-param ] ) ] ) ]

quoted-string = <quoted-string, see [RFC7230], Section 3.2>

token = <token, see [RFC7230], Section 3.2>
token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" )
 *"="

Index (索引)​

4​

  • 401 Unauthorized (status code) - Section 3.1
  • 407 Proxy Authentication Required (status code) - Section 3.2

A​

  • Authorization header field - Section 4.2

C​

  • Canonical Root URI - Section 2.2

G​

  • Grammar:
    • auth-param - Section 2.1
    • auth-scheme - Section 2.1
    • Authorization - Section 4.2
    • challenge - Section 2.1
    • credentials - Section 2.1
    • Proxy-Authenticate - Section 4.3
    • Proxy-Authorization - Section 4.4
    • token68 - Section 2.1
    • WWW-Authenticate - Section 4.1

P​

  • Protection Space - Section 2.2
  • Proxy-Authenticate header field - Section 4.3
  • Proxy-Authorization header field - Section 4.4

R​

  • Realm - Section 2.2

W​

  • WWW-Authenticate header field - Section 4.1

Authors' Addresses (作者地址)​

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA

Email: [email protected]
URI: http://roy.gbiv.com/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany

Email: [email protected]
URI: http://greenbytes.de/tech/webdav/

Copyright (c) 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.

HTTP/1.1 Specification Series (HTTP/1.1规范系列)​

RFC 7235 is part of the HTTP/1.1 specification series:

  1. RFC 7230 - Message Syntax and Routing (消息语法与路由)
  2. RFC 7231 - Semantics and Content (语义与内容)
  3. RFC 7232 - Conditional Requests (条件请求)
  4. RFC 7233 - Range Requests (范围请求)
  5. RFC 7234 - Caching (缓存)
  6. RFC 7235 - Authentication (认证) ← This Document