11. HTTP Authentication (HTTP认证)

11.1. Authentication Scheme (认证方案)

HTTP通过一组可扩展的质询-响应认证方案为访问控制和认证提供了通用框架,服务器可以使用该框架来质询客户端请求,客户端可以使用该框架来提供认证信息. 它使用不区分大小写的令牌来标识认证方案:

auth-scheme    = token

除了通用框架外,本文档不指定任何认证方案. 新的和现有的认证方案独立指定,并且应该在"超文本传输协议(HTTP)认证方案注册表"中注册. 例如,"basic"和"digest"认证方案分别由[RFC7617]和[RFC7616]定义.

11.2. Authentication Parameters (认证参数)

认证方案后面跟着通过该方案实现认证所需的附加信息,可以是逗号分隔的参数列表或能够保存base64编码信息的单个字符序列.

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

token68语法允许66个未保留的URI字符([URI]),加上其他一些字符,因此它可以保存base64,base64url(URL和文件名安全字母表),base32或base16(十六进制)编码,有或没有填充,但不包括空格([RFC4648]).

认证参数是名称/值对,其中名称令牌不区分大小写匹配,并且每个参数名称在每个质询中只能出现一次.

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

参数值可以表示为"token"或"quoted-string"(第5.6节). 认证方案定义需要接受两种表示法,对于发送者和接收者都是如此,以允许接收者使用通用解析组件,而不管认证方案如何.

为了向后兼容,认证方案定义可以将发送者的格式限制为两种变体之一. 当已知已部署的实现在遇到两种格式之一时会失败时,这可能很重要.

11.3. Challenge and Response (质询和响应)

源服务器使用401(Unauthorized)响应消息来质询用户代理的授权,包括至少包含一个适用于所请求资源的质询的WWW-Authenticate头部字段.

代理使用407(Proxy Authentication Required)响应消息来质询客户端的授权,包括至少包含一个适用于所请求资源的代理的质询的Proxy-Authenticate头部字段.

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

注意: 许多客户端无法解析包含未知方案的质询. 解决此问题的方法是首先列出支持良好的方案(例如"basic").

希望向源服务器认证自己的用户代理——通常但不一定是在接收到401(Unauthorized)之后——可以通过在请求中包含Authorization头部字段来这样做.

希望向代理认证自己的客户端——通常但不一定是在接收到407(Proxy Authentication Required)之后——可以通过在请求中包含Proxy-Authorization头部字段来这样做.

11.4. Credentials (凭据)

Authorization字段值和Proxy-Authorization字段值都包含客户端对所请求资源的领域的凭据,基于在响应中接收到的质询(可能在过去的某个时间点). 在创建它们的值时,用户代理应该通过选择它认为最安全的auth-scheme的质询来这样做,并根据需要从用户那里获取凭据. 在头部字段值中传输凭据意味着有关底层连接的机密性的重大安全考虑,如第17.16.1节所述.

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

在接收到省略凭据,包含无效凭据(例如,错误的密码)或部分凭据(例如,当认证方案需要多次往返时)的受保护资源的请求时,源服务器应该 (SHOULD) 发送401(Unauthorized)响应,其中包含至少包含一个(可能是新的)适用于所请求资源的质询的WWW-Authenticate头部字段.

同样,在接收到省略代理凭据或包含无效或部分代理凭据的请求时,需要认证的代理应该 (SHOULD) 生成407(Proxy Authentication Required)响应,其中包含至少包含一个(可能是新的)适用于代理的质询的Proxy-Authenticate头部字段.

接收到有效但不足以获得访问权限的凭据的服务器应该以403(Forbidden)状态码响应(第15.5.4节).

HTTP不限制应用程序使用这个简单的质询-响应框架进行访问认证. 可以使用其他机制,例如在传输层的认证或通过消息封装,以及指定认证信息的附加头部字段. 然而,本规范未定义此类附加机制.

请注意,各种自定义用户认证机制使用[COOKIE]中定义的Set-Cookie和Cookie头部字段来传递与认证相关的令牌.

11.5. Establishing a Protection Space (Realm) (建立保护空间(领域))

"realm"认证参数保留供希望指示保护范围的认证方案使用.

"保护空间" (protection space) 由正在访问的服务器的源(参见第4.3.1节)与领域值(如果存在)的组合定义. 这些领域允许服务器上的受保护资源被划分为一组保护空间,每个空间都有自己的认证方案和/或授权数据库. 领域值是一个字符串,通常由源服务器分配,可以具有特定于认证方案的附加语义. 请注意,响应可以具有多个具有相同auth-scheme但具有不同领域的质询.

保护空间确定可以自动应用凭据的域. 如果先前的请求已被授权,则用户代理可以 (MAY) 在由认证方案,参数和/或用户首选项(例如可配置的不活动超时)确定的一段时间内为该保护空间内的所有其他请求重用相同的凭据.

保护空间的范围,因此可能自动应用凭据的请求,对于客户端来说不一定是已知的,除非有附加信息. 认证方案可能定义描述保护空间范围的参数. 除非认证方案特别允许,否则单个保护空间不能扩展到其服务器范围之外.

由于历史原因,发送者必须 (MUST) 仅生成quoted-string语法. 接收者可能必须支持token和quoted-string语法,以实现与长期接受两种表示法的现有客户端的最大互操作性.

