[7] 認証authenticationは、合言葉その他の方法によってクライアントが鯖の資源にアクセスする権限を有しているか確認し、限定する機能です。 基本認証や OAuth が広く用いられています。

仕様書

プロトコル要素

[3] HTTP認証に関わる次のHTTPヘッダー

[4] HTTP認証に関わる次のHTTP状態符号があります。

[6] HTTP認証に関わる次の構文があります。

認証方式

[8] HTTP認証では基本認証や OAuth をはじめ、 色々な認証方式を用いることができます。詳しくは auth-scheme を参照してください。

サーバーの処理

[11] 起源鯖は、保護された資源に対する要求で credentials がなかったり、 非妥当な credentials (例えば誤ったパスワード) が指定されていたり、 不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階) が指定されていたりする場合には、最低1つの (おそらくは新しい) challenge が指定された WWW-Authenticate: ヘッダーを含む 401 応答を送信するべきです >>10。

[12] 認証が必要な串は、要求で串についての credentials がなかったり、 非妥当な credentials (例えば誤ったパスワード) が指定されていたり、 不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階) が指定されていたりする場合には、最低1つの (おそらくは新しい) challenge が指定された Proxy-Authenticate: ヘッダーを含む 407 応答を送信するべきです >>10。

[14] 認証が必要な串で認証に成功した場合には通常は Proxy-Authorization: ヘッダーを削除して転送しますが、 串の構成によってはそのまま転送することもあります。 Proxy-Authorization: ヘッダーの項を参照。

[13] 鯖は、妥当な credentials が含まれていて、なお適切なアクセス権を有しない場合には、 403 応答を返すべきought toです >>10。

[28] 401、challenge、各認証方式の項も参照。

クライアントの処理

[31] 複数の認証方式がサーバーにより指定された場合、XXX 基本認証参照。

[32] Webブラウザーが対応するべき (または対応するべきでない) 認証方式については、 認証方式の項を参照。

[30] 各認証方式の項も参照。

[33] credentials の再利用については、 credentials、 パスワードマネージャー、ダイジェスト認証を参照。

認証ダイアログ

[35] Webブラウザーは、利用者にダイアログを表示して利用者名と合言葉を尋ねるのが普通です。 realm 引数があれば、それをダイアログに表示します。

[36] HTTP認証ダイアログには、起源サーバーの認証のためのものと、 プロキシの認証のためのものがあります。 利用者に対してどちらであるのか明確に表示する必要があります。

認証ダイアログには、他にTLSクライアント認証のためのものもあります。

[38] 悪意あるサーバーによる spoofing で、 他のサイトと見せかけて利用者名や合言葉を収集される危険性があります >>37。 従ってダイアログはフィッシング対策が必要となります。

[39] 例えば起源を明示する、 TLS証明書の情報を表示するなどが考えられます。 realm を表示する際に、他のサイトやシステムのメッセージと誤認されにくい形とするよう配慮する必要もあります。 窓が最小化されていたり、他のタブが表示されていたり、 フレームとして埋め込まれていたりして、どの閲覧文脈と認証ダイアログが対応しているのか利用者に分かりにくい状態となることも、 避けるべきでしょう。

[34] 認証ダイアログの表示中Webブラウザーの他の関係ない機能まで使えなくならないよう、 利用者の便宜をはかることが望ましいと考えられます。

モーダルダイアログ参照。

[40] 実装によっては、合言葉として非ASCII文字を入力できません。 そのような実装方法は望ましくないと思われますが、 サーバーは非ASCII文字を使うべきではないでしょう。

認証ダイアログ後の再読込について、再読込

[56] Chrome はいつのまにか fetch で認証ダイアログが出ず、 即座に 401 Response をスクリプトにわたすようになりました。 (昔はちゃんと出てたのに。) どうして非互換変更しちゃうんだろうなあ。

認証の検出

[16] HTTP では資源にどのような認証によるアクセス制御が適用されているかクライアントが確実に知る方法はありません。 認証の有無によって応答が成功するかエラーになるか異なる場合もありますが、 認証しない「匿名」権限でも一部のみアクセスできるような場合もあります。

[17] If-Match: にダミーの実体タグを指定してダミーの PUT 要求を (認証なしで) 送信すると、認証が必要なら 401 応答と WWW-Authenticate: ヘッダーが返され、 必要ないとしても If-Match: の実体タグと実際の実体タグが一致しないので、 PUT は実行されません。 >>15

