[1] HTTP の基本ベーシック認証basic authentication (Basic) は、利用者名と合言葉を使った、 とても基本的な認証方式です。

仕様書

意味

[58] 基本認証は、クライアントから鯖に利用者の有する利用者識別子useridと合言葉passwordの組 >>72 を送信し、鯖がこれを受け入れるかどうか判断する共有鍵による認証方式です。

C
クライアント
S
鯖
C -> S
要求 (利用者識別子、合言葉)
S -> C
応答

[59] 本方式では、利用者名と合言葉の組が基本認証を使用するすべての HTTP要求において転送されることになります。

[61] このため、 HTTPS でない素の HTTP で基本認証を用いるのは安全ではありません。

[99] クライアント (または利用者) は、 利用者名と合言葉を平文または復号可能な形で保持している必要があります。 鯖は、利用者名と合言葉を保持する必要がありますが、こちらはハッシュ化などを行って保存していても構いません。

利用者識別子と合言葉

[23] 一般には、利用者識別子も合言葉も、任意の不透明な文字列 (ないしバイト列) と解釈されています。 あり得る文字やバイトの制約や、 大文字・小文字その他の値の正規化の有無は、 サーバーの実装や設計・設定に依存します。

[21] サーバーや資源によっては利用者識別子は大文字・小文字不区別かもしれません。>>18 合言葉も大文字・小文字不区別かもしれません。しかしクライアントは、 サーバーがどう解釈するか決められません。[22] 文字コードの節 (>>94) も参照。

[60] 古くから広く行われている利用形態では、利用者本人 (または管理者等、いずれにせよ人間) が事前に登録した利用者名 (当該システム等のアカウント名などの記号列) と合言葉 (パスワード) を用います。この形態は HTTP 以外の多くのシステムでも基本的な認証方式としてよく用いられていますが、 合言葉の強度やソーシャルハッキングなどに関する運用上の脆弱性が指摘されています。

[62] 近年では Web API 等における認証方式として、機械的に生成された利用者名と合言葉の組を用いる場合も増えています。この場合は人間が利用することは想定されていないのが普通です。

[41] OAuth 2.0 クライアント認証としての基本認証では、 利用者名と合言葉は application/x-www-form-urlencoded 版パーセント符号化したものを使います。

クライアント認証を参照。

[44] いくつかのWebアプリケーションの提供する Web API では、 利用者名を OAuth のアクセストークンやそれに相当する何らかの APIキー、 合言葉を空欄または何らかの固定の値として基本認証を使う認証方式 >>42 を採用しています。

[45] OAuth 2.0 Bearer 認証と実質的に等価ですが、 基本認証は Webブラウザーが対応しているという利点 (場合によっては欠点) があります。

[97] 利用者識別子と合言葉は、制御文字 (RFC 5234 CTL = >>98) を含んではなりません >>72。

[103] 仕様上禁止されていても、実装がどう扱っているのかは不明です。 少なくてもサーバーは、制御文字を受信した場合の処理を怠れません。

[116] charset="" 引数の値 UTF-8 の項も参照。

auth-scheme

[2] 基本認証を表す auth-scheme は Basic です >>72。

challenge

[8] 基本認証では realm >>3, >>18 と charset >>72 以外の auth-param は使いません。

[76] 受信者は未知の引数を無視しなければなりません >>72。

realm

[6] 基本認証における realm は、不透明な文字列として扱うべきものであり、 同じ鯖の別の realm と等しさequalityの比較のみができます。 >>3, >>18

[73] 仕様上は realm は保護空間とも呼ばれており、 基本認証の名前と合言葉の組が適用される範囲を表すことになっています。

[75] クライアントは、サーバーから応答で realm を受信せずとも基本認証の credentials を要求で送信することがあるのですから、 保護空間ごとに名前と合言葉の組を使い分ける、というような使い方もされません。

[74] 実際には realm は著者から利用者への短い説明文として使われています。

[77] realm 引数は必須です >>72。

[78] 指定されない場合に受信者がどうするべきかは不明です。[82] realm も参照。

charset 引数

[115] charset 引数は、 credentials で使う文字コードのヒントを与えるものです >>72。 これはクライアントが使うべき文字コードをサーバーが指定するものですが、 強制するものではありませんから、クライアントがそれを使っているとは限りません。

[79] charset 引数は、必須ではありません >>72。

[83] charset も参照。

credentials

[15] 基本認証の credentials は歴史的経緯により他の auth-scheme とは違う独自の構文になっています。

