認証方式

auth-scheme (HTTP)

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

仕様書

構文

[9] auth-schemeHTTPtoken とされています >>7, >>11, >>13, >>15

  1. 字句

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

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

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


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

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

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

文脈

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

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

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

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

[32] RTSPHTTP に定義を委ねていますが、 BasicDigest の実装を推奨しています >>31

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

[37] MSRPDigest のみ認めています。

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

[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
BasicRFC 1945, RFC 2068, RFC 2617
Bearer
Cookie
CredSSP
DelegatedToken
DigestRFC 2617
Eapdraft-torvinen-http-eap
GOOG1
GoogleLogin
GSS×draft-johansson-http-gss
HHMAC
HOBA
HTML×HTML5 [r2432-r2470)
hmac
IndieAuth
JWT
Kerberos
Mutual
NegotiateRFC 4559
NTLM
OAuthOAuth
PEM
pgpRFC 2543 (RFC 3261非推奨)
Remote-Passphrase
SASLdraft-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 7804SCRAM- から始まる命名規則を定義していますが、 特にこの名前を予約しているわけではなく、命名規則に従っていても 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 も参照。

歴史

誕生

RFC 第1世代

RFC 第2世代

RFC 第3世代

[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 の命名規則を提案していました。 また >>38SCRAM- から始まる命名規則を提案していました。 しかしいずれも支持を集められなかったようです。

RFC 第4世代

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