[18] PUT に対応していないとしても 405 などが返されるはずです。クライアントは鯖がおそらく返さないであろう適当な実体タグを生成する必要があります。[19] 認証より条件付きヘッダーが先に評価されてしまうと意図通りに動作しません >>15 し、条件付きヘッダーが実装されていないと PUT が実行されてしまいます。

[20] Authorization: ヘッダーに適当な (認証を通過しなそうな) 値を指定して送信することで、401 応答と WWW-Authenticate: ヘッダーが返されると期待できます >>15。

[21] しかし鯖が黙って無視するなら期待通り challenge を得ることはできません。

実装

[1] [IE5] Office ドキュメントを開くと認証ダイアログが表示される http://support.microsoft.com/default.aspx?scid=kb;ja;415541

基本認証のかかったページ内にある Excel などの Office ドキュメントを Internet Explorer 5 上から開こうとすると、再度、認証ダイアログが表示される現象

Office 2000 アプリケーションが Internet Explorer から起動される場合、Internet Explorer のキャッシュを利用せずに、Internet Explorer から渡された URL から自分自身で、ファイルをダウンロードして、ファイルを表示するようになっています。Internet Explorer は、他のプロセスにパスワードなどの認証情報を引き継がないため、Office 2000 アプリケーションが認証情報を設定せずに、Web サーバへリクエストを送信するためです。

バッドノウハウ

[57] 逆プロキシとアプリケーションサーバーが分離されているタイプの (中規模・大規模の) Webアプリケーションで、 HTTP認証をプロキシサーバーに担当させ、 アプリケーションサーバーは認証済みの要求だけが来るものと想定して認証しない設計が、 しばしば使われます。

[58] この設計方法には、多数のアプリケーションサーバーがあっても認証情報をプロキシサーバー側に集約でき、 アプリケーションサーバーはアプリケーションロジックに集中できるという管理運用上のメリットがあります。

[59] ところがこの設計方法は、ちょっとしたミスで認証なしでのアクセスを認めてしまうという、 脆弱性と隣合わせです。設計当初、すべてがうまく機能しているうちは、 まったく問題がありません。長く運用しているうちに、気付かないでミスを起こし、 長く脆弱な状態のまま放置してしまいがち、という嫌なタイプです。 具体的には、

関連

[9] HTTP では、 HTTP 本体の機能である HTTP認証の他に、 用途や個々の Webアプリケーション特有の色々な認証方式が用いられています。 例えば次のものがあります。

[22] HTTPキャッシュは HTTP認証については適切に処理するのが既定の動作になっていますが、 それ以外の認証方式には対応できないので、適宜 Cache-Control: ヘッダーなどで制御する必要があります。 (通常はクライアントも鯖も、 相手との間にキャッシュが存在するかどうか知り得ないので、両者共に適切なヘッダーを指定する必要があります。)

歴史

[1] HTTP Authentication with HTML forms : Paul James http://www.peej.co.uk/articles/http-auth-with-html-forms.html

[408] draft-williams-websec-session-continue-proto-00 - Hypertext Transport Protocol (HTTP) Session Continuation Protocol ( ( 版)) http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00

[410] draft-oiwa-httpauth-multihop-template-00 - Common Template for HTTP Message-based Multi-hop Authentication ( ( 版)) https://tools.ietf.org/html/draft-oiwa-httpauth-multihop-template-00

[411] draft-williams-httpbis-auth-classification-01 - A Proposals for Classification and Analysis of HTTPbis Authentication Proposals ( ( 版)) http://tools.ietf.org/html/draft-williams-httpbis-auth-classification-01

[413] Define authentication entries a bit better https://www.w3.org/Bugs/Publi... · bffaa17 · whatwg/fetch ( ( 版)) https://github.com/whatwg/fetch/commit/bffaa17cdad4f7924548233d24ff14b0ae793bbb

[414] XEP-0070: Verifying HTTP Requests via XMPP ( ( 版)) http://xmpp.org/extensions/xep-0070.html

[23] HTTP authentication - The Chromium Projects ( 版) https://www.chromium.org/developers/design-documents/http-authentication

Chrome supports four authentication schemes: Basic, Digest, NTLM, and Negotiate. Basic, Digest, and NTLM are supported on all platforms by default. Negotiate is supported on all platforms except ChromeOS by default.

