仕様書

構文

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

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

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

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

[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: ヘッダーでも使われます。

処理

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

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

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

認証方式の一覧

[1]

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

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

Web ブラウザーによる実装

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

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

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

OAuth 2.0 認証方式

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

統計

[3] HTTP/1.1 WWW-Authenticate header (2009-07-19 11:05:40 +09:00 版) http://www.http-stats.com/WWW-Authenticate

関連

[16] auth-param も参照。

歴史