[84] RFC 7235 でいう token68 >>72 です。

[16] 利用者IDと合言葉を : で連結し、それを Base64 した文字列を credentials として使います。

[118] : があるので、 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) が、クライアントがそれに対応しているとは限りません。

charset=UTF-8 は NFC + UTF-8 を意味しています (UTF-8 参照)。実装が NFC を適用するかは謎です。

:

[101] credentials で Base64 復号した文字列においては、 最初の : が利用者識別子と合言葉の区切りです >>72。

[100] 利用者識別子が : を含むのは非妥当です >>72。

[102] この「非妥当」が何を意味するのかは不明です。 制御文字は禁止 (>>97) されていて、 : は非妥当ですが、 その違いも不明です。

[104] 多くの利用者エージェントは、利用者識別子に : が含まれるかどうかを検査しません >>72。

[105] サーバーが : を含む利用者識別子を発行する可能性もあります。 サーバーは >>89 のクライアントの符号化と同じ方法で Base64 符号化し、その結果を比較するのであれば、 : を含む利用者識別子も扱えます。 (ただしその場合、異なる利用者識別子であっても合言葉との組み合わせによっては一致してしまう危険性があります。)

クライアントの処理

[89] クライアントは、次のようにします >>72。

  1. [90] 利用者から利用者識別子と合言葉を得ます。
  2. [91] 利用者識別子、:、合言葉を連結します。
  3. [92] それをバイト列に符号化します。
  4. [93] それを RFC 4648 Base64 符号化し、 ASCII文字列とします。

[10] その結果を credentials として要求の Authorization: ヘッダーで送信します。

[12] 利用者ID が Aladdin で合言葉が open sesame であるとすると、 Authorization: 欄は

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
... となります >>3。

[63] Webブラウザーのような対話的な利用者エージェントでは、 401 応答を受けて認証情報の入力を利用者に求めるダイアログを表示し、 改めて要求を送信することができる実装形態になっているのが普通です。

HTTP認証も参照。

[29] クライアントは、前に利用者から受け取った credentials を (条件が合えば) 再利用して自動的に要求に含めて送信することができます。

[119] credentials も参照。

[65] Chrome や IE は、サーバーが複数の認証方式を示している場合、 基本認証は使用しません >>64。

[88] HTTP認証も参照。

サーバーの処理

[7] 鯖は、指定された利用者 ID と合言葉が当該 Request-URI の保護空間において妥当であると確認できる場合のみ、要求を認証します。

[9] 認証できない要求に対して鯖は

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。

[87] HTTP認証も参照。[106] Base64 のバリエーション

通信路の安全性と基本認証

[13] 基本認証は利用者のIDと合言葉を平文で送信するので、 安全でない通信路でやり取りするべきではありません >>72, >>24, >>32。

[30] Base64 によって事故により合言葉を人間に傍受されることは防げますが、 悪意を持って合言葉や credentials を盗もうとするものには対抗できません。

[14] 実装によっては HTTPS でない HTTP で基本認証に対応していません。

[25] しかし非常に手軽な認証方式であることから、現在でもよく用いられています。 一般に平文 HTTP での基本認証に対応しないクライアントは Web互換ではありません。

[40] WebDAV の鯖とクライアントは、保安接続を除き、 基本認証を使ってはなりません >>39。

[56] IPP/1.1 印刷機は保安通信路において基本認証に対応できます >>55。

[57] それ以外での基本認証の利用は明示的には禁止されていませんが...

CSRF

[46] 基本認証は Webブラウザーが標準で対応しており、 また一度認証すると自動的に同じ credentials が送信されるので、 CSRF に関しては認証がない Webページと同じ状態です。 基本認証があることを理由に CSRF 対策を省略することはできません。

URL userinfo

[96] 基本認証の利用者識別子と合言葉の組、または利用者識別子のみは、 http: や https: の URL の userinfo として記述されることがあります。

userinfo 参照。

二段階認証の拡張

[47] GitHub は二段階認証のために追加のヘッダーを導入しています。

[43] Other Authentication Methods | GitHub API ( 版) https://developer.github.com/v3/auth/

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.

関連

[114] APIキー的なものは Bearer 認証方式がより適切なこともあります。

歴史

RFC

  • [3] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-11.1
  • [18] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-11.1
  • [24] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-15.1
  • [26] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-2
    • [27] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-2
    • [32] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-4.1

