[7] [DFN[[RUBYB[[[認証]]]@en[authentication]]]]は、[[合言葉]]その他の方法によって[[クライアント]]が[[鯖]]の[[資源]]にアクセスする権限を有しているか確認し、限定する機能です。 [[基本認証]]や [[OAuth]] が広く用いられています。 * 仕様書 [REFS[ - [5] '''[CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) ''' -- [10] [CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) - [2] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [15] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [37] [CITE@en[RFC 7617 - The 'Basic' HTTP Authentication Scheme]] ([TIME[2015-10-01 09:47:40 +09:00]] 版) ]REFS] * プロトコル要素 [FIG(middle list)[ [3] [[HTTP認証]]に関わる次の[[HTTPヘッダー]] - [CODE(HTTP)@en[[[Authorization:]]]] - [CODE(HTTP)@en[[[Proxy-Authorization:]]]] - [CODE(HTTP)@en[[[WWW-Authenticate:]]]] - [CODE(HTTP)@en[[[Proxy-Authenticate:]]]] - [CODE(HTTP)@en[[[Authentication-Info:]]]] - [CODE(HTTP)@en[[[Proxy-Authentication-Info:]]]] - [CODE(HTTP)@en[Optional-WWW-Authenticate:]] - [CODE(HTTP)@en[Authentication-Control:]] ]FIG] [4] [[HTTP認証]]に関わる次の[[HTTP状態符号]]があります。 [FIG(short list)[ - [CODE(HTTP)[[[401]]]] - [CODE(HTTP)[[[407]]]] ]FIG] [6] [[HTTP認証]]に関わる次の構文があります。 [FIG(short list)[ - [CODE(ABNF)@en[[[auth-scheme]]]] - [CODE(ABNF)@en[[[auth-param]]]] - [[challenge (HTTP)]] - [[credentials]] ]FIG] * 認証方式 [8] [[HTTP認証]]では[[基本認証]]や [[OAuth]] をはじめ、 色々な認証方式を用いることができます。詳しくは [CODE(ABNF)@en[[[auth-scheme]]]] を参照してください。 * サーバーの処理 [11] [[起源鯖]]は、保護された[[資源]]に対する[[要求]]で [[credentials]] がなかったり、 非妥当な [[credentials]] (例えば誤った[[パスワード]]) が指定されていたり、 不完全な [[credentials]] (例えば複数回の往復が必要な認証方式の途中の段階) が指定されていたりする場合には、最低1つの (おそらくは新しい) [[challenge]] が指定された [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]を含む [CODE(HTTP)[[[401]]]] [[応答]]を送信する[['''べきです''']] [SRC[>>10]]。 [12] 認証が必要な[[串]]は、[[要求]]で[[串]]についての [[credentials]] がなかったり、 非妥当な [[credentials]] (例えば誤った[[パスワード]]) が指定されていたり、 不完全な [[credentials]] (例えば複数回の往復が必要な認証方式の途中の段階) が指定されていたりする場合には、最低1つの (おそらくは新しい) [[challenge]] が指定された [CODE(HTTP)@en[[[Proxy-Authenticate:]]]] [[ヘッダー]]を含む [CODE(HTTP)[[[407]]]] [[応答]]を送信する[['''べきです''']] [SRC[>>10]]。 ;; [14] 認証が必要な[[串]]で認証に成功した場合には通常は [CODE(HTTP)@en[[[Proxy-Authorization:]]]] [[ヘッダー]]を削除して[[転送]]しますが、 [[串]]の構成によってはそのまま[[転送]]することもあります。 [CODE(HTTP)@en[[[Proxy-Authorization:]]]] [[ヘッダー]]の項を参照。 [13] [[鯖]]は、妥当な [[credentials]] が含まれていて、なお適切なアクセス権を有しない場合には、 [CODE(HTTP)[[[403]]]] [[応答]]を返す[RUBYB[べき]@en[ought to]]です [SRC[>>10]]。 ;; [28] [CODE(HTTP)[[[401]]]]、[[challenge]]、各[[認証方式]]の項も参照。 * クライアントの処理 [31] 複数の[[認証方式]]が[[サーバー]]により指定された場合、 @@ XXX [[基本認証]]参照。 [32] [[Webブラウザー]]が対応するべき (または対応するべきでない) [[認証方式]]については、 [[認証方式]]の項を参照。 ;; [30] 各[[認証方式]]の項も参照。 [33] [[credentials]] の再利用については、 [[credentials]]、 [[パスワードマネージャー]]、[[ダイジェスト認証]]を参照。 ** 認証ダイアログ [35] [[Webブラウザー]]は、[[利用者]]に[[ダイアログ]]を表示して[[利用者名]]と[[合言葉]]を尋ねるのが普通です。 [CODE(HTTP)@en[[[realm]]]] [[引数]]があれば、それを[[ダイアログ]]に表示します。 [36] [[HTTP認証ダイアログ]]には、[[起源サーバー]]の[[認証]]のためのものと、 [[プロキシ]]の[[認証]]のためのものがあります。 [[利用者]]に対してどちらであるのか明確に表示する必要があります。 ;; [[認証ダイアログ]]には、他に[[TLSクライアント認証]]のためのものもあります。 [38] 悪意あるサーバーによる [[spoofing]] で、 他のサイトと見せかけて[[利用者名]]や[[合言葉]]を収集される危険性があります [SRC[>>37]]。 従ってダイアログは[[フィッシング]]対策が必要となります。 ;; [39] 例えば[[起源]]を明示する、 [[TLS証明書]]の情報を表示するなどが考えられます。 [CODE[[[realm]]]] を表示する際に、他のサイトやシステムのメッセージと誤認されにくい形とするよう配慮する必要もあります。 [[窓]]が最小化されていたり、他の[[タブ]]が表示されていたり、 [[フレーム]]として埋め込まれていたりして、どの[[閲覧文脈]]と[[認証ダイアログ]]が対応しているのか[[利用者]]に分かりにくい状態となることも、 避けるべきでしょう。 [34] [[認証ダイアログ]]の表示中[[Webブラウザー]]の他の関係ない機能まで使えなくならないよう、 [[利用者]]の便宜をはかることが望ましいと考えられます。 ;; [[モーダルダイアログ]]参照。 [40] 実装によっては、[[合言葉]]として[[非ASCII文字]]を入力できません。 そのような実装方法は望ましくないと思われますが、 [[サーバー]]は[[非ASCII文字]]を使うべきではないでしょう。 [TIME[2015-11-26T10:10:59.600Z]] [SEE[ 認証ダイアログ後の再読込について、[[再読込]] ]] [56] [[Chrome]] はいつのまにか [CODE[fetch]] で[[認証ダイアログ]]が出ず、 即座に [CODE[401]] [CODE[Response]] を[[スクリプト]]にわたすようになりました。 (昔はちゃんと出てたのに。) どうして[[非互換変更]]しちゃうんだろうなあ。 [TIME[2020-01-28T08:36:35.00Z]] * 認証の検出 [16] [[HTTP]] では[[資源]]にどのような[[認証]]によるアクセス制御が適用されているか[[クライアント]]が確実に知る方法はありません。 [[認証]]の有無によって応答が成功するかエラーになるか異なる場合もありますが、 [[認証]]しない「匿名」権限でも一部のみアクセスできるような場合もあります。 [17] [CODE(HTTP)@en[[[If-Match:]]]] にダミーの[[実体タグ]]を指定してダミーの [CODE(HTTP)@en[[[PUT]]]] [[要求]]を ([[認証]]なしで) 送信すると、[[認証]]が必要なら [CODE(HTTP)[[[401]]]] [[応答]]と [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]が返され、 必要ないとしても [CODE(HTTP)@en[[[If-Match:]]]] の[[実体タグ]]と実際の[[実体タグ]]が一致しないので、 [CODE(HTTP)@en[[[PUT]]]] は実行されません。 [SRC[>>15]] ;; [18] [CODE(HTTP)@en[[[PUT]]]] に対応していないとしても [CODE(HTTP)[[[405]]]] などが返されるはずです。[[クライアント]]は[[鯖]]がおそらく返さないであろう適当な[[実体タグ]]を生成する必要があります。 ;; [19] [[認証]]より[[条件付きヘッダー]]が先に評価されてしまうと意図通りに動作しません [SRC[>>15]] し、[[条件付きヘッダー]]が実装されていないと [CODE(HTTP)@en[[[PUT]]]] が実行されてしまいます。 [20] [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]に適当な ([[認証]]を通過しなそうな) 値を指定して送信することで、[CODE(HTTP)[[[401]]]] [[応答]]と [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]が返されると期待できます [SRC[>>15]]。 ;; [21] しかし[[鯖]]が黙って無視するなら期待通り [[challenge]] を得ることはできません。 * 実装 [1] [CITE[[IE5] Office ドキュメントを開くと認証ダイアログが表示される]] >基本認証のかかったページ内にある Excel などの Office ドキュメントを Internet Explorer 5 上から開こうとすると、再度、認証ダイアログが表示される現象 >Office 2000 アプリケーションが Internet Explorer から起動される場合、Internet Explorer のキャッシュを利用せずに、Internet Explorer から渡された URL から自分自身で、ファイルをダウンロードして、ファイルを表示するようになっています。Internet Explorer は、他のプロセスにパスワードなどの認証情報を引き継がないため、Office 2000 アプリケーションが認証情報を設定せずに、Web サーバへリクエストを送信するためです。 ** バッドノウハウ [57] [[逆プロキシ]]と[[アプリケーションサーバー]]が分離されているタイプの (中規模・大規模の) [[Webアプリケーション]]で、 [[HTTP認証]]を[[プロキシサーバー]]に担当させ、 [[アプリケーションサーバー]]は認証済みの[[要求]]だけが来るものと想定して認証しない設計が、 しばしば使われます。 [58] この設計方法には、多数の[[アプリケーションサーバー]]があっても認証情報を[[プロキシサーバー]]側に集約でき、 [[アプリケーションサーバー]]は[[アプリケーション]]ロジックに集中できるという管理運用上のメリットがあります。 [59] ところがこの設計方法は、ちょっとしたミスで認証なしでのアクセスを認めてしまうという、 脆弱性と隣合わせです。設計当初、すべてがうまく機能しているうちは、 まったく問題がありません。長く運用しているうちに、気付かないでミスを起こし、 長く脆弱な状態のまま放置してしまいがち、という嫌なタイプです。 具体的には、 - [60] 何かのきっかけで[[プロキシサーバー]]側の認証の設定を消してしまい、 まったく無認証で[[アプリケーションサーバー]]にアクセスできてしまう。 - [64] ネットワーク構成の変更で[[プロキシサーバー]]を廃止したとき、 [[認証]]が[[プロキシサーバー]]担当だったことを忘れ、 まったく無認証で[[アプリケーションサーバー]]にアクセスできてしまう。 - [61] [[アプリケーションサーバー]]側の仕様変更と連動して[[プロキシサーバー]]を更新することを忘れ、 またはタイミングのずれが生じ、 認証を回避して[[アプリケーションサーバー]]にアクセスできる抜け道を作ってしまう。 - [62] 特定の [[URL path]] のみ、特定の条件でアクセスしたときのみ、 のような前提条件 (例えば: 通常サービス画面と管理画面が混在する[[アプリケーション]]で、 管理画面へのアクセスのみ) によって[[認証]]をしたり、しなかったりするとき、 その条件が、[[プロキシサーバー]]側と[[アプリケーションサーバー]]側で違うため、 認証を回避して[[アプリケーションサーバー]]にアクセスできる抜け道を作ってしまう。 [EG[ [63] ある[[プロキシサーバー]]で [[URL path]] が [CODE[/admin/]] から始まる ([[大文字・小文字を区別する]]) なら[[認証]]する、 と設定しているとします。 対応する[[アプリケーションサーバー]]側で、 [[WAF]] の[[ルーティング]]によって [[URL path]] [CODE[/admin/]] を[[プログラミング言語]]側の [CODE[Admin]] という名前の処理に割り当てているとします。 ところが実は[[アプリケーション]]開発者は気づいていませんでしたが、 [[WAF]] の[[ルーター]]は [[URL path]] [CODE[/ADMIN/]] も [CODE[Admin]] という名前の処理に割り当てているとしたらどうでしょうか。 開発者は[[プロキシサーバー]]で[[認証]]されていると思っていますが、 実は[[認証]]を回避できる抜け道が存在しています。 ]EG] - [65] 同じネットワーク中の他の[[アプリケーションサーバー]]に、 外部の[[利用者]]が指定した [[URL]] から情報を取得する機能 (例えば[[ブログ]]に [[URL]] を貼り付けた時にリンク先ページタイトルを表示する機能とか。) があるとき、 そちらのサーバー側で同一ネットワーク内部へのアクセスを禁止するのを忘れると、 同一ネットワーク内部の[[アプリケーションサーバー]]に無認証でアクセスできてしまいます。 * 関連 [9] [[HTTP]] では、 [[HTTP]] 本体の機能である [[HTTP認証]]の他に、 用途や個々の [[Webアプリケーション]]特有の色々な認証方式が用いられています。 例えば次のものがあります。 [FIG(short list)[ - [[Cookie認証]] - [[OAuth 1.0]] ([[HTTP認証]]を使わないもの) - [[OAuth 2.0クライアント認証]] ([[HTTP認証]]を使わないもの) - [[OAuth 2.0]] [[ベアラートークン]]認証 ([[HTTP認証]]を使わないもの) - [[APIキー]] - [[Flickr Authentication API]] - [[はてな認証API]] - [[かんたんログイン]] - [[TLS]] [[クライアント認証]] - [[IPアドレス]]によるアクセス制限 - [CODE[email:]], [CODE[password:]] - [CODE[apiKey:]] - [CODE[jwtTokenString:]] - [[signed_request]] ]FIG] [22] [[HTTPキャッシュ]]は [[HTTP認証]]については適切に処理するのが既定の動作になっていますが、 それ以外の[[認証]]方式には対応できないので、適宜 [CODE(HTTP)@en[[[Cache-Control:]]]] [[ヘッダー]]などで制御する必要があります。 (通常は[[クライアント]]も[[鯖]]も、 相手との間に[[キャッシュ]]が存在するかどうか知り得ないので、両者共に適切な[[ヘッダー]]を指定する必要があります。) * 歴史 [1] [CITE[HTTP Authentication with HTML forms : Paul James]] [408] [CITE@en[draft-williams-websec-session-continue-proto-00 - Hypertext Transport Protocol (HTTP) Session Continuation Protocol]] ( ([TIME[2014-10-19 15:12:28 +09:00]] 版)) [410] [CITE@en[draft-oiwa-httpauth-multihop-template-00 - Common Template for HTTP Message-based Multi-hop Authentication]] ( ([TIME[2014-10-18 15:08:43 +09:00]] 版)) [411] [CITE@en[draft-williams-httpbis-auth-classification-01 - A Proposals for Classification and Analysis of HTTPbis Authentication Proposals]] ( ([TIME[2014-10-16 14:58:39 +09:00]] 版)) [413] [CITE@en[Define authentication entries a bit better https://www.w3.org/Bugs/Publi... · bffaa17 · whatwg/fetch]] ( ([TIME[2014-11-04 03:21:52 +09:00]] 版)) [414] [CITE[XEP-0070: Verifying HTTP Requests via XMPP]] ( ([TIME[2014-04-09 01:56:36 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [23] [CITE[HTTP authentication - The Chromium Projects]] ([TIME[2015-03-21 10:14:33 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [24] [CITE[HTTP authentication - The Chromium Projects]] ([TIME[2015-03-21 10:14:33 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [25] [CITE@en[Handling Authentication (Windows)]] ([TIME[2015-03-22 00:24:32 +09:00]] 版) [26] [CITE[Part3 - browsersec - Browser Security Handbook, part 3 - Browser Security Handbook - Google Project Hosting]] ([TIME[2015-03-31 16:50:41 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [27] [CITE@en[RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP)]] ([TIME[2015-03-26 07:39:15 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [29] [CITE@en[Bug 25791 – ''''''[''''''new feature'''''']'''''' Provide a way to opt out of authentication dialogs]] ([TIME[2015-06-11 12:56:55 +09:00]] 版) [41] [CITE@en[Fix #209: no credential prompt when credentials mode is not include · whatwg/fetch@10cb34f]] ([TIME[2016-01-30 12:27:47 +09:00]] 版) [42] [CITE@en[21013 – Credentials and HTTP authentication]] ([TIME[2016-03-15 11:40:54 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [43] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [44] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [45] [CITE@en[RFC 7030 - Enrollment over Secure Transport]] ([TIME[2016-06-19 16:27:56 +09:00]]) ]FIGCAPTION] > A client MAY set the username to the empty string ("") if it is > presenting a password that is not associated with a username. ]FIG] ** RFC 8053 [46] [DFN[RFC 8053]] は、 [[HTTP認証]]の拡張機能を提案するもので、 [TIME[2017年1月][2017-01]]に出版されました [SRC[>>47]]。 [REFS[ - [47] [CITE@en[RFC 8053 - HTTP Authentication Extensions for Interactive Clients]] ([TIME[2017-01-26 12:13:39 +09:00]]) ]REFS] [48] 現在主流の [[HTML]] [[フォーム]]ベースの[[認証]]には[[フィッシング]]などの問題があると指摘して、 新しい方法を提案しています。認証方式は既存の [[HTTP認証]]のものを流用しているものの、 新しい[[HTTPヘッダー]]を導入するなど既存の [[HTTP認証]]の方式との互換性はありません。 また、広く使われている[[フォーム]]や[[クッキー認証]]との互換性もありません。 [49] 主要な [[Webブラウザー]]は実装していませんし、 [[Webサーバー]]側の開発者にとっても既存の方式から乗り換えるだけのメリットがあるのかは謎です。 今後普及する見込みがあるのかどうかは不明です。 [50] [CITE@en[Use Fetch terminology for HTTP authentication.]] ([[mikewest]]著, [TIME[2017-03-24 18:21:25 +09:00]]) [51] [CITE@en[HTTP Authentication - WHATWG Wiki]] ([TIME[2017-09-09 06:04:47 +09:00]]) [52] [CITE@en[174179 - Re-Re-Think HTTP Basic Auth experience with respect to embedded content - chromium - Monorail]] ([TIME[2018-02-05 23:31:33 +09:00]]) [53] [CITE@en[Stop saying HTTP authentication over WebSocket is disallowed]] ([[ricea]]著, [TIME[2018-06-16 23:40:25 +09:00]]) [54] [CITE@en[WebSocket: "HTTP authentication will not function" is not correct · Issue #565 · whatwg/fetch]] ([TIME[2018-06-17 12:35:05 +09:00]]) [55] [CITE@en[Stop saying WebSocket auth is disallowed by ricea · Pull Request #761 · whatwg/fetch]] ([TIME[2018-06-17 12:35:36 +09:00]]) [66] [CITE[curl - How To Use]] ([TIME[2020-09-21T09:01:13.000Z]], [TIME[2020-10-01T06:20:28.221Z]]) [67] [CITE[curl - How To Use]] ([TIME[2020-09-21T09:01:13.000Z]], [TIME[2020-10-01T06:22:04.265Z]]) [68] [CITE@en[GNU Wget 1.20 Manual]] ([TIME[2020-10-01T07:23:55.000Z]]) [69] [CITE@EN-US[CACAO Security Playbooks Version 1.0]] ([TIME[2021-01-12T17:00:00.000Z]], [TIME[2021-08-19T04:21:56.548Z]])