11.6. Authenticating Users to Origin Servers (向源服务器认证用户)

11.6.1. WWW-Authenticate

"WWW-Authenticate"响应头部字段指示适用于目标资源的认证方案和参数.

WWW-Authenticate = #challenge

生成401(Unauthorized)响应的服务器必须 (MUST) 发送包含至少一个质询的WWW-Authenticate头部字段. 服务器可以 (MAY) 在其他响应消息中生成WWW-Authenticate头部字段,以指示提供凭据(或不同的凭据)可能会影响响应.

转发响应的代理不得 (MUST NOT) 修改该响应中的任何WWW-Authenticate头部字段.

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

例如:

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

此头部字段包含两个质询,一个用于"Basic"方案,领域值为"simple",另一个用于"Newauth"方案,领域值为"apps". 它还包含两个附加参数,"type"和"title".

然而,一些用户代理无法识别这种形式. 因此,在同一字段行上发送具有多个成员的WWW-Authenticate字段值可能无法互操作.

注意: 质询语法产生式也使用列表语法. 因此,逗号,空格和逗号的序列可以被认为是应用于前面的质询,或者是质询列表中的空条目. 实际上,这种歧义不会影响头部字段值的语义,因此是无害的.

11.6.2. Authorization

"Authorization"头部字段允许用户代理向源服务器认证自己——通常但不一定是在接收到401(Unauthorized)响应之后. 其值由包含用户代理对所请求资源的领域的认证信息的凭据组成.

Authorization = credentials

如果请求已认证并指定了领域,则假定相同的凭据对该领域内的所有其他请求有效(假设认证方案本身不要求其他方式,例如根据质询值变化的凭据或使用同步时钟).

转发请求的代理不得 (MUST NOT) 修改该请求中的任何Authorization头部字段. 有关HTTP缓存处理Authorization头部字段的详细信息和要求,请参阅[CACHING]的第3.5节.

11.6.3. Authentication-Info

HTTP认证方案可以使用"Authentication-Info"响应字段在客户端的认证凭据被接受后传达信息. 此信息可以包括来自服务器的最终消息(例如,它可以包含服务器认证).

字段值是参数列表(名称/值对),使用第11.3节中定义的"auth-param"语法. 本规范仅描述通用格式; 使用Authentication-Info的认证方案将定义各个参数. 例如,"Digest"认证方案在[RFC7616]的第3.5节中定义了多个参数.

Authentication-Info = #auth-param

Authentication-Info字段可以在任何HTTP响应中使用,与请求方法和状态码无关. 其语义由相应请求的Authorization头部字段(第11.6.2节)指示的认证方案定义.

转发响应的代理不允许以任何方式修改字段值.

当认证方案明确允许时,Authentication-Info可以作为尾部字段(第6.5节)发送.

11.7. Authenticating Clients to Proxies (向代理认证客户端)

11.7.1. Proxy-Authenticate

"Proxy-Authenticate"头部字段由至少一个质询组成,该质询指示适用于此请求的代理的认证方案和参数. 代理必须 (MUST) 在其生成的每个407(Proxy Authentication Required)响应中发送至少一个Proxy-Authenticate头部字段.

Proxy-Authenticate = #challenge

与WWW-Authenticate不同,Proxy-Authenticate头部字段仅适用于响应链上的下一个出站客户端. 这是因为只有选择给定代理的客户端才可能拥有认证所需的凭据. 然而,当在同一管理域内使用多个代理时,例如大型企业网络中的办公室和区域缓存代理,用户代理生成凭据并通过层次结构传递直到被消耗是常见的. 因此,在这样的配置中,看起来好像Proxy-Authenticate正在被转发,因为每个代理将发送相同的质询集.

请注意,WWW-Authenticate的解析考虑也适用于此头部字段; 有关详细信息,请参阅第11.6.1节.

11.7.2. Proxy-Authorization

"Proxy-Authorization"头部字段允许客户端向需要认证的代理标识自己(或其用户). 其值由包含客户端对代理和/或所请求资源的领域的认证信息的凭据组成.

Proxy-Authorization = credentials

与Authorization不同,Proxy-Authorization头部字段仅适用于使用Proxy-Authenticate头部字段要求认证的下一个入站代理. 当在链中使用多个代理时,Proxy-Authorization头部字段由期望接收凭据的第一个入站代理消耗. 如果这是代理协作认证给定请求的机制,则代理可以 (MAY) 将凭据从客户端请求中继到下一个代理.

11.7.3. Proxy-Authentication-Info

"Proxy-Authentication-Info"响应头部字段等同于Authentication-Info,只是它适用于代理认证(第11.3节),并且其语义由相应请求的Proxy-Authorization头部字段(第11.7.2节)指示的认证方案定义:

Proxy-Authentication-Info = #auth-param

然而,与Authentication-Info不同,Proxy-Authentication-Info头部字段仅适用于响应链上的下一个出站客户端. 这是因为只有选择给定代理的客户端才可能拥有认证所需的凭据. 然而,当在同一管理域内使用多个代理时,例如大型企业网络中的办公室和区域缓存代理,用户代理生成凭据并通过层次结构传递直到被消耗是常见的. 因此,在这样的配置中,看起来好像Proxy-Authentication-Info正在被转发,因为每个代理将发送相同的字段值.

当认证方案明确允许时,Proxy-Authentication-Info可以作为尾部字段(第6.5节)发送.