1. 序論
~HTTPは、~access制御と認証~用の 一般的~frameworkを,拡張-可能な[ [`~challenge$応答] `認証~scheme$の集合 ]を介して,供する — それは、`~server$により~client要請を~challengeするために, および `~client$により認証~情報を供するために利用できる。 この文書は、`~HTTP11$認証を, `7230$R により定義される~architectureを通して定義する。 この~architectureには、[ 以前に `2617$R にて述べられた,一般的~framework ], および[ 以前に `2616$R にて定義された,関係する 各種~headerおよび状態code ]も含まれる。 ◎ 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].
IANA Authentication Scheme Registry( `5.1$sec )に,登録-済みの`認証~scheme$, および それらに対応0仕様を挙げる — 以前に `2617$R にて定義された認証~scheme "`basic^c", "`digest^c" も含めて。 ◎ 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.
1.1. 適合性, ~errorの取扱い
【 この節の内容は、 共通頁 に委譲。 】
1.2. 構文の表記法
【 この節の内容は、 共通頁 に委譲。 】
総集的~ABNF にて、他の文書から取込まれた規則, および すべての`~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. ~access認証~framework
2.1. ~challengeと応答
~HTTPは、単純な,`~challenge$応答による認証~frameworkを供する — それは、次の 2 つの目的に利用できる: ◎ HTTP provides a simple challenge-response authentication framework that can be used\
- `~server$が~client要請を~challengeする。 ◎ by a server to challenge a client request and\
- `~client$が認証~情報を供する。 ◎ by a client to provide authentication information.\
各 `~challenge@( `challenge$p ) は、順に,次の情報からなる: ◎ \
- `認証~scheme@ ( `auth-scheme$p ) を識別する,文字大小無視 `token$p 。 ◎ It uses a case-insensitive token as a means to identify the authentication scheme, followed by\
-
前項の~schemeの下で認証を受けるために必要とされる,追加の情報 — 次のいずれかをとり得る: ◎ additional information necessary for achieving authentication via that scheme. The latter can be either\
- いくつかの`認証~parameter$からなる,~comma区切りの~list。 ◎ a comma-separated list of parameters or\
- base64 符号化された情報を保持できる,単独の[ 文字~並び ]( `token68$p )。 ◎ a single sequence of characters capable of holding base64-encoded information.
各 `認証~parameter@ ( `auth-param$p )は、 "`=^c" で~~区切られた `名前@var と `値@var の~pairであり: ◎ Authentication parameters are name=value pairs, where\
- `名前$var は、文字大小無視で照合される `token$p である。 ◎ the name token is matched case-insensitively, and\
- 同じ `名前$var が生じるのは、 `challenge$p ごとに 1 個までで~MUST。 ◎ each parameter name MUST only occur once per 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.
[ `Authorization$h, `Proxy-Authorization$h ]両`~header値$とも,[ 要請-中にある`資源$が属する `realm$c ]用の[ `~client$の `資格証@( `credentials$p ) ]を包含する。 `~UA$は、それらの値を[ 応答~内に(場合によっては過去のある時点で)受信された `challenge$p ]に基づいて,次のように作成する~OUGHT: ◎ 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\
- 受信した `challenge$p たちのうち,[ 自身が解する かつ最も保安的と見なすような, `auth-scheme$p ]を伴うものを選定する。 ◎ selecting the challenge with what it considers to be the most secure auth-scheme that it understands,\
- 利用者から適宜 `資格証$を得る。 ◎ obtaining credentials from the user as appropriate.\
`資格証$を`~header値$の中に伝送することは、下層~接続の機密性に関する,有意な保安上の考慮点も含意する — `6.1$sec を見よ。 ◎ Transmission of credentials within header field values implies significant security considerations regarding the confidentiality of the underlying connection, as described in Section 6.1.
`credentials@p = `auth-scheme$p [ 1*`SP$P ( `token68$p / #`auth-param$p ) ]
`生成元~server$は、被保護~資源~用の`資格証$が[ 省略されている / 無効である(例: 不良~password) / 部分的である(例:`認証~scheme$が複数~回の往来を要求する) ]ような要請の受領~時には,次のような `401$st 応答を送信する~SHOULD: ◎ 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\
- `WWW-Authenticate$h ~headerを包含する。 ◎ contains a WWW-Authenticate header field\
- この~headerには、 1 個~以上の[ 要請された資源に適用-可能な `challenge$p ]を伴わせる(場合によっては 新たなそれも含ませる)。 ◎ with at least one (possibly new) challenge applicable to the requested resource.
同様に,認証を要求する`~proxy$は、~proxy`資格証$が[ 省略されている/無効である/部分的である ]ような要請の受領~時には,次のような `407$st 応答を`生成する$~SHOULD: ◎ 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\
- `Proxy-Authenticate$h ~headerを包含する。 ◎ contains a Proxy-Authenticate header field\
- この~headerには、 1 個~以上の[ その`~proxy$に適用-可能な `challenge$p ]を伴わせる(場合によっては 新たなそれも含ませる)。 ◎ with at least one (possibly new) challenge applicable to the proxy.
`~server$は、妥当ではあるが ~accessを獲得するには必要十分でない`資格証$を受信したときは,状態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による~encapsulationを介して ], および認証~情報を指定する追加の~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 値(もし在するなら)との組合わせにより定義される。 `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$は、その`保護~空間$に属する他のすべての要請に対し,同じ`資格証$を ある期間までは再利用して~MAY — その期間は、[ `認証~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 構文のみを`生成し$~MUST。 長年にわたり両 表記法を受容してきた既存の`~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. 状態code定義
3.1. `401^st
状態code `401^st は、[ 要請は、`~target資源$用の妥当な認証 `資格証$を欠如するために,まだ適用されていない ]ことを指示する。 `~server$が `401^st0 応答を`生成する$ときは、[ ~target資源に適用-可能な `challenge$p を, 1 個~以上は包含する ]ような, `WWW-Authenticate$h ~headerを送信し~MUST。 ◎ 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^st0 応答は,[ その`資格証$に対する権限付与は,拒否された ]ことを指示する。 `~UA$は,その応答に対し: ◎ If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.\
- [ 新たな, または他の値に置換された `Authorization$h ~header ]を伴わせた上で,要請を繰返して~MAY。 ◎ The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2).\
- [ その `401^st0 応答が,それに先立つ応答と同じ `challenge$p を包含する ], かつ[ ~UAは,認証をすでに 1 回は試みていた ]場合、同封された表現を利用者に提示する~SHOULD — それは、通例的に,関連する診断~情報を包含するので。 ◎ 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.
3.2. `407^st
状態code `407^st は、 `401$stに類似するが,[ `~client$は、`~proxy$を利用するためには,認証が必要である ]ことを指示する: ◎ 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.\
- ~proxyは、[[ 自身に適用-可能な, `~target資源$用の `challenge$p ]を包含する, `Proxy-Authenticate$h ~header ]を送信し~MUST。 ◎ The proxy MUST send a Proxy-Authenticate header field (Section 4.3) containing a challenge applicable to that proxy for the target resource.\
- `~client$は、[ 新たな, または他の値に置換された, `Proxy-Authorization$h ~header ]を伴わせた上で,要請を繰返して~MAY。 ◎ The client MAY repeat the request with a new or replaced Proxy-Authorization header field (Section 4.4).
4. ~header定義
この節では、~HTTP認証~frameworkに関係する各種~headerの構文と意味論を定義する。 ◎ This section defines the syntax and semantics of header fields related to the HTTP authentication framework.
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 ]を送信し~MUST。 ~serverは、他の応答~message内にも, `WWW-Authenticate$h ~headerを`生成し$て~MAY — 【後の要請に】 `資格証$(または異なる`資格証$)を給することが,対する応答に影響し得ることを指示するために。 ◎ 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も,改変し~MUST_NOT。 ◎ A proxy forwarding a response MUST NOT modify any WWW-Authenticate fields in that response.
`~UA$には、`~header値$を構文解析するときに,特別に配慮することを勧める — それは,複数の `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.
具体例: ◎ For instance:
WWW-Authenticate: Newauth `realm^c="apps", type=1, title="Login to \"apps\"", Basic `realm^c="simple"
この~headerは、 2 個の `challenge$p を包含する: ◎ This header field contains two challenges;\
- `Newauth^c ~scheme用の `realm$c 値 "`apps^c" を伴い,追加の~parameter `type^c, `title^c も伴うもの。 ◎ one for the "Newauth" scheme with a realm value of "apps", and two additional parameters "type" and "title", and\
- `Basic^c ~scheme用の `realm$c 値 "`simple^c" を伴うもの。 ◎ another one for the "Basic" scheme with a realm value of "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も, 改変し~MUST_NOT。 ~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を送信し~MUST。 ◎ 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$のみが,認証に必要とされる`資格証$を持つ見込みが高いので。 しかしながら、同じ管轄の中で複数の`~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へ中継して~MAY。 ◎ 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. ~IANA考慮点
5.1. 認証~scheme登記簿
[ `~challenge$および`資格証$における,`認証~scheme$ ]用の名前空間は、新たに作成された Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry ( HTTP 認証~scheme登記簿)にて保守され, 定義される。 ◎ 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.1.1. 手続き
登録にあたっては,次の~fieldを含ま~MUST: ◎ Registrations MUST include the following fields:
- `認証~scheme$名 ◎ • Authentication Scheme Name
- 仕様~textへの~pointer ◎ • Pointer to specification text
- 注記(省略可) ◎ • Notes (optional)
この名前空間に追加される値は, `IETF Review$ を要する。 ◎ Values to be added to this namespace require IETF Review (see [RFC5226], Section 4.1).
5.1.2. 新たな認証~schemeに対する考慮点
~HTTP認証~frameworkは、次の側面において,新たな`認証~scheme$がどのように働き得るかについての拘束を課す: ◎ There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:
- ~HTTP認証は、`~stateless$であることを~~前提にする: 要請を認証するために必要とされる,すべての情報が、その要請~内に供され~MUST — `~server$が それに先立つ要請を記憶することに依存するのではなく。 下層~接続に 基づく/束縛される 認証は、この仕様の視野~外であり、[ その接続が、認証-済み利用者~以外のどの主体からも利用され得ない ]ことを確保するための手順が踏まれない限り,内来的に欠陥があるものとされる( `7230-2.3$rfc を見よ)。 ◎ • 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]).
- `名前$var `realm$c の`認証~parameter$は、`保護~空間$を定義するものとして予約される。 新たな~schemeは、 "`realm^c" をその定義と非~互換な仕方で利用し~MUST_NOT。 ◎ • 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.
- 既存の`認証~scheme$との互換性のために, `token68$p 表記法が導入された — それは、 `challenge$p/`credentials$p ごとに 1 個しか利用できない。 したがって,新たな~schemeは、代わりに `auth-param$p 構文を利用する~OUGHT — さもなければ,将来の拡張が不可能になるので。 ◎ • 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.
-
`challenge$p/`credentials$p の構文解析は,この仕様により定義され、新たな`認証~scheme$は,それを改変できない。 `auth-param$p 構文が利用されるときは、すべての~parameterが `token$p, `quoted-string$p 両~構文を~supportする~OUGHT。 また,構文上の拘束は、構文解析-後の(すなわち, `quoted-string$p を処理した後の)`~header値$に対し,定義される~OUGHT。 これは、`受信者$が,[ すべての`認証~scheme$に適用される,汎用 構文解析器 ]を利用できるようにするために必要とされる。 ◎ • 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.
注記: "`realm^c" ~parameter用の値の構文が `quoted-string$p に制約される事は、悪い設計の選択であった — 新たな~parameterに対しては繰返されない。 ◎ 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.
- 新たな~schemeの定義は、未知の拡張~parameterの扱いを定義する~OUGHT。 一般に、 “無視しなければならない” とする規則が “解さなければならない” とするよりも選好される — さもなければ、旧来の`受信者$が在する下で,新たな~parameterを導入することが難しくなるので。 更には、新たな~parameterたちを定義するための~policyを述べる方が良い( “〜の仕様を更新せよ” や, “この登記簿を利用せよ” など)。 ◎ • 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").
- `認証~scheme$は、[ `生成元~server$による認証(すなわち, `WWW-Authenticate$h を利用)/ `~proxy$による認証(すなわち, `Proxy-Authenticate$h を利用) ]に利用できるかどうかを文書化する必要がある。 ◎ • 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).
- `Authorization$h ~header内に運ばれる`資格証$は,`~UA$に特有なので、それが出現する要請の視野の下で,~HTTP~cacheに対する `private$sdir `Cache-Control$h 応答~指令と同じ効果を持つ。 したがって,新たな`認証~scheme$は、`資格証$を `Authorization$h ~header内に運ばせないことを選択する場合(例えば,新たに定義される~headerを利用して)、~cachingを明示的に不許可にする必要がある — `Cache-Control$h 指令(例: 要請に対する `no-store$qdir や, 応答に対する `private$sdir )の利用を義務化することにより。 ◎ • 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").
5.2. 状態code登録
~HTTP状態code登記簿 は、以下の登録により更新された: ◎ 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:
- `401$st
- `407$st
+-------+-------------------------------+-------------+
| Value | Description | Reference |
+-------+-------------------------------+-------------+
| 401 | Unauthorized | Section 3.1 |
| 407 | Proxy Authentication Required | Section 3.2 |
+-------+-------------------------------+-------------+
5.3. ~header登録
~HTTP~headerは、 Message Headers 登記簿にて登録される。 ◎ 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" 登記簿は更新された(`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名 | ~protocol | 位置付け |
`Authorization$h | http | standard |
`Proxy-Authenticate$h | http | standard |
`Proxy-Authorization$h | http | standard |
`WWW-Authenticate$h | http | standard |
+---------------------+----------+----------+-------------+
| 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. 保安上の考慮点
この節は、[ 開発者/情報~provider/利用者 ]向けに, ~HTTP認証に特有の,既知の保安上の懸念を伝えることを~~意図している。 より一般的な保安上の考慮点は、 ~HTTP~messaging `7230-9$rfc, および ~HTTP意味論 `7231-9$rfc にて取組まれている。 ◎ 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認証の論題についての何でもが保安上の考慮点になるので、下に挙げる考慮点は,網羅的なものではない。 更には、[ 一般的な,認証~frameworkに関する保安上の考慮点 ]に制限されている — 特定の`認証~scheme$について考え得る,あらゆる考慮点を論じるのではなく(それらは,各~schemeを定義する仕様にて文書化される~OUGHT)。 様々な組織が,~Web~appの保安についての時事的な情報や現在の調査研究への~linkを保守する(例: `OWASP$r ) — 実施において見出される`認証~scheme$や, 実装する/利用する際に共通的な罠など。 ◎ 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.
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接続の,各種 保安上の~propertyに依存する。 言い換えれば、`~server$は,[ この~frameworkを利用して,~accessを認証-済み利用者のみに制限する場合 ]には,[ その接続が,利用する`認証~scheme$の資質に則って適正に保安化される ]ことを確保する必要がある。 例えば、個々の利用者~認証に依存する~serviceは、[ `資格証$を交換するに先立って,接続が~TLS( “Transport Layer Security”, `5246$RFC )により保安化される ]ことを要求することが多い。 ◎ 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の保安~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の終了~指示(頁~上の “~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$上のすべての資源に対し,`資格証$を公開する ]ことになる。 資源への認証-済み要請を成功裡に発行0した`~client$は、同じ`生成元~server$上の他の資源に対しても,同じ認証 `資格証$を利用できる。 これは、[ ある資源が,他の資源~用の認証 `資格証$を採取すること ]を可能0にする。 ◎ 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.
これは特に、[ `生成元~server$が、同じ`正準的~root~URI$の下で,複数の主体~用に資源を~hostするとき ]に,懸念される。 とり得る軽減策としては、次が挙げられる: ◎ 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\
- 認証 `資格証$への直接的な~accessを制約する(すなわち, `Authorization$h 要請~headerの内容を可用にしない)。 ◎ restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and\
- 異なる~host名(あるいは~port番号)を利用して,`保護~空間$を各~主体ごとに分離する。 ◎ separating protection spaces by using a different host name (or port number) for each party.
7. 謝辞
この仕様は、以前に `2617$R にて定義された HTTP Authentication Framework の定義に取って代わる。 その仕様の仕事をされた次の方々に感謝する( 更なる謝辞は `2617-6$rfc に): ◎ This specification takes over the definition of the HTTP Authentication Framework, previously defined in RFC 2617.
この文書による改訂に関係する謝辞は、 【 共通頁 に委譲。 】 ◎ See Section 10 of [RFC7230] for the Acknowledgments related to this document revision.
8. 参照文献
【 この節の内容は、 共通頁 に委譲。 】
付録 A. RFC 2616, 2617 からの変更点
- ~HTTP認証~用の~frameworkは、今や, `2617$R でなく,この文書にて定義される。 ◎ The framework for HTTP Authentication is now defined by this document, rather than RFC 2617.
- `realm$c ~parameterは,最早、常に `challenge$p 上に要求されることはない — その帰結として, ~ABNF は、 `auth-param$p ~parameterを伴わない `challenge$p も許容する。 ( `2$sec ) ◎ The "realm" parameter is no longer always required on challenges; consequently, the ABNF allows challenges without any auth parameters. (Section 2)
- `Basic^c などの旧来の`認証~scheme$との一貫性のため、 `auth-param$p ~listに対する `token68$p による代替が追加された ( `2$sec ) ◎ The "token68" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". (Section 2)
- この仕様は、新たな`認証~scheme$のための考慮点と伴に Authentication Scheme Registry を導入する。 ( `5.1$sec ) ◎ This specification introduces the Authentication Scheme Registry, along with considerations for new authentication schemes. (Section 5.1)
付録 B. 取込まれた~ABNF
付録 C. 総集的~ABNF
【 付録 B, C の内容は、 総集的~ABNF に委譲。 】