[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
参照。[47] GitHub は二段階認証のために追加のヘッダーを導入しています。
For users with two-factor authentication enabled, Basic Authentication requires an extra step. When you attempt to authenticate with Basic Authentication, the server will respond with a 401 and an X-GitHub-OTP: required; :2fa-type header. This indicates that a two-factor authentication code is needed (in addition to the username and password). The :2fa-type in this header indicates whether the account receives its two-factor authentication codes via SMS or via an application.
In addition to the Basic Authentication credentials, you must send the user’s authentication code (i.e., one-time password) in the X-GitHub-OTP header. Because these authentication codes expire quickly, we recommend using the Authorizations API to create an access token and using that token to authenticate via OAuth for most API access.
[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
Basic
認証の credentials の構文basic-credentials = "Basic" SP basic-cookie basic-cookie = <base64 [7] encoding of user-pass, except not limited to 76 char/line> user-pass = userid ":" password userid = *<TEXT excluding ":"> password = *TEXT
Basic
認証の credentials の構文basic-credentials = "Basic" SP basic-cookie basic-cookie = <base64 [5] encoding of userid-password, except not limited to 76 char/line> userid-password = [ token ] ":" *TEXT
[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 も当初は基本認証を使っていましたが、廃止されました。
you can authenticate using personal access tokens or OAuth tokens. To do so, provide the token as the username and provide a blank password or a password of x-oauth-basic.
If you are testing an application, you can use a client such as cURL together with basic authentication (username/password).
HTTP で定められている基本 (basic) 認証も利用できます。ユーザ名にはてなIDを、パスワードには投稿用アドレス (...@h.hatena.ne.jp のもの) を指定します。安全性考慮のため通常のはてなのパスワードではないのでご注意ください。
基本 (basic) 認証の利用は非推奨となっております。
Authentication to the Heroku API is accomplished using an API key, available on the My Account page.
Once you have an API key, use HTTP Basic Authentication with a blank username and the API key as a password.
Snap uses basic authentication. To authenticate you need to provide your username and API key.
You may use HTTP Basic Auth by providing the API Consumer Key as the username and the API Consumer Secret as the password.
using HTTP basic auth:
$ curl -u APIKEY: https://storage.scrapinghub.com/foo
If the "basic" scheme is used, HTTP
over TLS [RFC2818] MUST be used to protect the client's credentials
from disclosure while in transit (see Section 3.5).
After each deployment we check if your app is up. Therefore we call (wget) either the default *.herokuapp.com URL or the URL you specified here.
If this URL requires basic auth please enter: http://YOUR_USERNAME:YOUR_PASSWORD@YOUR_URL
You may also authenticate your REST API requests using basic HTTP authentication. For example, to retrieve an object you could set the URL using your Parse credentials in the following format:
https://myAppID:javascript-key=myJavaScriptKey@api.parse.com/1/classes/GameScore/Ed1nuqPvcm
[69] Internet Explorer では Web サイト アドレス (HTTP URL および HTTPS URL) に含まれるユーザー名およびパスワードがサポートされない ( 版) https://support.microsoft.com/ja-jp/kb/834489
Authentication to the API occurs via HTTP Basic Auth. Provide your API key as the basic auth username. You do not need to provide a password.
NOTE: even if you use Windows authentication with your local helpdesk install you still have to use Basic auth headers! And pas your Windows usernames and passwords. And don't forget to include the user's domain into the username like this "DOMAIN\Username".
Opera and Chromium(they just send the username as byte utf8 without transport encoding)
[120] 41489 – HTTP authentication does not support non-ISO-8859-1 characters ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=41489
Authentication to the API occurs via HTTP Basic Auth. Use api as the user name and your API key is the password.
HTTPSのトンネルの設定時にBasic認証を必要とするプロキシは、デフォルトでは成功しないようになりました。必要な場合、jdk.http.auth.tunneling.disabledSchemesネットワーク・プロパティからBasicを削除するか、コマンド行で同じ名前のシステム・プロパティを"" (空)に設定することで、この認証スキームを再度アクティブ化できます。
Authentication to the API is performed via HTTP Basic Auth. Provide your API key as the basic auth username value. You do not need to provide a password.
All routes described in this document require authentication using CrossRef member credentials. These must be supplied on each requests using the HTTP basic authentication scheme.
you can use the API token as the username for HTTP Basic Authentication, by passing the -u flag to the curl command, like so:
curl -u <circle-token>: https://circleci.com/api/...
(Note the colon :, which tells curl that there’s no password.)
2013年10月17日 Basic認証に対応/APIのエンドポイントをhttpsに変更(Basic認証が利用できないことを除いて、httpのエンドポイントも引き続き利用できます)
Since add-ons will not be able to upload their own SSH keys to clone with, access tokens can be used as Basic HTTP Auth credentials to clone securely over HTTPS. This is much like GitHub, yet slightly different:
$ git clone https://x-token-auth:{access_token}@bitbucket.org/user/repo.git
The literal string x-token-auth as a substitute for username is required (note the difference with GitHub where the actual token is in the username field).
[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
その後は、アクセス トークンを HTTP パスワードとして使うことができます。 TOKEN は、アクセス トークンに置き換えます。
git clone https://x-access-token:TOKEN@github.com/owner/repo.git