[11] credentials は、HTTP認証における認証のための利用者名やパスワードなどの情報を記述したものです。 Authorization: ヘッダーなどで使われます。

仕様書

構文

[21] credentials は、 auth-scheme のみか、その後に auth-param のリスト (#) または token68 を続けたものです。

[22] auth-scheme の後に続く場合には auth-scheme の後に1文字以上の SP が必要です。

  1. auth-scheme
  2. ?
    1. +
      1. SP
    2. |
      1. auth-param のリスト
      2. token68
[2] RFC 1945 や RFC 2068 では、原則として auth-param のリスト (#) ながらも、基本認証だけ特別な構文とされていました。 RFC 2617 ではなぜか基本認証の場合が示されていませんでした。 RFC 7235 で基本認証の場合が token68 に置き換えられました。[3] RFC 2617 までは区切りの SP が省略されていて、 LWS が暗示的に挟まるとも明記されていませんでした。

[4] auth-param や token68 の部分は auth-scheme によって異なる構文となります。 どの auth-scheme でも共通して必須である引数はありません。

[23] 詳しくは auth-scheme と各認証方式の項を参照。

[24] token68 は既存の認証方式の構文との互換性のためのもので、 新しい認証方式は使うべきではありませんought to >>22。

[37] とされてはいるものの、 Basic や Bearer など token68 形式はよく使われています。

authorization credentials

[14] 次のヘッダーは、 authorization credentials に分類されています >>13。

[15] X-WSSE: もこの分類に含めるのが適当かもしれません。

[16] これに属するヘッダーは、 TRACE に対する応答に含めるべきではないでしょう。

文脈

[7] credentials は Authorization: ヘッダーや Proxy-Authorization: ヘッダーの値として使われます。

適用範囲と再利用

[5] 利用者エージェントがある credentials を自動的に適用できる範囲は、 ホストと realm による保護空間により決まります。 当該 creadentials 付きの要求が一旦認証されれば、 それを同じ空間の別の要求に対しても、 auth-scheme、 auth-param、 あるいは利用者の設定によって決まる期間、再利用して構いません。 >>1, >>8

[6] auth-scheme によって特に決められていない限り、 保護空間を鯖を超えて延長することはできません。 >>1, >>8

[26] 利用者エージェントによる credentials の保存の期間を満了させたり、 破棄させたりする方法は HTTP としては規定されていませんが、 認証方式によってはそのような仕組みを規定することもできます。 >>25

[27] 利用者エージェントは保存されている利用者が credentials を破棄できる仕組みを提供することを推奨encourageされています >>25。

[28] 最近の Webブラウザーにはパスワードマネージャーのような機能があり、 サイトごとのパスワードを個別に削除できます。

[29] また、一括またはサイトごとのパスワードを消去する機能を用意している Webブラウザーや、終了時に消去するシークレットウィンドウのような機能を用意している Webブラウザーもあります。

[30] 現在の Webブラウザーの一般的な実装では、ある保護空間に対する Webブラウザーのセッションの初回 401 応答では保存されているパスワードを補完した入力ダイアログボックスを表示し、 以後のアクセスでは予め credentials を指定した要求を送信するようになっています。

[31] 自動的な credentials の送信をやめるよう著者が鯖側から指示する 「ログアウト」機能が度々提案されていますが、そのような機能が必要な場合は Cookie認証が用いられることが多く、特に必要性は高く無いとして Webブラウザー開発者等の関心は高くないのが実情のようです。

[33] この Webブラウザーの自動的な credentials のため、 一つのホストを複数の著者が共有しているような場合に、 他の著者の資源に対するパスワードを受信することが可能となってしまいます。 realm を指定しても対策にはなりません >>32。

[34] これは Webブラウザーの問題とは考えられていません。 これが問題となるような場合、鯖側の管理者は著者にHTTP認証の機能を提供するべきではありません。

[38] 基本認証においては、 要求の対象URLから path 部分の最後の / の後の文字をすべて削除したものが、当該要求の認証範囲authentication scopeとなります。 クライアントは、認証範囲と接頭辞一致する URL によって表される資源は、当該要求の realm で表されるのと同じ保護空間内にあるものと仮定するべきです。 >>42

[43] ダイジェスト認証も参照。

[41] クライアントは、サーバーから改めて challenge を受信せずとも、予め保護空間内の資源への要求に Authorization: ヘッダー (プロキシの認証の場合は Proxy-Authorization: ヘッダー) で基本認証の credentials を含めて送信できます >>42。

[40] パスワードマネージャーも参照。

歴史

RFC 第1世代

  • [1] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-11

RFC 第2世代

  • [8] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-11

RFC 第3世代

  • [39] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-2
  • [9] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#page-4
  • [35] RFC Errata Report ( 版) http://www.rfc-editor.org/errata_search.php?rfc=2617

RFC 第4世代

  • [10] RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication ( 版) https://tools.ietf.org/html/rfc7235#section-2.1

Fetch

[17] Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0087.html

[18] Move credentials out of network or cache fetch since it ties in with COR... · 9014f52 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/9014f52207bd12f9882ee929d13d3b39def02790

[19] Credential Management ( ( 版)) https://mikewest.github.io/credentialmanagement/spec/

[402] [webappsec] Rechartering: Credential Management API ( (Brad Hill 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0123.html

[36] Credential Management ( 版) https://w3c.github.io/webappsec/specs/credentialmanagement/

[44] Explain CORS protocol and credentials interaction ( (annevk著, )) https://github.com/whatwg/fetch/commit/c9e8db9d9075989fd2b91203f0247c52bac0ca27

user credentials

[45] Cross-Origin Resource Sharing ( ( 版)) http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#user-credentials

[46] Re: [whatwg] [Fetch spec] Link to CORS FAQ wiki ( (Anne van Kesteren 著, 版)) http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0087.html

[47] Reference Fetch for “credentials” definition (sideshowbarker著, ) https://github.com/whatwg/xhr/commit/900f0138ba16dbe14d610f5aa8a417185e3f49c0

[48] Reference Fetch spec for “credentials” definition by sideshowbarker · Pull Request #163 · whatwg/xhr () https://github.com/whatwg/xhr/pull/163

[49] Clarify that credentials includes HTTP authentication (sideshowbarker著, ) https://github.com/whatwg/fetch/commit/d84658ee3f97b0dafa3ff3e4a2d10dbf8e77c2d6

[50] Doc: Definition of credentials unclear · Issue #612 · whatwg/fetch () https://github.com/whatwg/fetch/issues/612

[51] Clarify that credentials include HTTP auth by sideshowbarker · Pull Request #616 · whatwg/fetch () https://github.com/whatwg/fetch/pull/616

[52] [worklets] Change the default credentials mode from 'omit' to 'same-o… (nhiroki著, ) https://github.com/w3c/css-houdini-drafts/commit/06d6906df81a3cd17893ed6bb2da79354c8dd7c1

[53] Change credentials mode default · Issue #756 · w3c/css-houdini-drafts () https://github.com/w3c/css-houdini-drafts/issues/756

[54] [worklets] Change the default credentials mode by nhiroki · Pull Request #757 · w3c/css-houdini-drafts () https://github.com/w3c/css-houdini-drafts/pull/757