[1] [[HTTP]] の[DFN[[RUBYB[[RUBY[基本][ベーシック]]認証]@en[basic authentication]]]] ([DFN[[CODE(HTTP)@en[[[Basic]]]]]]) は、[[利用者名]]と[[合言葉]]を使った、 とても基本的な[[認証]]方式です。 * 仕様書 [REFS[ - [72] '''[CITE@en[RFC 7617 - The 'Basic' HTTP Authentication Scheme]] ([TIME[2015-10-01 09:47:40 +09:00]] 版) ''' - [4] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) - [39] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) - [55] [CITE@en[RFC 2910 - Internet Printing Protocol/1.1: Encoding and Transport]] ([TIME[2015-02-15 15:24:06 +09:00]] 版) ]REFS] * 意味 [58] [[基本認証]]は、[[クライアント]]から[[鯖]]に[[利用者]]の有する[RUBYB[[[利用者識別子]]]@en[userid]]と[RUBYB[[[合言葉]]]@en[password]]の組 [SRC[>>72]] を送信し、[[鯖]]がこれを受け入れるかどうか判断する共有鍵による認証方式です。 [FIG(sequence)[ :C:[[クライアント]] :S:[[鯖]] :C -> S:[[要求]] ([[利用者識別子]]、[[合言葉]]) :S -> C:[[応答]] ]FIG] [59] 本方式では、[[利用者名]]と[[合言葉]]の組が[[基本認証]]を使用するすべての [[HTTP要求]]において転送されることになります。 ;; [61] このため、 [[HTTPS]] でない素の [[HTTP]] で[[基本認証]]を用いるのは安全ではありません。 [99] [[クライアント]] (または[[利用者]]) は、 [[利用者名]]と[[合言葉]]を[[平文]]または[[復号]]可能な形で保持している必要があります。 [[鯖]]は、[[利用者名]]と[[合言葉]]を保持する必要がありますが、こちらは[[ハッシュ化]]などを行って保存していても構いません。 * 利用者識別子と合言葉 [23] 一般には、[[利用者識別子]]も[[合言葉]]も、任意の[[不透明]]な[[文字列]] (ないし[[バイト列]]) と解釈されています。 あり得る[[文字]]や[[バイト]]の制約や、 [[大文字]]・[[小文字]]その他の値の[[正規化]]の有無は、 [[サーバー]]の実装や設計・設定に依存します。 ;; [21] [[サーバー]]や[[資源]]によっては[[利用者識別子]]は[[大文字・小文字不区別]]かもしれません。[SRC[>>18]] [[合言葉]]も[[大文字・小文字不区別]]かもしれません。しかし[[クライアント]]は、 [[サーバー]]がどう解釈するか決められません。 ;; [22] [[文字コード]]の節 (>>94) も参照。 [60] 古くから広く行われている利用形態では、[[利用者]]本人 (または[[管理者]]等、いずれにせよ人間) が事前に登録した[[利用者名]] (当該システム等の[[アカウント]]名などの記号列) と[[合言葉]] ([[パスワード]]) を用います。この形態は [[HTTP]] 以外の多くのシステムでも基本的な認証方式としてよく用いられていますが、 [[合言葉]]の強度や[[ソーシャルハッキング]]などに関する運用上の脆弱性が指摘されています。 [62] 近年では [[Web API]] 等における認証方式として、機械的に生成された[[利用者名]]と[[合言葉]]の組を用いる場合も増えています。この場合は人間が利用することは想定されていないのが普通です。 [41] [[OAuth 2.0]] [[クライアント認証]]としての[[基本認証]]では、 [[利用者名]]と[[合言葉]]は [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]] 版[[パーセント符号化]]したものを使います。 ;; [[クライアント認証]]を参照。 [44] いくつかの[[Webアプリケーション]]の提供する [[Web API]] では、 [[利用者名]]を [[OAuth]] の[[アクセストークン]]やそれに相当する何らかの [[APIキー]]、 [[合言葉]]を空欄または何らかの固定の値として[[基本認証]]を使う[[認証]]方式 [SRC[>>42]] を採用しています。 ;; [45] [[OAuth 2.0]] [CODE(HTTP)@en[[[Bearer]]]] 認証と実質的に等価ですが、 [[基本認証]]は [[Webブラウザー]]が対応しているという利点 (場合によっては欠点) があります。 [97] [[利用者識別子]]と[[合言葉]]は、[[制御文字]] ([[RFC 5234]] [CODE[[[CTL]]]] = >>98) を含んでは[['''なりません''']] [SRC[>>72]]。 [REFS[ - [98] [CITE@en[Character set "CTL"]] ([TIME[2015-11-12 16:04:42 +09:00]] 版) ]REFS] ;; [103] 仕様上禁止されていても、実装がどう扱っているのかは不明です。 少なくても[[サーバー]]は、[[制御文字]]を受信した場合の処理を怠れません。 [116] [CODE(HTTP)@en[[[charset=""]]]] [[引数]]の値 [CODE(charset)@en[[[UTF-8]]]] の項も参照。 * [CODE(HTTP)@en[auth-scheme]] [2] [[基本認証]]を表す [CODE(HTTP)@en[[[auth-scheme]]]] は [DFN[[CODE(HTTP)[[[Basic]]]]]] です [SRC[>>72]]。 * challenge [8] [[基本認証]]では [CODE(HTTP)@en[[[realm]]]] [SRC[>>3, >>18]] と [CODE(HTTP)@en[[[charset]]]] [SRC[>>72]] 以外の [CODE(ABNF)@en[[[auth-param]]]] は使いません。 [76] [[受信者]]は未知の[[引数]]を無視しなければ[['''なりません''']] [SRC[>>72]]。 ** [CODE(HTTP)@en[realm]] [6] [[基本認証]]における [CODE(HTTP)@en[[[realm]]]] は、[[不透明]]な文字列として扱うべきものであり、 同じ[[鯖]]の別の [CODE(HTTP)@en[[[realm]]]] と[RUBYB[等しさ]@en[equality]]の比較のみができます。 [SRC[>>3, >>18]] [73] 仕様上は [CODE(HTTP)@en[[[realm]]]] は[[保護空間]]とも呼ばれており、 [[基本認証]]の名前と合言葉の組が適用される範囲を表すことになっています。 ;; [75] [[クライアント]]は、[[サーバー]]から[[応答]]で [CODE[[[realm]]]] を受信せずとも[[基本認証]]の [[credentials]] を[[要求]]で送信することがあるのですから、 [[保護空間]]ごとに名前と合言葉の組を使い分ける、というような使い方もされません。 [74] 実際には [CODE[[[realm]]]] は[[著者]]から[[利用者]]への短い説明文として使われています。 [77] [CODE(HTTP)@en[[[realm]]]] [[引数]]は必須です [SRC[>>72]]。 ;; [78] 指定されない場合に[[受信者]]がどうするべきかは不明です。 ;; [82] [CODE(HTTP)@en[[[realm]]]] も参照。 ** [CODE(HTTP)@en[charset]] 引数 [115] [CODE(HTTP)@en[[[charset]]]] [[引数]]は、 [[credentials]] で使う[[文字コード]]の[[ヒント]]を与えるものです [SRC[>>72]]。 これは[[クライアント]]が使うべき[[文字コード]]を[[サーバー]]が指定するものですが、 強制するものではありませんから、[[クライアント]]がそれを使っているとは限りません。 [79] [CODE(HTTP)@en[[[charset]]]] [[引数]]は、必須ではありません [SRC[>>72]]。 ;; [83] [CODE(HTTP)@en[[[charset]]]] も参照。 * credentials [15] [[基本認証]]の [[credentials]] は[[歴史的経緯]]により他の [[auth-scheme]] とは違う独自の構文になっています。 ;; [84] [[RFC 7235]] でいう [CODE(ABNF)@en[[[token68]]]] [SRC[>>72]] です。 [16] [[利用者]]IDと[[合言葉]]を [CODE(char)[[[:]]]] で連結し、それを [[Base64]] した文字列を [[credentials]] として使います。 ;; [118] [CODE[[[:]]]] があるので、 [[credentials]] が空になることはありません。 ** 文字コード [94] [[利用者識別子]]と[[合言葉]]の[[符号化]]に使う[[文字コード]]について、 [[RFC]] は、 [[US-ASCII]] と互換 ([[US-ASCII]] の[[文字]]が [[US-ASCII]] の[[文字コード]]と同じ1バイトで表されるよう) な何らかの[[文字コード]]が既定値である [SRC[>>72]] とされています。 [HISTORY[ [95] 元々[[文字コード]]が規定されておらず、 [CODE[[[ISO-8859-1]]]]、 [CODE[[[UTF-8]]]] その他の[[ロケール]]依存の[[文字コード]]が使われてきたため、 それとの[[後方互換性]]のため、このように規定されています [SRC[>>72]]。 [17] 旧 [[RFC]] の [[ABNF]] 構文上[[利用者]]IDと[[合言葉]]は [[HTTP]] の [[TEXT]] に制限されていますが、実際には[[鯖]]の既存のシステムの認証システムが流用されていることもしばしばあり、 [[非ASCII文字]]が含まれることもありました。 [20] それより前の [[RFC 1945]] の定義では[[利用者]]IDは [[HTTP]] の [[token]] と、 更に制限されていました。 ]HISTORY] [117] [[サーバー]]は [CODE(HTTP)@en[[[charset=""]]]] [[引数]]でどう処理するかを表明できます (>>115) が、[[クライアント]]がそれに対応しているとは限りません。 ;; [CODE(HTTP)@en[[[charset]]=[[UTF-8]]]] は [[NFC]] + [[UTF-8]] を意味しています ([[UTF-8]] 参照)。実装が [[NFC]] を適用するかは謎です。 ** [CODE[:]] [101] [[credentials]] で [[Base64]] [[復号]]した文字列においては、 最初の [CODE[[[:]]]] が[[利用者識別子]]と[[合言葉]]の区切りです [SRC[>>72]]。 [100] [[利用者識別子]]が [CODE[[[:]]]] を含むのは[[非妥当]]です [SRC[>>72]]。 ;; [102] この「[[非妥当]]」が何を意味するのかは不明です。 [[制御文字]]は禁止 (>>97) されていて、 [CODE[[[:]]]] は[[非妥当]]ですが、 その違いも不明です。 [104] 多くの[[利用者エージェント]]は、[[利用者識別子]]に [CODE[[[:]]]] が含まれるかどうかを検査しません [SRC[>>72]]。 ;; [105] [[サーバー]]が [CODE[[[:]]]] を含む[[利用者識別子]]を発行する可能性もあります。 [[サーバー]]は >>89 の[[クライアント]]の符号化と同じ方法で [[Base64]] [[符号化]]し、その結果を比較するのであれば、 [CODE[[[:]]]] を含む[[利用者識別子]]も扱えます。 (ただしその場合、異なる[[利用者識別子]]であっても[[合言葉]]との組み合わせによっては一致してしまう危険性があります。) * クライアントの処理 [89] [[クライアント]]は、次のようにします [SRC[>>72]]。 [FIG(steps)[ = [90] [[利用者]]から[[利用者識別子]]と[[合言葉]]を得ます。 = [91] [[利用者識別子]]、[CODE[[[:]]]]、[[合言葉]]を連結します。 = [92] それを[[バイト列]]に[[符号化]]します。 = [93] それを [[RFC 4648]] [[Base64]] [[符号化]]し、 [[ASCII文字列]]とします。 ]FIG] [10] その結果を [[credentials]] として[[要求]]の [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]で送信します。 [EG[ [12] [[利用者]]ID が [CODE[Aladdin]] で[[合言葉]]が [CODE[open sesame]] であるとすると、 [CODE(HTTP)@en[[[Authorization:]]]] 欄は [PRE(HTTP code)[ Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== ]PRE] ... となります [SRC[>>3]]。 ]EG] [63] [[Webブラウザー]]のような[[対話的]]な[[利用者エージェント]]では、 [CODE(HTTP)[[[401]]]] [[応答]]を受けて[[認証]]情報の入力を[[利用者]]に求める[[ダイアログ]]を表示し、 改めて[[要求]]を送信することができる実装形態になっているのが普通です。 ;; [[HTTP認証]]も参照。 [29] [[クライアント]]は、前に[[利用者]]から受け取った [[credentials]] を (条件が合えば) 再利用して自動的に[[要求]]に含めて送信することができます。 ;; [119] [[credentials]] も参照。 [65] [[Chrome]] や [[IE]] は、[[サーバー]]が複数の[[認証方式]]を示している場合、 [[基本認証]]は使用しません [SRC[>>64]]。 [REFS[ - [64] [CITE[HTTP authentication - The Chromium Projects]] ([TIME[2015-03-21 10:14:33 +09:00]] 版) ]REFS] ;; [88] [[HTTP認証]]も参照。 * サーバーの処理 [7] [[鯖]]は、指定された[[利用者]] ID と[[合言葉]]が当該 [[Request-URI]] の保護空間において妥当であると確認できる場合のみ、[[要求]]を[[認証]]します。 [EG[ [9] [[認証]]できない[[要求]]に対して[[鯖]]は [PRE(HTTP code)[ WWW-Authenticate: Basic realm="WallyWorld" ]PRE] ... のように [CODE(HTTP)@en[[[realm]]]] を指定した [CODE(HTTP)@en[[[WWW-Authenticate:]]]] 欄を送ります。この [CODE(HTTP)@en[[[realm]]]] が当該 [[Request-URI]] に対応する保護空間を表します。 ]EG] [85] [[サーバー]]は、[[保護空間]]内の [[URL]] に関する[[要求]]が適切な [[credentials]] を欠いている場合には、 [CODE(HTTP)[[[401]]]] [[応答]]で [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]を返すことができます [SRC[>>72]]。 [86] [[プロキシ]]は、[[保護空間]]内の [[URL]] に関する[[要求]]が適切な [[credentials]] を欠いている場合には、 [CODE(HTTP)[[[407]]]] [[応答]]で [CODE(HTTP)@en[[[Proxy-Authenticate:]]]] [[ヘッダー]]を返すことができます [SRC[>>72]]。 ;; [87] [[HTTP認証]]も参照。 @@ [106] [[Base64]] のバリエーション * 通信路の安全性と基本認証 [13] [[基本認証]]は[[利用者]]のIDと[[合言葉]]を[[平文]]で送信するので、 安全でない[[通信路]]でやり取りする[['''べきではありません''']] [SRC[>>72, >>24, >>32]]。 ;; [30] [[Base64]] によって事故により[[合言葉]]を人間に傍受されることは防げますが、 悪意を持って[[合言葉]]や [[credentials]] を盗もうとするものには対抗できません。 [14] 実装によっては [[HTTPS]] でない [[HTTP]] で[[基本認証]]に対応していません。 [25] しかし非常に手軽な認証方式であることから、現在でもよく用いられています。 一般に[[平文]] [[HTTP]] での[[基本認証]]に対応しない[[クライアント]]は [[Web互換]]ではありません。 [40] [[WebDAV]] の[[鯖]]と[[クライアント]]は、[[保安接続]]を除き、 [[基本認証]]を使っては[['''なりません''']] [SRC[>>39]]。 [56] [[IPP/1.1]] [[印刷機]]は[[保安通信路]]において[[基本認証]]に対応できます [SRC[>>55]]。 ;; [57] それ以外での[[基本認証]]の利用は明示的には禁止されていませんが... * CSRF [46] [[基本認証]]は [[Webブラウザー]]が標準で対応しており、 また一度[[認証]]すると自動的に同じ [[credentials]] が送信されるので、 [[CSRF]] に関しては[[認証]]がない [[Webページ]]と同じ状態です。 [[基本認証]]があることを理由に [[CSRF]] 対策を省略することはできません。 * URL [CODE[userinfo]] [96] [[基本認証]]の[[利用者識別子]]と[[合言葉]]の組、または[[利用者識別子]]のみは、 [CODE(URI)@en[[[http:]]]] や [CODE(URI)@en[[[https:]]]] の [[URL]] の [CODE[[[userinfo]]]] として記述されることがあります。 ;; [CODE[[[userinfo]]]] 参照。 * 二段階認証の拡張 [47] [[GitHub]] は[[二段階認証]]のために追加の[[ヘッダー]]を導入しています。 [FIG(quote)[ [FIGCAPTION[ [43] [CITE@en[Other Authentication Methods | GitHub API]] ([TIME[2015-02-05 07:24:20 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] * 関連 [114] [[APIキー]]的なものは [CODE(HTTP)@en[[[Bearer]]]] [[認証方式]]がより適切なこともあります。 * 歴史 ** RFC [REFS[ - [3] [CITE@en[RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0]] ([TIME[2012-02-18 23:25:56 +09:00]] 版) - [18] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) - [24] [CITE@en[RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2012-02-18 23:30:14 +09:00]] 版) - [26] '''[CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) ''' -- [27] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) -- [32] [CITE@en[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication]] ([TIME[2012-01-09 21:04:30 +09:00]] 版) ]REFS] [33] [CITE[Git over HTTPS using OAuth token · GitHub Help]] ( ([TIME[2013-04-25 05:34:46 +09:00]] 版)) [34] [CITE@en[HTTP Authentication encoding test results]] ( ([[Bjoern Hoehrmann]] 著, [TIME[2014-02-15 00:18:19 +09:00]] 版)) [FIG(quote)[ [FIGCAPTION[ [19] [[RFC 2068]] における [CODE(HTTP)@en[[[Basic]]]] 認証の [[credentials]] の構文 ]FIGCAPTION] [PRE(ABNF code)[ basic-credentials = "Basic" SP basic-cookie basic-cookie = user-pass = userid ":" password userid = * password = *TEXT ]PRE] ;; [28] [[RFC 2617]] の定義もこれと等価です。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [11] [[RFC 1945]] における [CODE(HTTP)@en[[[Basic]]]] 認証の [[credentials]] の構文 ]FIGCAPTION] [PRE(ABNF code)[ basic-credentials = "Basic" SP basic-cookie basic-cookie = userid-password = [ token ] ":" *TEXT ]PRE] ]FIG] ** RFC 761x [80] [[RFC 723x]] では [CODE(HTTP)@en[[[Basic]]]] 認証の定義は改訂されないままでしたが、 その後 [DFN[[[RFC 7617]]]] として出版されています。 [81] 新たに [CODE(HTTP)@en[[[charset]]]] [[引数]]が追加されています。 [35] [CITE@en[RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations]] ( ([TIME[2014-09-10 00:40:16 +09:00]] 版)) [36] [CITE@en[draft-ietf-httpauth-basicauth-enc-03 - An Encoding Parameter for HTTP Basic Authentication]] ( ([TIME[2014-10-16 11:44:39 +09:00]] 版)) [37] [CITE@en[draft-ietf-httpauth-basicauth-update-01 - The \x27Basic\x27 HTTP Authentication Scheme]] ( ([TIME[2014-10-16 11:44:39 +09:00]] 版)) [38] [CITE[Request Headers in the HTTP protocol]] ( ([TIME[2001-11-29 20:01:38 +09:00]] 版)) * 実装 [107] [[基本認証]]は[[クライアント]]にとっても[[サーバー]]にとっても極めて単純で、 広く実装されています。 [108] すべての[[要求]]で毎回[[認証]]が必要であること、 [[平文]]で[[合言葉]]を送信すること、 [[利用者インターフェイス]]のカスタマイズ性に乏しいことなどから、 [[Webアプリケーション]]の一般利用者向けの認証として用いられることはほとんどありません ([[Cookie認証]]が普通です)。しかし、 次のような場合に、[[基本認証]]が用いられます。 [FIG(list)[ - [109] 限られた[[利用者]]のみが用いるもの (管理画面、開発サーバー等) - [110] [[Web API]] - [113] 専用クライアント向け[[資源]] ([[WebDAV]], [[Git]] など) ]FIG] [111] 稀に、次のような目的で用いられることがあります。 [FIG(list)[ - [112] [[ロボット]]によるアクセスの拒絶 ]FIG] [49] [[Twitter]] の [[API]] も当初は[[基本認証]]を使っていましたが、廃止されました。 [FIG(quote)[ [FIGCAPTION[ [42] [CITE@en[Other Authentication Methods | GitHub API]] ([TIME[2015-02-05 07:24:20 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [48] [CITE[Use the Bitbucket REST APIs - Bitbucket - Atlassian Documentation]] ([TIME[2015-03-05 18:49:57 +09:00]] 版) ]FIGCAPTION] > If you are testing an application, you can use a client such as cURL together with basic authentication (username/password). ]FIG] [FIG(quote)[ [FIGCAPTION[ [50] [CITE[はてなハイク REST API - Hatena Developer Center]] ([TIME[2015-03-05 18:51:22 +09:00]] 版) ]FIGCAPTION] > HTTP で定められている基本 (basic) 認証も利用できます。ユーザ名にはてなIDを、パスワードには投稿用アドレス (...@h.hatena.ne.jp のもの) を指定します。安全性考慮のため通常のはてなのパスワードではないのでご注意ください。 > 基本 (basic) 認証の利用は非推奨となっております。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [51] [CITE@en[Heroku API]] ([TIME[2015-03-06 08:12:19 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [52] [CITE[API | Snap CI | Hosted Continuous Integration]] ([TIME[2015-03-04 01:09:13 +09:00]] 版) ]FIGCAPTION] > Snap uses basic authentication. To authenticate you need to provide your username and API key. ]FIG] [FIG(quote)[ [FIGCAPTION[ [53] [CITE[WooCommerce REST API Documentation v2]] ([TIME[2015-03-11 03:10:19 +09:00]] 版) ]FIGCAPTION] > You may use HTTP Basic Auth by providing the API Consumer Key as the username and the API Consumer Secret as the password. ]FIG] [FIG(quote)[ [FIGCAPTION[ [54] [CITE[API Basics — Scrapinghub documentation]] ([TIME[2015-03-05 23:55:58 +09:00]] 版) ]FIGCAPTION] > using HTTP basic auth: > $ curl -u APIKEY: https://storage.scrapinghub.com/foo ]FIG] [FIG(quote)[ [FIGCAPTION[ [66] [CITE@en[RFC 7481 - Security Services for the Registration Data Access Protocol (RDAP)]] ([TIME[2015-03-26 07:39:15 +09:00]] 版) ]FIGCAPTION] > 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). ]FIG] [FIG(quote)[ [FIGCAPTION[ [67] [CITE@en[Deploy to Heroku | Codeship Documentation]] ([TIME[2015-04-02 23:54:27 +09:00]] 版) ]FIGCAPTION] > 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 ]FIG] [FIG(quote)[ [FIGCAPTION[ [68] [CITE[REST API Developers Guide | Parse]] ([TIME[2015-07-15 00:01:58 +09:00]] 版) ]FIGCAPTION] > 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 > ]FIG] [69] [CITE[Internet Explorer では Web サイト アドレス (HTTP URL および HTTPS URL) に含まれるユーザー名およびパスワードがサポートされない]] ([TIME[2015-08-14 11:54:14 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [70] [CITE@en[Stripe API Reference]] ([TIME[2015-08-29 17:37:10 +09:00]] 版) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [71] [CITE[Helpdesk API]] ([TIME[2015-08-29 17:41:20 +09:00]] 版) ]FIGCAPTION] > > 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". ]FIG] [FIG(quote)[ [FIGCAPTION[ [31] [CITE@en[41489 – HTTP authentication does not support non-ISO-8859-1 characters]] ([TIME[2015-11-12 19:09:22 +09:00]] 版) ]FIGCAPTION] > Opera and Chromium(they just send the username as byte utf8 without transport encoding) ]FIG] [120] [CITE@en[41489 – HTTP authentication does not support non-ISO-8859-1 characters]] ([TIME[2015-11-12 19:09:30 +09:00]] 版) [FIG(quote)[ [FIGCAPTION[ [121] [CITE@en[Introduction — Mailgun API documentation]] ([TIME[2016-03-30 09:11:04 +09:00]] 版) ]FIGCAPTION] > Authentication to the API occurs via HTTP Basic Auth. Use api as the user name and your API key is the password. ]FIG] [FIG(quote)[ [FIGCAPTION[ [122] [CITE@ja-JP[Java 8リリースの変更]] ( ([TIME[2016-12-14 14:54:19 +09:00]])) ]FIGCAPTION] > HTTPSのトンネルの設定時にBasic認証を必要とするプロキシは、デフォルトでは成功しないようになりました。必要な場合、jdk.http.auth.tunneling.disabledSchemesネットワーク・プロパティからBasicを削除するか、コマンド行で同じ名前のシステム・プロパティを"" (空)に設定することで、この認証スキームを再度アクティブ化できます。 ]FIG] [FIG(quote)[ [FIGCAPTION[ [123] [CITE@en[Stripe API Reference]] ([TIME[2016-12-16 17:58:49 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [124] [CITE@en[rest-api-doc/deposit_api.md at master · CrossRef/rest-api-doc]] ([TIME[2017-04-20 18:10:07 +09:00]]) ]FIGCAPTION] > 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. ]FIG] [FIG(quote)[ [FIGCAPTION[ [125] [CITE[CircleCI API v1.1 Reference - CircleCI]] ([TIME[2017-06-10 05:03:08 +09:00]]) ]FIGCAPTION] > 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 : https://circleci.com/api/... > (Note the colon :, which tells curl that there’s no password.) ]FIG] [FIG(quote)[ [FIGCAPTION[ [126] [CITE[はてなブログAtomPub - Hatena Developer Center]] ([TIME[2017-07-18 13:16:40 +09:00]]) ]FIGCAPTION] > 2013年10月17日 Basic認証に対応/APIのエンドポイントをhttpsに変更(Basic認証が利用できないことを除いて、httpのエンドポイントも引き続き利用できます) ]FIG] [FIG(quote)[ [FIGCAPTION[ [127] [CITE[Bitbucket API]] ([TIME[2017-09-08 16:53:51 +09:00]]) ]FIGCAPTION] > 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). ]FIG] [128] [CITE@ja[標準規格(放送分野)一覧表]] ([TIME[2017-08-29 12:04:00 +09:00]]) [129] [CITE@en[Support HTTP Basic auth for RTSP · Issue #510 · nmap/nmap]] ([TIME[2018-02-04 00:54:50 +09:00]]) [130] [CITE@en[435547 - Evaluate dropping legacy and credentialed subresource requests. - chromium - Monorail]] ([TIME[2018-02-05 23:28:47 +09:00]]) [131] [CITE@en[174179 - Re-Re-Think HTTP Basic Auth experience with respect to embedded content - chromium - Monorail]] ([TIME[2018-02-05 23:32:12 +09:00]]) [132] [CITE@en[504300 - Disallow requests with basic auth credentials in URL - chromium - Monorail]] ([TIME[2018-02-05 23:32:52 +09:00]]) [133] [CITE@en[707761 - Name and Password in XMLHttpRequest.open no longer work - chromium - Monorail]] ([TIME[2018-02-05 23:36:20 +09:00]]) [FIG(quote)[ [FIGCAPTION[ [134] [CITE@ja[GitHub アプリのアクセス許可を選択する - GitHub Enterprise Server 3.13 Docs]] ([TIME[2024-11-30T03:16:36.000Z]]) ]FIGCAPTION] > その後は、アクセス トークンを HTTP パスワードとして使うことができます。 TOKEN は、アクセス トークンに置き換えます。 > git clone https://x-access-token:TOKEN@github.com/owner/repo.git ]FIG]