[4] auth-scheme は、 HTTP や派生プロトコルにおいて認証に用いる仕組み、あるいは仕組みを表す文字列です。

仕様書

構文

[9] auth-scheme は HTTP の token とされています >>7, >>11, >>13, >>15。

  1. 字句

[10] auth-scheme は大文字・小文字不区別です >>7, >>11, >>13, >>15。

[53] 現実には、特定の大文字・小文字の組み合わせしか受け付けない杜撰な実装もあります。

[54] BitBucket の Web API サーバーは、 Bearer は認識しますが、 bearer は認識しません。

[25] auth-scheme が使われる challenge や credentials では、 auth-param のリスト (#) または token68 を添えて指定できます。これらは chalenge や credentials における auth-scheme 依存の追加情報を表しています。

[26] 例えば基本認証の challenge では利用者名と合言葉を指定します。

[27] 各 auth-scheme におけるこれらの値の構文と処理方法については、 それぞれの項および auth-param を参照してください。

文脈

[8] auth-scheme の値は、 HTTP の challenge、 credentials の中で認証の方式を表すために使われます。

[5] auth-scheme の値は、 CGI のメタ変数 AUTH_TYPE の値としても使われます。

[28] 認証方式は一般に起源鯖での認証にも串での認証にも使えます。 各認証方式はそれぞれの場面で使えるかを明記する必要がある >>19 とされています。

[29] HTTP では認証方式は特に限定されておらず、 IANA登録簿に新規に登録もできるようになっています。

[32] RTSP は HTTP に定義を委ねていますが、 Basic と Digest の実装を推奨しています >>31。

[30] SIP はIANA登録簿がなかった時代の HTTP から派生したためか、 そのようには明記されていません。また Digest には対応することが求められていますが、 Basic の実装は禁止されています。旧版では pgp が定義されていましたが、後に削除されています。

[37] MSRP は Digest のみ認めています。

詳しくはそれぞれの項を参照。

[51] auth-scheme の値は、 Authentication-Control: ヘッダーでも使われます。

処理

[47] HTTP認証や各認証方式の項も参照。

[20] HTTP認証は状態を持ちませんstateless。 認証に必要な情報は、すべて要求に含めなければなりません。 >>19

[21] HTTP接続に基いていたり、束縛されていたりする認証は、 HTTP の仕様の範囲外とされており、認証された利用者以外が当該 HTTP接続を使えないことを保証できない限り、欠陥を持っています。 >>19

[24] 1つのHTTP接続で要求と応答の組を複数回やり取りできますが、 先の要求と応答での認証の結果を以後の要求と応答に (同じHTTP接続を使っているという理由で) 適用してはいけないということです。 HTTP における HTTP接続は、状態を持つプロトコルとは違って、 要求と応答の組を複数連続的にやり取りするためだけの構文的な存在に過ぎず、 それ以上の意味を持ちません。1つの HTTP接続で複数の要求と応答の組をやり取りするのと、 2つの別のHTTP接続で要求と応答の組をそれぞれ別々にやり取りするのとでは意味が変わってしまうべきではありません。[23] Negotiate のようにこの原則に反した auth-scheme もありますが、セキュリティーや相互運用性の問題を抱えている >>22 と指摘されています。[46] ただし、前の応答で提供された情報を次の要求に引き継ぐような形の状態は持つことがあります。 例えばダイジェスト認証がそのような仕組みとなっています。

[48] 複数の認証方式をサーバーとクライアントの間で折衝する方法については、 challenge を参照。

認証方式の一覧

[1]
auth-schemechallenge での使用 (応答)credentials での使用 (要求)出典
AdobeAuth○
anon○○
ApiKey○
ApplePushNotifications○
Atom○○
AWS○
AWS4-HMAC-SHA256○
Basic○○RFC 1945, RFC 2068, RFC 2617
Bearer○○
Bot○
CookieCookie (auth-scheme)○
CredSSP○○
DelegatedToken○
Digest○○RFC 2617
Eap○○draft-torvinen-http-eap
GOOG1○
GoogleLogin○
GSS○×draft-johansson-http-gss
HHMAC○
HOBA○○
HTML○×HTML5 [r2432-r2470)
hmac○
IndieAuth○
JWT○
Kerberos○
Mutual
Negotiate○○RFC 4559
NTLM○
OAuth○○OAuth
PEM○
pgp○○RFC 2543 (RFC 3261 で非推奨)
Remote-Passphrase○○
SASL○○draft-nystrom-http-sasl
SCRAM-SHA-1○○
SCRAM-SHA-256○○
Session×○WD-session-id
SFLY○
SharedKey○
SharedKeyLite○
SharedAccessSignature○
Token○
vapid○○
WebID-RSA○○
WRAP○○
WSSE×○
W3C-API×○

[2] RFC 2617 時代までは IANA登録簿がありませんでしたが、 RFC 7235 で新設されました (>>18) >>15。

[39] JSON 形式の auth-scheme および auth-param の一覧が >>40 にあります。

[49] RFC 7804 は SCRAM- から始まる命名規則を定義していますが、 特にこの名前を予約しているわけではなく、命名規則に従っていても IANA登録簿に通常の規則により登録することを求めています。

Web ブラウザーによる実装

[42] Webブラウザーは、Web互換性のため、次の認証方式に対応する必要があります。

[43] Webブラウザーは、次の認証方式に対応していることもあります。

[44] Webブラウザーは、Web互換性のため、次の認証方式に直接対応することはできません。

[45] ある日突然 Webブラウザーがこれらを実装すると、サーバー側が想定しておらず、 セキュリティー上の問題となる可能性があります。 XHR などにより著者のスクリプトが独自に実装して Webブラウザー経由でアクセスする分には問題ありません。

OAuth 2.0 認証方式

[41] OAuth 2.0 では、要求におけるアクセストークンの送信や応答における認証エラーの通知に、 専用または兼用の HTTP認証方式を使うことができるとしています。そのような認証方式に対して若干の制約も課しています。 アクセストークン型と認証方式名は揃えることが推奨されています。

資源鯖、アクセストークン型を参照。

統計

[3] HTTP/1.1 WWW-Authenticate header ( 版) http://www.http-stats.com/WWW-Authenticate

関連

[16] auth-param も参照。

歴史

誕生

  • [6] Request Headers in the HTTP protocol ( ( 版)) http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z9

RFC 第1世代

  • [7] RFC 1945 - Hypertext Transfer Protocol -- HTTP/1.0 ( 版) http://tools.ietf.org/html/rfc1945#section-11

RFC 第2世代

  • [11] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2068#section-11

RFC 第3世代

  • [12] [13] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-1.2

[14] draft-stecher-icap-subid-00 - ICAP Extensions ( ( 版)) http://tools.ietf.org/html/draft-stecher-icap-subid-00#section-3.4

[36] >>35 は類似した一連の認証方式について RA- から始まる auth-scheme の命名規則を提案していました。 また >>38 は SCRAM- から始まる命名規則を提案していました。 しかしいずれも支持を集められなかったようです。

  • [35] draft-williams-http-rest-auth-03 - RESTful Authentication Pattern for the Hypertext Transport Protocol (HTTP) ( 版) http://tools.ietf.org/html/draft-williams-http-rest-auth-03
  • [38] draft-melnikov-httpbis-scram-auth-00 - Salted Challenge Response (SCRAM) HTTP Authentication Mechanism ( 版) https://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00

[55] RFC 3050 - Common Gateway Interface for SIP, , https://tools.ietf.org/html/rfc3050#section-5.5.1.1

RFC 第4世代

  • [34] RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication ( 版) https://tools.ietf.org/html/rfc7235#section-2.1
  • [33] RFC 7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations ( 版) https://tools.ietf.org/html/rfc7236
[50] XProc 2.0: Standard Step Library () https://www.w3.org/TR/2016/NOTE-xproc20-steps-20160721/#cv.request

Appropriate values for the auth-method attribute are “Basic” or “Digest” but other values are allowed. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. The interpretation of auth-method values on c:request other than “Basic” or “Digest” is implementation-definedXP.

[52] RFC 8040 - RESTCONF Protocol () https://tools.ietf.org/html/rfc8040#section-2.5

If certificate-based authentication is not feasible (e.g., because one cannot build the required PKI for clients), then HTTP authentication MAY be used. In the latter case, one of the HTTP authentication schemes defined in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" (Section 5.1 in [RFC7235]) MUST be used.