WWW-Authenticate ヘッダー

構文

WWW-Authenticate: <challenge>

<challenge> が <auth-scheme> で構成され、その後にオプションの <token68> またはカンマで区切られた <auth-params> のリストが続く場合、

challenge = <auth-scheme> <auth-param>, …, <auth-paramN>
challenge = <auth-scheme> <token68>

例えば、

WWW-Authenticate: <auth-scheme>
WWW-Authenticate: <auth-scheme> token68
WWW-Authenticate: <auth-scheme> auth-param1=param-token1
WWW-Authenticate: <auth-scheme> auth-param1=param-token1, …, auth-paramN=param-tokenN

token68 または認証引数の有無は、選択した <auth-scheme> によって異なります。 例えば、 Basic 認証では <realm> が要求され、オプションで charset キーを使用できますが、 token68 は対応していません。

WWW-Authenticate: Basic realm="Dev", charset="UTF-8"

複数のチャレンジを、カンマで区切ったリストで送信することができます。

WWW-Authenticate: <challenge>, …, <challengeN>

複数のヘッダーを単一のレスポンスで送信することもできます。

WWW-Authenticate: <challenge>
WWW-Authenticate: <challengeN>

ディレクティブ

<auth-scheme>

使用される認証方式を示す、大文字小文字の区別のないトークンです。 有名なものとしては、 Basic、Digest、Negotiate、AWS4-HMAC-SHA256 などがあります。 IANA は認証方式のリストを管理していますが、ホストサービスによって提供されている方式はそれ以外にもあります。

<auth-param> 省略可

<auth-scheme> によって決まる形の認証引数です。 <realm> は、多くの認証方式で共通の認証引数であるため、下記で説明します。

<realm> 省略可

文字列 realm に = と、保護領域を記述する引用符で囲まれた文字列が続きます。例えば、 realm="staging environment" のように記述します。 realm を指定すると、サーバーは保護する領域を区分することができます （そのような区分を許可する方式に対応している場合）。 一部のクライアントは、この値をユーザーに表示して、具体的な資格情報が要求されていることを知らせます。ただし、ほとんどのブラウザーは、フィッシング対策のためにこの表示を廃止しています。 この値が確実に対応している文字セットは、us-ascii だけです。 realm が指定されていない場合、クライアントは多くの場合、書式化されたホスト名を表示します。

<token68> 省略可

一部の方式で役立つ可能性のあるトークンです。 このトークンでは、 66 種類の予約されていない URI 文字に加えて、いくつかの文字を使用できます。 base64、base64url、base32、base16 （16 進数）の各エンコード方式のいずれかを、パディングの有無にかかわらず、ホワイトスペースを除いて保持することができます。 古い認証方式との整合性を保つため、 auth-param リストの代替として token68 が対応しています。

通常、それぞれの <auth-scheme> に必要な認証引数については、関連する仕様を確認する必要があります。 次の節では、いくつかの一般的な認証方式のトークンおよび認証引数について説明します。

Basic 認証のディレクティブ

<realm>

<realm> で前述の通りです。 なお、 realm は Basic 認証では必須です。

charset="UTF-8" 省略可

ユーザー名とパスワードを送信するときのサーバーが優先するエンコード方式をクライアントに伝えます。 文字列 UTF-8 だけが許可されており、大文字小文字の区別はありません。 これは realm 文字列のエンコード方式とは関係がありません。

Digest 認証のディレクティブ

<realm> 省略可

<realm> で前述の通りであり、どのユーザー名/パスワードを使用するかを示します。 少なくともホスト名を含める必要がありますが、アクセス権を持つユーザーやグループを示す場合もあります。

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)

<challenge>

<len>:<value> の形式のペアのセットを連結したもので、クライアントに渡されます。 チャレンジは、ノンス、アルゴリズム、発信元、realm、キー識別子、およびチャレンジで構成されます。

<max-age>

このチャレンジに対するレスポンスを受け入れることができる、 HTTP レスポンスが送信された時点からの秒数です。

<realm> 省略可

前述のディレクティブの節にある通りです。

例

複数の認証チャレンジの発行

単一のレスポンスヘッダーで複数のチャレンジを指定することができます。

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）。

SHA-256 と MD5 を使用した Digest 認証

クライアントは、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="http-auth@example.org",
    qop="auth, auth-int",
    algorithm=SHA-256,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"
WWW-Authenticate: Digest
    realm="http-auth@example.org",
    qop="auth, auth-int",
    algorithm=MD5,
    nonce="7ypf/xlj9XXwfDPEoM4URrv/xwf94BcCAzFZH4GiTo0v",
    opaque="FQhe/qaU925kfnzjCev0ciny7QMkPqMAFRtzCUYo5tdS"

クライアントはユーザー名とパスワードの入力をユーザーに促し、それから Authorization ヘッダーフィールドに資格情報をエンコードして入れます。 クライアントが MD5 ダイジェストを選択した場合、Authorization ヘッダーフィールドは次のようになります。

Authorization: Digest username="Mufasa",
    realm="http-auth@example.org",
    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="http-auth@example.org",
    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.<signature-of-challenge>

仕様書

ブラウザーの互換性

関連情報

• HTTP 認証
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407