[24] HTTP authentication - The Chromium Projects ( 版) https://www.chromium.org/developers/design-documents/http-authentication

When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:

Basic: 1

Digest: 2

NTLM: 3

Negotiate: 4

The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.

So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.

[25] Handling Authentication (Windows) ( 版) https://msdn.microsoft.com/en-us/library/aa384220(VS.85).aspx

[26] Part3 - browsersec - Browser Security Handbook, part 3 - Browser Security Handbook - Google Project Hosting ( 版) https://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication

[27] RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP) ( 版) https://tools.ietf.org/html/rfc7481

Servers MUST support either Basic or Digest authentication; they are

not required to support both. Clients MUST support both to

interoperate with servers that support one or the other. Servers may

provide a login page that triggers HTTP authentication. Clients

should continue sending the HTTP authentication header once they

receive an initial 401 (Unauthorized) response from the HTTP server

as long as the scheme portion of the URL doesn't change.

[29] Bug 25791 – [new feature] Provide a way to opt out of authentication dialogs ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=25791

[41] Fix #209: no credential prompt when credentials mode is not include · whatwg/fetch@10cb34f ( 版) https://github.com/whatwg/fetch/commit/10cb34f48160b21c1013aa720242f4bb12eceb45

[42] 21013 – Credentials and HTTP authentication ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=21013

[43] RFC 7030 - Enrollment over Secure Transport () https://tools.ietf.org/html/rfc7030#section-3.2.3

HTTP Basic and Digest authentication MUST only be performed over TLS

1.1 [RFC4346] or later versions. NULL and anon cipher suites MUST

NOT be used because they do not provide confidentiality or support

mutual certificate-based or certificate-less authentication,

respectively.

[44] RFC 7030 - Enrollment over Secure Transport () https://tools.ietf.org/html/rfc7030#section-3.2.3

As specified in "Certificate Management over CMS

(CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume

client support for any type of HTTP authentication such as cookies,

Basic authentication, or Digest authentication". Clients SHOULD

support the Basic and Digest authentication mechanism.

[45] RFC 7030 - Enrollment over Secure Transport () https://tools.ietf.org/html/rfc7030#section-3.2.3

A client MAY set the username to the empty string ("") if it is

presenting a password that is not associated with a username.

RFC 8053

[46] RFC 8053 は、 HTTP認証の拡張機能を提案するもので、 に出版されました >>47。

  • [47] RFC 8053 - HTTP Authentication Extensions for Interactive Clients () https://tools.ietf.org/html/rfc8053#section-4.1

[48] 現在主流の HTML フォームベースの認証にはフィッシングなどの問題があると指摘して、 新しい方法を提案しています。認証方式は既存の HTTP認証のものを流用しているものの、 新しいHTTPヘッダーを導入するなど既存の HTTP認証の方式との互換性はありません。 また、広く使われているフォームやクッキー認証との互換性もありません。

[49] 主要な Webブラウザーは実装していませんし、 Webサーバー側の開発者にとっても既存の方式から乗り換えるだけのメリットがあるのかは謎です。 今後普及する見込みがあるのかどうかは不明です。

[50] Use Fetch terminology for HTTP authentication. (mikewest著, ) https://github.com/w3c/webappsec-clear-site-data/commit/78abb9acf975d4a48870138bc40d9d77626219e4

[51] HTTP Authentication - WHATWG Wiki () https://wiki.whatwg.org/wiki/HTTP_Authentication

[52] 174179 - Re-Re-Think HTTP Basic Auth experience with respect to embedded content - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=174179

[53] Stop saying HTTP authentication over WebSocket is disallowed (ricea著, ) https://github.com/whatwg/fetch/commit/8b070f14a1fb2d1f8f4d07e1902a40a14f77b060

[54] WebSocket: "HTTP authentication will not function" is not correct · Issue #565 · whatwg/fetch () https://github.com/whatwg/fetch/issues/565

[55] Stop saying WebSocket auth is disallowed by ricea · Pull Request #761 · whatwg/fetch () https://github.com/whatwg/fetch/pull/761

[66] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--location-trusted

[67] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#-n

[68] GNU Wget 1.20 Manual () https://www.gnu.org/software/wget/manual/wget.html#index-authentication-2

[69] CACAO Security Playbooks Version 1.0 (, ) https://docs.oasis-open.org/cacao/security-playbooks/v1.0/cs01/security-playbooks-v1.0-cs01.html#_lzonmc14ppik