[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

[19] RFC 2068 における 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
[28] RFC 2617 の定義もこれと等価です。
[11] RFC 1945 における 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

RFC 761x

[80] RFC 723x では Basic 認証の定義は改訂されないままでしたが、 その後 RFC 7617 として出版されています。

[81] 新たに charset 引数が追加されています。

[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 も当初は基本認証を使っていましたが、廃止されました。

[42] Other Authentication Methods | GitHub API ( 版) https://developer.github.com/v3/auth/

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.

[48] Use the Bitbucket REST APIs - Bitbucket - Atlassian Documentation ( 版) https://confluence.atlassian.com/display/BITBUCKET/Use+the+Bitbucket+REST+APIs#UsetheBitbucketRESTAPIs-Authentication

If you are testing an application, you can use a client such as cURL together with basic authentication (username/password).

[50] はてなハイク REST API - Hatena Developer Center ( 版) http://developer.hatena.ne.jp/ja/documents/haiku/apis/rest#auth-basic

HTTP で定められている基本 (basic) 認証も利用できます。ユーザ名にはてなIDを、パスワードには投稿用アドレス (...@h.hatena.ne.jp のもの) を指定します。安全性考慮のため通常のはてなのパスワードではないのでご注意ください。

基本 (basic) 認証の利用は非推奨となっております。

[51] Heroku API ( 版) https://legacy-api-docs.herokuapp.com/

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.

[52] API | Snap CI | Hosted Continuous Integration ( 版) https://docs.snap-ci.com/api/

Snap uses basic authentication. To authenticate you need to provide your username and API key.

[53] WooCommerce REST API Documentation v2 ( 版) http://woothemes.github.io/woocommerce-rest-api-docs/#authentication

You may use HTTP Basic Auth by providing the API Consumer Key as the username and the API Consumer Secret as the password.

[54] API Basics — Scrapinghub documentation ( 版) http://doc.scrapinghub.com/api.html

using HTTP basic auth:

$ curl -u APIKEY: https://storage.scrapinghub.com/foo

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

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).

[67] Deploy to Heroku | Codeship Documentation ( 版) https://codeship.com/documentation/continuous-deployment/deployment-to-heroku/

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

[68] REST API Developers Guide | Parse ( 版) https://parse.com/docs/rest/guide/

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

[70] Stripe API Reference ( 版) https://stripe.com/docs/api#authentication

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.

[71] Helpdesk API ( 版) https://www.jitbit.com/web-helpdesk/helpdesk-api/

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".

[31] 41489 – HTTP authentication does not support non-ISO-8859-1 characters ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=41489

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

[121] Introduction — Mailgun API documentation ( 版) https://documentation.mailgun.com/api-intro.html#authentication

Authentication to the API occurs via HTTP Basic Auth. Use api as the user name and your API key is the password.

[122] Java 8リリースの変更 ( ()) https://www.java.com/ja/download/faq/release_changes.xml

HTTPSのトンネルの設定時にBasic認証を必要とするプロキシは、デフォルトでは成功しないようになりました。必要な場合、jdk.http.auth.tunneling.disabledSchemesネットワーク・プロパティからBasicを削除するか、コマンド行で同じ名前のシステム・プロパティを"" (空)に設定することで、この認証スキームを再度アクティブ化できます。

[123] Stripe API Reference () https://stripe.com/docs/api#authentication

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.

[124] rest-api-doc/deposit_api.md at master · CrossRef/rest-api-doc () https://github.com/CrossRef/rest-api-doc/blob/master/deposit_api.md

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.

[125] CircleCI API v1.1 Reference - CircleCI () https://circleci.com/docs/api/v1-reference/

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.)

[126] はてなブログAtomPub - Hatena Developer Center () http://developer.hatena.ne.jp/ja/documents/blog/apis/atom

2013年10月17日 Basic認証に対応/APIのエンドポイントをhttpsに変更(Basic認証が利用できないことを除いて、httpのエンドポイントも引き続き利用できます)

[127] Bitbucket API () https://developer.atlassian.com/bitbucket/api/2/reference/meta/authentication

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

[134] GitHub アプリのアクセス許可を選択する - GitHub Enterprise Server 3.13 Docs () https://docs.github.com/ja/enterprise-server@3.13/apps/creating-github-apps/registering-a-github-app/choosing-permissions-for-a-github-app

その後は、アクセス トークンを HTTP パスワードとして使うことができます。 TOKEN は、アクセス トークンに置き換えます。

git clone https://x-access-token:TOKEN@github.com/owner/repo.git