HTTP/1.1 — 認証

1.1. 適合性, ~errorの取扱い

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ 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].

適合性の判定基準, および ~errorの取扱いに関する考慮点は、 `7230-2.5$rfc にて定義される。 ◎ Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].

1.2. 構文の表記法

【 この節の他の内容は、 `~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$に移譲。 】

`総集的~ABNF＠~723Xabnf#abnf-7235$ にて、他の文書から取込まれた規則, および すべての`~list演算子$を標準な~ABNF表記法に展開した，総集的な文法を示す。 ◎ 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.

2.1. ~challengeと応答

`auth-scheme@p
	= `token$p

`auth-param@p
	= `token$p `BWS$p "=" `BWS$p ( `token$p / `quoted-string$p )

`token68@p
	= 1*( `ALPHA$P / `DIGIT$P /
	      "-" / "." / "_" / "~" / "+" / "/" ) *"="

`token68$p 構文は、 66 個の非~予約-済み~URI文字（ `3986-2.3$rfc ）に加えて，空白~以外の少数の文字も許容する — 次に挙げる符号化法 `4648$R を，~paddingの有無も込みで保持できるようにするための ⇒＃ `base64$, `base64url$ （ URL や~filenameに用いても安全な~alphabet）, `base32$, `base16$ （ 16 進） ◎ 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]).

`401$st 応答~messageは、`~UA$への権限付与を~challengeするために，`生成元~server$により利用され、［ 要請された資源に適用-可能な， 1 個~以上の `challenge$p ］を包含する， `WWW-Authenticate$h ~headerを含む。 ◎ 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.

`407$st 応答~messageは、`~client$への権限付与を~challengeするために，`~proxy$により利用され、［ 要請された資源~用に~proxyに適用-可能な， 1 個~以上の `challenge$p ］を包含する， `Proxy-Authenticate$h ~headerを含む。 ◎ 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.

