WWW-Authenticate ヘッダー
Baseline Widely available *
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
* Some parts of this feature may have varying levels of support.
HTTP の WWW-Authenticate レスポンスヘッダーは、リソースへのアクセス権を得るために使われる HTTP 認証メソッド (またはチャレンジ) を定義します。
このヘッダーは、一般的な HTTP 認証の枠組みの一部であり、多くの認証方式で使用することができます。 それぞれのチャレンジには、サーバーが対応している方式と、その方式型に定義されている追加引数が記載されています。
HTTP 認証を使用するサーバーは、保護されたリソースへのリクエストに対して 401 Unauthorized レスポンスを返します。
このレスポンスには、1 つ以上の WWW-Authenticate ヘッダーと 1 つ以上のチャレンジが含まれていなければならず、リソースへのアクセスにどのような認証方式が使用できるか（およびそれぞれの方式が必要とする追加データ）を示します。
1 つの WWW-Authenticate ヘッダーには複数のチャレンジが許され、1 つのレスポンスには複数の WWW-Authenticate ヘッダーが許されます。
サーバーは、他のレスポンスメッセージに WWW-Authenticate ヘッダーを含めることで、資格情報を提供することがレスポンスに影響を与える可能性があることを示すこともできます。
WWW-Authenticate ヘッダーを受け取った後、クライアントは通常、ユーザーに資格情報を求めるプロンプトを表示し、リソースを再リクエストします。
この新しいリクエストは Authorization ヘッダーを使用して、選択された「チャレンジ」の認証方法に応じて適切にエンコードされた資格情報をサーバーに提供します。
クライアントは、対応しているチャレンジのうち、最も安全なものを選択することが期待されます（なお、「最も安全な」方法については議論の余地がある場合もあります）。
| ヘッダー種別 | レスポンスヘッダー |
|---|---|
| 禁止リクエストヘッダー | いいえ |
構文
WWW-Authenticate:
challenge =, …, challenge =
例えば、
WWW-Authenticate:
WWW-Authenticate: token68
WWW-Authenticate: auth-param1=param-token1
WWW-Authenticate: auth-param1=param-token1, …, auth-paramN=param-tokenN
token68 または認証引数の有無は、選択した charset キーを使用できますが、 token68 は対応していません。
WWW-Authenticate: Basic realm="Dev", charset="UTF-8"
複数のチャレンジを、カンマで区切ったリストで送信することができます。
WWW-Authenticate: , …,
複数のヘッダーを単一のレスポンスで送信することもできます。
WWW-Authenticate:
WWW-Authenticate:
ディレクティブ
-
使用される認証方式を示す、大文字小文字の区別のないトークンです。 有名なものとしては、
Basic、Digest、Negotiate、AWS4-HMAC-SHA256などがあります。 IANA は認証方式のリストを管理していますが、ホストサービスによって提供されている方式はそれ以外にもあります。 -
-
文字列
realmに=と、保護領域を記述する引用符で囲まれた文字列が続きます。例えば、realm="staging environment"のように記述します。 realm を指定すると、サーバーは保護する領域を区分することができます （そのような区分を許可する方式に対応している場合）。 一部のクライアントは、この値をユーザーに表示して、具体的な資格情報が要求されていることを知らせます。ただし、ほとんどのブラウザーは、フィッシング対策のためにこの表示を廃止しています。 この値が確実に対応している文字セットは、us-asciiだけです。 realm が指定されていない場合、クライアントは多くの場合、書式化されたホスト名を表示します。
-
一部の方式で役立つ可能性のあるトークンです。 このトークンでは、 66 種類の予約されていない URI 文字に加えて、いくつかの文字を使用できます。 base64、base64url、base32、base16 （16 進数）の各エンコード方式のいずれかを、パディングの有無にかかわらず、ホワイトスペースを除いて保持することができます。 古い認証方式との整合性を保つため、 auth-param リストの代替として token68 が対応しています。
通常、それぞれの
Basic 認証のディレクティブ
-
Basic認証では必須です。 charset="UTF-8"省略可-
ユーザー名とパスワードを送信するときのサーバーが優先するエンコード方式をクライアントに伝えます。 文字列
UTF-8だけが許可されており、大文字小文字の区別はありません。 これは realm 文字列のエンコード方式とは関係がありません。
Digest 認証のディレクティブ
-
domain省略可-
引用符を付け、空白で区切った URL 接頭辞のリストで、この資格情報を使用するすべての場所を定義します。 このキーが指定されていない場合、この資格情報はウェブルート以下のどこでも使用できます。
nonce-
サーバーが指定する引用符の付いた文字列で、特定の資格情報が有効とみなされる期間を制御するためにサーバーが使用できます。 これは、401 レスポンスが行われるたびに一意に生成されなければならず、さらに頻繁に再生成される可能性があります (たとえば、ダイジェストを 1 回だけ使用できるようにするなど)。 仕様書には、この値を生成するために利用可能なアルゴリズムに関する助言が含まれています。 nonce の値は、クライアントには不透明です。
opaque-
サーバーが指定する引用符の付いた文字列で、
Authorizationで変更されずに返されるべきものです。 これはクライアントには不透明です。サーバーは Base64 または 16 進数のデータを含めることを推奨します。 stale省略可-
大文字小文字を区別しないフラグで、クライアントからの前回のリクエストが、使用された
nonceが古すぎる (stale) ために拒否されたことを示します。 これがtrueであれば、新しいnonceで暗号化された同じユーザー名/パスワードを使ってリクエストを再試行できます。 それ以外の値の場合は、ユーザー名/パスワードが無効なので、ユーザーに再度リクエストする必要があります。 algorithm省略可-
ダイジェストの生成に使用するアルゴリズムです。 セッション以外での有効な値は
MD5(指定されていない場合の既定値)、SHA-256、SHA-512です。 セッションで有効な値はMD5-sess、SHA-256-sess、SHA-512-sessです。 qop-
引用符の付いた文字列で、サーバーが対応している保護の品質を示します。これは必ず指定しなければならず、認識できないオプションは無視されます。
"auth": 認証"auth-int": 完全性保護付きの認証
charset="UTF-8"省略可-
ユーザー名とパスワードを送信する際に、サーバーが優先するエンコード方式をクライアントに伝えます。 大文字小文字を区別しない文字列 "UTF-8" のみが許可されます。
userhash省略可-
サーバーが
"true"を指定することで、ユーザー名のハッシュ化に対応していることを示すことができます（既定値は"false"です）。
HTTP Origin-Bound Authentication (HOBA)
例
複数の認証チャレンジの発行
単一のレスポンスヘッダーで複数のチャレンジを指定することができます。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: challenge1, …, challengeN
複数のチャレンジを、同じレスポンス内の別個の WWW-Authenticate ヘッダーで送信することができます。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: challenge1
WWW-Authenticate: challengeN
Basic 認証
通常、WWW-Authenticate ヘッダーを含むサーバーのレスポンスは以下のようなものです。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Staging server", charset="UTF-8"
このヘッダーを受け取ったユーザーエージェントは、まずユーザーにユーザー名とパスワードの入力を求め、それからリソースを再リクエストします。このとき、 Authorization ヘッダーにエンコードされた資格情報を含めます。
Authorization ヘッダーは次のようになります。
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
Basic 認証では、資格情報はまず、ユーザー名とパスワードをコロンで結合し (aladdin:opensesame)、その結果の文字列を base64 でエンコードすることで構築します（YWxhZGRpbjpvcGVuc2VzYW1l）。
メモ: Apache や nginx サーバーで HTTP の Basic 認証を使用してサイトを保護する方法の例については、 HTTP 認証を参照してください。
SHA-256 と MD5 を使用した Digest 認証
メモ:
この例は、RFC 7616 "HTTP Digest Access Authentication" から引用しています (この仕様書の他の例では、SHA-512、charset、userhash の使用方法を示しています)。
クライアントは、Digest 認証で保護された URI http://www.example.org/dir/index.html の文書にアクセスしようとしています。
この文書のユーザー名は "Mufasa" で、パスワードは "Circle of Life" です (各単語の間にスペースがあることに注意してください)。
クライアントが初めて文書をリクエストしたとき、Authorization ヘッダーフィールドは送信されません。
ここでサーバーは、対応している各ダイジェストアルゴリズムのチャレンジを含む HTTP 401 メッセージでレスポンスします（SHA256、MD5 の順）。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth, auth-int",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
realm="[email protected]",
qop="auth, auth-int",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
クライアントはユーザー名とパスワードの入力をユーザーに促し、それから Authorization ヘッダーフィールドに資格情報をエンコードして入れます。
クライアントが MD5 ダイジェストを選択した場合、Authorization ヘッダーフィールドは次のようになります。
Authorization: Digest username="Mufasa",
realm="[email protected]",
uri="/dir/index.html",
algorithm=MD5,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="8ca523f5e9506fed4657c9700eebdbec",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
クライアントが SHA-256 ダイジェストを選択した場合は、 Authorization ヘッダーフィールドは次のようになります。
Authorization: Digest username="Mufasa",
realm="[email protected]",
uri="/dir/index.html",
algorithm=SHA-256,
nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
nc=00000001,
cnonce="f2/wE4q74E6zIJEtWaHKaf5wv/H5QzzpXusqGemxURZJ",
qop=auth,
response="753927fa0e85d155564e2e272a28d1802ca10daf449
6794697cf8db5856cb6c1",
opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
HOBA 認証
HOBA 認証に対応しているサーバーは、次のような WWW-Authenticate レスポンスヘッダーを入れることができます。
HTTP/1.1 401 Unauthorized
WWW-Authenticate: HOBA max-age="180", challenge="16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz"
署名されているこの blob チャレンジの構成要素は、 www.example.com はポート 8080 を使用し、ノンスは 1123123123、署名用のアルゴリズムは RSA-SHA256、キー識別子は 123、そして最後にチャレンジは 68147c97-461b-4310-be9b-4c707237ab53 です。
クライアントは、このヘッダーを受信し、チャレンジを抽出し、RSA-SHA256 を使用して、この例ではキー識別子 123 に対応する秘密鍵で署名し、その結果をドットで区切ったキー ID、チャレンジ、ノンス、および署名として Authorization ヘッダーで送信します。
Authorization: 123.16:MTEyMzEyMzEyMw==1:028:https://www.example.com:8080:3:MTI48:NjgxNDdjOTctNDYxYi00MzEwLWJlOWItNGM3MDcyMzdhYjUz.1123123123.
仕様書
| Specification |
|---|
| HTTP Semantics # field.www-authenticate |