[1] HTTP の基本認証
(Basic
) は、利用者名と合言葉を使った、
とても基本的な認証方式です。
[58] 基本認証は、クライアントから鯖に利用者の有する利用者識別子と合言葉の組 >>72 を送信し、鯖がこれを受け入れるかどうか判断する共有鍵による認証方式です。
[59] 本方式では、利用者名と合言葉の組が基本認証を使用するすべての HTTP要求において転送されることになります。
[99] クライアント (または利用者) は、 利用者名と合言葉を平文または復号可能な形で保持している必要があります。 鯖は、利用者名と合言葉を保持する必要がありますが、こちらはハッシュ化などを行って保存していても構いません。
[23] 一般には、利用者識別子も合言葉も、任意の不透明な文字列 (ないしバイト列) と解釈されています。 あり得る文字やバイトの制約や、 大文字・小文字その他の値の正規化の有無は、 サーバーの実装や設計・設定に依存します。
[60] 古くから広く行われている利用形態では、利用者本人 (または管理者等、いずれにせよ人間) が事前に登録した利用者名 (当該システム等のアカウント名などの記号列) と合言葉 (パスワード) を用います。この形態は HTTP 以外の多くのシステムでも基本的な認証方式としてよく用いられていますが、 合言葉の強度やソーシャルハッキングなどに関する運用上の脆弱性が指摘されています。
[62] 近年では Web API 等における認証方式として、機械的に生成された利用者名と合言葉の組を用いる場合も増えています。この場合は人間が利用することは想定されていないのが普通です。
[41] OAuth 2.0 クライアント認証としての基本認証では、
利用者名と合言葉は application/x-www-form-urlencoded
版パーセント符号化したものを使います。
[44] いくつかのWebアプリケーションの提供する Web API では、 利用者名を OAuth のアクセストークンやそれに相当する何らかの APIキー、 合言葉を空欄または何らかの固定の値として基本認証を使う認証方式 >>42 を採用しています。
[97] 利用者識別子と合言葉は、制御文字 (RFC 5234 CTL
= >>98)
を含んではなりません >>72。
[116] charset=""
引数の値 UTF-8
の項も参照。
auth-scheme
[2] 基本認証を表す auth-scheme
は Basic
です
>>72。
[8] 基本認証では realm
>>3, >>18
と charset
>>72 以外の auth-param
は使いません。
[76] 受信者は未知の引数を無視しなければなりません >>72。
realm
[6] 基本認証における realm
は、不透明な文字列として扱うべきものであり、
同じ鯖の別の realm
と等しさの比較のみができます。
>>3, >>18
[73] 仕様上は realm
は保護空間とも呼ばれており、
基本認証の名前と合言葉の組が適用される範囲を表すことになっています。
realm
を受信せずとも基本認証の credentials を要求で送信することがあるのですから、
保護空間ごとに名前と合言葉の組を使い分ける、というような使い方もされません。charset
引数[115] charset
引数は、 credentials
で使う文字コードのヒントを与えるものです >>72。
これはクライアントが使うべき文字コードをサーバーが指定するものですが、
強制するものではありませんから、クライアントがそれを使っているとは限りません。
[15] 基本認証の credentials は歴史的経緯により他の auth-scheme とは違う独自の構文になっています。
[16] 利用者IDと合言葉を :
で連結し、それを Base64 した文字列を credentials として使います。
[94] 利用者識別子と合言葉の符号化に使う文字コードについて、 RFC は、 US-ASCII と互換 (US-ASCII の文字が US-ASCII の文字コードと同じ1バイトで表されるよう) な何らかの文字コードが既定値である >>72 とされています。
[95] 元々文字コードが規定されておらず、 ISO-8859-1
、
UTF-8
その他のロケール依存の文字コードが使われてきたため、
それとの後方互換性のため、このように規定されています >>72。
[17] 旧 RFC の ABNF 構文上利用者IDと合言葉は HTTP の TEXT に制限されていますが、実際には鯖の既存のシステムの認証システムが流用されていることもしばしばあり、 非ASCII文字が含まれることもありました。
[20] それより前の RFC 1945 の定義では利用者IDは HTTP の token と、 更に制限されていました。
[117] サーバーは charset=""
引数でどう処理するかを表明できます
(>>115) が、クライアントがそれに対応しているとは限りません。
:
[101] credentials で Base64 復号した文字列においては、
最初の :
が利用者識別子と合言葉の区切りです >>72。
[10] その結果を credentials として要求の Authorization:
ヘッダーで送信します。
[12] 利用者ID が Aladdin
で合言葉が open sesame
であるとすると、 Authorization:
欄は
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==... となります >>3。
[63] Webブラウザーのような対話的な利用者エージェントでは、
401
応答を受けて認証情報の入力を利用者に求めるダイアログを表示し、
改めて要求を送信することができる実装形態になっているのが普通です。
[29] クライアントは、前に利用者から受け取った credentials を (条件が合えば) 再利用して自動的に要求に含めて送信することができます。
[65] Chrome や IE は、サーバーが複数の認証方式を示している場合、 基本認証は使用しません >>64。
[7] 鯖は、指定された利用者 ID と合言葉が当該 Request-URI の保護空間において妥当であると確認できる場合のみ、要求を認証します。
WWW-Authenticate: Basic realm="WallyWorld"... のように
realm
を指定した WWW-Authenticate:
欄を送ります。この realm
が当該 Request-URI
に対応する保護空間を表します。[85] サーバーは、保護空間内の URL に関する要求が適切な credentials
を欠いている場合には、 401
応答で
WWW-Authenticate:
ヘッダーを返すことができます >>72。
[86] プロキシは、保護空間内の URL に関する要求が適切な credentials
を欠いている場合には、 407
応答で
Proxy-Authenticate:
ヘッダーを返すことができます >>72。
[13] 基本認証は利用者のIDと合言葉を平文で送信するので、 安全でない通信路でやり取りするべきではありません >>72, >>24, >>32。
[14] 実装によっては HTTPS でない HTTP で基本認証に対応していません。
[25] しかし非常に手軽な認証方式であることから、現在でもよく用いられています。 一般に平文 HTTP での基本認証に対応しないクライアントは Web互換ではありません。
[46] 基本認証は Webブラウザーが標準で対応しており、 また一度認証すると自動的に同じ credentials が送信されるので、 CSRF に関しては認証がない Webページと同じ状態です。 基本認証があることを理由に CSRF 対策を省略することはできません。
userinfo
[96] 基本認証の利用者識別子と合言葉の組、または利用者識別子のみは、
http:
や https:
の URL
の userinfo
として記述されることがあります。
userinfo
参照。[33] Git over HTTPS using OAuth token · GitHub Help ( ( 版)) <https://help.github.com/articles/git-over-https-using-oauth-token>
[34] HTTP Authentication encoding test results ( (Bjoern Hoehrmann 著, 版)) <http://lists.w3.org/Archives/Public/www-archive/2014Feb/0014.html>
[80] RFC 723x では Basic
認証の定義は改訂されないままでしたが、
その後 RFC 7617 として出版されています。
[35] RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations ( ( 版)) <https://tools.ietf.org/html/rfc7236#section-3>
[36] draft-ietf-httpauth-basicauth-enc-03 - An Encoding Parameter for HTTP Basic Authentication ( ( 版)) <https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-03>
[37] draft-ietf-httpauth-basicauth-update-01 - The \x27Basic\x27 HTTP Authentication Scheme ( ( 版)) <https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01>
[38] Request Headers in the HTTP protocol ( ( 版)) <http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z9>
[107] 基本認証はクライアントにとってもサーバーにとっても極めて単純で、 広く実装されています。
[108] すべての要求で毎回認証が必要であること、 平文で合言葉を送信すること、 利用者インターフェイスのカスタマイズ性に乏しいことなどから、 Webアプリケーションの一般利用者向けの認証として用いられることはほとんどありません (Cookie認証が普通です)。しかし、 次のような場合に、基本認証が用いられます。
[111] 稀に、次のような目的で用いられることがあります。
[49] Twitter の API も当初は基本認証を使っていましたが、廃止されました。
[69] Internet Explorer では Web サイト アドレス (HTTP URL および HTTPS URL) に含まれるユーザー名およびパスワードがサポートされない ( 版) <https://support.microsoft.com/ja-jp/kb/834489>
[120] 41489 – HTTP authentication does not support non-ISO-8859-1 characters ( 版) <https://bugzilla.mozilla.org/show_bug.cgi?id=41489>
[128] 標準規格(放送分野)一覧表 () <http://www.arib.or.jp/tyosakenkyu/kikaku_hoso/hoso_kikaku_number.html>
[129] Support HTTP Basic auth for RTSP · Issue #510 · nmap/nmap () <https://github.com/nmap/nmap/issues/510>
[130] 435547 - Evaluate dropping legacy and credentialed subresource requests. - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=435547>
[131] 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>
[132] 504300 - Disallow requests with basic auth credentials in URL - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=504300>
[133] 707761 - Name and Password in XMLHttpRequest.open no longer work - chromium - Monorail () <https://bugs.chromium.org/p/chromium/issues/detail?id=707761>