`challenge@p
	= `auth-scheme$p [ 1*`SP$P ( `token68$p / #`auth-param$p ) ]

注記： 多くの`~client$は、［ 未知な~schemeを包含するような `challenge$p ］の構文解析-に失敗する。 この問題~用の対処法は、広く~supportされている~schemeたち（ "`basic^c" など）を，~~最初の方に挙げることである。 ◎ 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.

`~UA$は、 — 必要とされてはいないが通例的には， `401$st を受信した後に — ［ 要請に `Authorization$h ~headerを内包する ］ことにより，［ 自身を`生成元~server$から認証してもらう ］ことができる。 ◎ 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.

`~client$は、 — 必要とされてはいないが通例的には， `407$st を受信した後に — ［ 要請に `Proxy-Authorization$h ~headerを内包する ］ことにより，［ 自身を`~proxy$から認証してもらう ］ことができる。 ◎ 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.

`credentials@p
	= `auth-scheme$p [ 1*`SP$P ( `token68$p / #`auth-param$p ) ]

`~server$は、妥当ではあるが ~accessを獲得するには必要十分でない`資格証$を受信したときは，状態s~code `403$st で応答する~OUGHT。 ◎ 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]).

~HTTPは、この単純な ［`~challenge$応答］ ~frameworkによる応用を，~access認証のみに制約しない。 追加的な仕組みにも利用し得る — ［ ~transport~levelの認証として, あるいは ~messageによる~capsule化を介して ］, および認証~情報を指定する追加的な~headerを伴わせるような。 しかしながら、そのような追加的な仕組みは，この仕様では定義されない。 ◎ 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.

2.2. 保護~空間（ `realm^c ）

`名前$var `realm@c の`認証~parameter$は、`認証~scheme$における保護の視野 — `保護~空間$ — を指示する利用が望まれるときのために，予約されている。 ◎ The "realm" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.

`保護~空間@ は、~accessされている`~server$の `正準的~root~URI@ — `実効~要請~URI$の［ `scheme$p, `authority$p ］成分の組 — と, この `realm$c 値（もし在れば）との組合nにより定義される。 `realm$c により、`~server$上の保護される資源たちを，いくつかの`保護~空間$に区分できるようになる — それぞれが自前の［ `認証~scheme$や, 権限付与~database ］を伴うような。 `realm$c 値は、一般に，`生成元~server$によりアテガわれる文字列であり、`認証~scheme$に特有な追加的な意味論を持ち得る。 応答は、［ 同じ `auth-scheme$p を伴いつつ, 異なる `realm$c 値を伴う ］ような，複数の `challenge$p を持ち得ることに注意。 ◎ 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.

`保護~空間$は、`資格証$を自動的に適用できるような~domainを決定する。 先立つ要請に権限付与されていた場合、`~UA$は、その`保護~空間$に属する他のすべての要請に対し，同じ`資格証$を ある期間までは再利用してヨイ — その期間は、［ `認証~scheme$, `認証~parameter$たち, 利用者-選好（環境設定できるような放置 制限時間など） ］のうち いくつかから決定される。 `認証~scheme$により特に許容されない限り、単独の`保護~空間$は，その`~server$の視野から外へは拡張できない。 ◎ 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.

歴史的な理由から、`送信者$は， `quoted-string$p 構文のみを`生成し$なければナラナイ。 長年にわたり両 表記法を受容してきた既存の`~client$との相互運用能を最大にするため、 `受信者$は， `token$p, `quoted-string$p 両~構文の~supportを要し得る。 ◎ 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.

3.1. `401^st

状態s~code `401^st は、［ 要請は、`~target資源$用の妥当な認証 `資格証$を欠如するために，まだ適用されていない ］ことを指示する。 `~server$が `401^st0 応答を`生成する$ときは、［ ~target資源に適用-可能な `challenge$p を， 1 個~以上は包含する ］ような， `WWW-Authenticate$h ~headerを送信しなければナラナイ。 ◎ 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.

3.2. `407^st

4.1. `WWW-Authenticate^h

`WWW-Authenticate^h ~headerは、`~target資源$に適用-可能な［ `認証~scheme$たち, および `認証~parameter$たち ］を指示する。 ◎ The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.

`WWW-Authenticate@p
	= 1#`challenge$p

`401$st 応答を`生成する$`~server$は、［ 1 個~以上の `challenge$p を包含する， `WWW-Authenticate$h ~header ］を送信しなければナラナイ。 ~serverは、他の応答~message内にも， `WWW-Authenticate$h ~headerを`生成し$てヨイ — 【後の要請に】 `資格証$（または異なる`資格証$）を給することが，対する応答に影響し得ることを指示するために。 ◎ 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.

応答を回送している`~proxy$は、その応答~内のどの `WWW-Authenticate$h ~headerも，改変してはナラナイ。 ◎ A proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response.

`~UA$には、`~header値$を構文解析するときに，特別に~careすることを勧める — それは，複数の `challenge$p を包含することがあり、また，各 `challenge$p も，いくつかの`認証~parameter$からなる~commaで分離された~listを包含し得るので。 更には、~header自体も複数~回 生じ得る。 ◎ 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.

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

注記： `challenge$p 文法~生成規則も~list構文を利用する。 したがって、［ ~comma, 空白, ~comma ］の並びは、［ 先行している `challenge$p に適用するもの ］としても, あるいは［ `challenge$p の~listにおける，空~entry ］にも，見なし得る。 この多義性は、実施においては `~header値$の意味論に影響しないので，無害である。 ◎ 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^h

`Authorization^h ~headerにより、 `~UA$は，自身を`生成元~server$から認証してもらうことが可能になる — 必要とされてはいないが通例的には， `401$st 応答を受信した後に。 その値は、［ 要請-中にある資源が属する `realm$c 用の，`~UA$の認証~情報 ］を包含する`資格証$からなる。 ◎ 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@p
	= `credentials$p

要請が認証され, かつ `realm$c も指定されている場合、同じ`資格証$は，［ この `realm$c に属する 他のすべての要請に対しても，妥当である ］と~~見做されるようになる（`認証~scheme$自体が，他のもの — `challenge$p 値に則って, あるいは同期された`時計$を利用して様々になるような，`資格証$など — を要求しない限りにおいて）。 ◎ 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).

要請を回送している`~proxy$は、その要請~内のどの `Authorization$h ~headerも， 改変してはナラナイ。 ~HTTP~cacheによる `Authorization$h ~headerの取扱い［ の詳細／に課される要件 ］については、 `7234-3.2$rfc を見よ。 ◎ 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.

4.3. `Proxy-Authenticate^h

`Proxy-Authenticate^h ~headerは， 1 個~以上の `challenge$p からなり、そのそれぞれは，［ この`実効~要請~URI$に対し，`~proxy$に適用-可能な［ `認証~scheme$, `認証~parameter$たち ］］を指示する。 `~proxy$は、自身が`生成する$各 `407$st 応答~内に， 1 個~以上の `Proxy-Authenticate$h ~headerを送信しなければナラナイ。 ◎ 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@p
	= 1#`challenge$p

`WWW-Authenticate$h とは違って， `Proxy-Authenticate$h ~headerは、［ 応答`連鎖$の`外方$にある次の`~client$ ］のみに適用される — 当の`~proxy$を選択した`~client$のみが，認証に必要yな`資格証$を持つ見込みが高いので。 しかしながら、同じ管轄の中で複数の`~proxy$が利用されるとき — 巨大~企業~networkの中の，各~部署の~caching~proxyなど — `~UA$により`生成され$た`資格証$が，消費されるまで階層を通過することは、共通的にある。 よって，そのような環境設定では、各`~proxy$は同じ `challenge$p 集合を送信することになり， `Proxy-Authenticate$h が回送されているかのように出現することになる。 ◎ 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$p の構文解析に際しての考慮点は、この~headerにも適用される。 詳細は`4.1$sec を見よ。 ◎ Note that the parsing considerations for WWW-Authenticate apply to this header field as well; see Section 4.1 for details.

4.4. `Proxy-Authorization^h

`Proxy-Authorization^h ~headerは、 `~client$が，認証を要求する`~proxy$に対し，自身を（または その利用者を）識別してもらうことを可能にする。 その値は、［［ 当の~proxyや, 要請-中にある資源が属する `realm$c ］用の，`~client$の認証~情報 ］を包含する，`資格証$からなる。 ◎ 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@p
	= `credentials$p

`Authorization$h と違って， `Proxy-Authorization$h ~headerは、［ `Proxy-Authenticate$h ~headerを利用して認証を請求した，`内方$にある次の`~proxy$ ］のみに適用される。 `連鎖$にて複数の~proxyが利用されているときは、 `Proxy-Authorization$h ~headerは，［ `資格証$を受信することを予期していた最初の内方~proxy ］により消費される。 複数の~proxyが，所与の要請を協力的に認証する仕組みを成している場合、 `~proxy$は，~client要請からの`資格証$を 次の~proxyへ中継してヨイ。 ◎ 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.

5.1. 認証~scheme~registry

［ `~challenge$および`資格証$における，`認証~scheme$ ］用の名前空間は、新たに作成された `Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry＠~IANA-a/http-authschemes$ （ HTTP 認証~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>.

5.2. 状態s~code登録

`~HTTP状態s~code~registry＠~IANA-a/http-status-codes$ は、以下の登録により更新された： ◎ 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:

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

5.3. ~header登録

~HTTP~headerは、 `Message Headers＠~IANA-a/message-headers/$ ~registryにて登録される。 ◎ HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>.

この文書は、次の~HTTP~headerを定義する。 それに伴い "Permanent Message Header Field Names" ~registryは更新された（`BCP90$rを見よ）。 ◎ This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [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 |
   +---------------------+----------+----------+-------------+

変更~制御者は~IETF-orgである。 ◎ The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".

6.1.`資格証$の機密性

~HTTP認証~frameworkは、［ `資格証$の機密性を保守するための，単独の仕組み ］を定義しない — 代わりに、各 `認証~scheme$が［ 伝送に先立って`資格証$が符号化される方法 ］を定義する。 これは、将来の`認証~scheme$の開発に柔軟性を供する一方で、［ 自前の機密性を供さない, あるいは 反射攻撃に対する保護には足らない ］ような既存の~schemeの保護には，必要十分でない。 更には，`~server$が［ 個々の利用者に特有な`資格証$ ］を期待する場合、それらの`資格証$の交換は，その利用者を識別する効果ももたらす — `資格証$の中の内容が機密的であり続けるとしても。 ◎ 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が供する~headerの伝送の機密性は、下層［ ~transport／~session ］~level接続の，各種 ~securityの~propertyに依存する。 言い換えれば、`~server$は，［ この~frameworkを利用して，~accessを認証-済み利用者のみに制限する場合 ］には，［ その接続が，利用する`認証~scheme$の資質に則って適正に~secure化される ］ことを確保する必要がある。 例えば、個々の利用者~認証に依存する~serviceは、［ `資格証$を交換するに先立って，接続が~TLS（ “Transport Layer Security”, `5246$R ）により~secure化される ］ことを要求することが多い。 ◎ 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.

6.2. 認証 `資格証$と遊休~client

既存の~HTTP `~client$／`~UA$が 認証~情報を維持する~~期間は、概して 不定である。 ~HTTPは、［ `生成元~server$が、`~client$に対し，~cacheされた`資格証$を破棄するように指令する ］ための仕組みは供さない — この~protocolは、［ ~UAが`資格証$を 得する／管理する 方法 ］については関知しないので。 ［ `資格証$を 失効させる／廃用する ための仕組み ］は、`認証~scheme$定義の一部として指定し得る。 ◎ 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.

少なくとも，次に挙げる状況下においては、資格証の~cachingが，~appの~security~modelに干渉し得る： ◎ Circumstances under which credential caching can interfere with the application's security model include but are not limited to:

• `~client$が期間を延長して遊休~中にあるときに、`~server$が，`~client$に対し［ 再度，利用者に`資格証$の~~入力を促す ］ように望むことがあるとき。 ◎ • 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.
• ~appは，~sessionの終了n指示（~page上の “~logout” や “~commit” ~buttonなど）を含んでいて、それにより，~appの~server側は［ `~client$が`資格証$を維持する理由は それ以上~無い ］ことを “知る” ようなとき。 ◎ • 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.

`資格証$を~cacheする`~UA$には、［［ ~cacheされた`資格証$を，利用者-制御の下で破棄する ］ための，~~簡単に~access可能な仕組み ］を供することが奨励される。 ◎ User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.

6.3. 保護~空間

［ `保護~空間$を確立するときに，もっぱら `realm$c の仕組みに依拠する ］ような`認証~scheme$は、［ `生成元~server$上のすべての資源に対し，`資格証$を公開する ］ことになる。 資源への認証-済み要請を成功裡に為した`~client$は、同じ`生成元~server$上の他の資源に対しても，同じ認証 `資格証$を利用できる。 これは、［ ある資源が，他の資源~用の認証 `資格証$を採取すること ］をアリにする。 ◎ 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.