[18] challenge の realm 引数は、 HTTP認証が適用される範囲を表す短い文字列です。 認証方式によっては credentials でも使います。

仕様書

意味

[37] 保護空間protection spaceは、 アクセスされている鯖の正準根URLと、指定されていれば realm の値とにより決まります >>36。

[46] 正準根URLの定義には URL scheme、ホスト名、ポートが含まれています。[26] 他に domain 属性も使われることがあります。

[16] realm は、鯖をいくつかの保護空間に分割するものです >>36, >>11, >>21, >>28。

[40] 認証方式により特に定められている場合を除き、鯖の範囲を超えて保護空間を拡大することはできません >>36。 (逆に言えば認証方式によっては鯖の範囲を超えることができるようです。)

[29] realm 引数は、保護の範囲scopeを示す必要がある認証方式で使うために予約されています >>36, >>45。新しい認証方式はこれと非互換な方法で使ってはなりません >>45。

[17] realm は、通常起源鯖によって割り当てられる文字列であり、 auth-scheme によっては更に何らかの意味を与えているかもしれません。 >>36, >>11, >>21, >>28

[12] 要求が認証された場合であって、 realm が指定されていた場合にあっては、 同じ credentials が同一の realm を共有するすべての要求に対しても妥当であるべきです。 >>11, >>22, >>24

credentials も参照。

[19] しばしば、「パスワードを入力してください」のような利用者に対するメッセージを含める場所として使われます。 入力するべきパスワードの種別を示した短い説明文や、 (機械的なアクセスを拒みたいなどの理由でパスワードを設定する場合に) パスワードそのものが記述されていることもあります。

[38] 応答が challenge を複数持つ場合、それぞれ別の realm でも構いません >>36。

構文

[41] auth-param の値は一般には字句か引用文字列とされていますが、 歴史的理由により、送信者は引用文字列として生成しなければなりません >>36, >>53。しかし受信者は字句も対応しないといけないかもしれません >>36。

[42] 値としては (引用文字列として表現できる) 任意の文字の列が認められているようです。

[3] >>1 によると空文字列も特に制限されていないみたいですね。

[15] realm 引数の値は大文字・小文字を区別します >>11, >>21, >>28。

[20] RFC 上は認められていませんが、シフトJISやUTF-8など任意のcharset による非ASCII文字が含まれることがよくあります。その場合、 Content-Type: ヘッダーの charset 引数があったとしても、それと一致しているとは限りません。

[52] RFC は問題の存在は認めながらも解決を先送りしています >>51。auth-param も参照。

文脈

[13] realm 引数は challenge で指定します。

[30] RFC 1945 と RFC 2068 では他の realm-param よりも前に1つだけ指定する構文になっていましたが、RFC 2617 では特にそういう制限はなくなっています。 (元から制限する意図が無かったのでしょう。)[14] 以前は realm 引数は必須でした >>11, >>21, >>28。 現在は auth-scheme 依存でどちらとも規定できるようです。

基本認証の場合

[50] Basic 認証では、必須です >>49。

ダイジェスト認証の場合

[56] Digest 認証では、 challenge の他 credentials でも使います >>53。

[54] ダイジェスト認証では、 realm は、 利用者が指定するべき利用者名と合言葉を知るために表示される文字列です >>53。少なくても認証を行うホストの名前は含んでいるべきで、 それに加えて利用者がアクセスできるであろう集成をも示すことができます >>53。 challenge でも credentials でも使います >>53。

[55] 例えば registered_users@example.com のような値を指定できます >>53, >>26。

[27] realm 引数の値はダイジェスト値の計算に使われます。 非ASCII文字が含まれる場合の扱いは定かではありません。

[57] ダイジェスト値の計算に realm が含まれているので、 サーバー内で生の合言葉を保存せずにダイジェスト値だけを保管している場合で、 それが仮に流出したとしても、生の合言葉は簡単にはわからない (と期待される) ので、他の realm にその値を流用するのが難しくなります >>35。

[58] しかし、サーバーは生の合言葉を何らかの方法で保存しないと realm を新設できませんし、ダイジェストアルゴリズムをより安全なものに変更することもできません。。。

[59] realm は、特定の利用者が使い得る他のどんな realm とも異なるものとするべきです。 そのために認証を行うホストの名前を含めるべきです。 >>35

OAuth の場合

[33] OAuth 1.0 は realm 引数を追加して構わないとしています >>30。逆に言えば省略しても構わないということで、 >>14 と矛盾していました。

[10] OAuth 1.0 だと realm は意味が無いのですが、指定することは認められています。 特に意味が無いので空文字列が指定されたりすることもあります。

[34] OAuth 1.0 では realm を省略することができますが、 Apple のライブラリー NSURLProtectionSpace を使っている Safari や iOS アプリケーションは realm が存在しないとクラッシュします。

[48] OAuth 2.0 Bearer は RFC 2617 を参照して realm の使用を認めています >>47。 実際には意味はなさそうです。

VAPID の場合

[65] VAPID では無視されます。

処理

[39] 保護空間によって credentials が自動的に適用できる範囲が決まります。 利用者エージェントは、以前の要求が認可されている場合には、 その credentials を保護空間内の他の要求にも (auth-scheme や auth-param や利用者の設定で決まる期間中は) 再利用して構いません。 >>36

レンダリング

[43] 基本認証やダイジェスト認証では、利用者の名前と合言葉の入力を促す画面に realm の値も示す実装が普通です。鯖側でも、 利用者に表示されることを前提とした人間可読なメッセージを (当該資源において相応しいと思われる言語で) 記述するのが一般的です。

[44] realm を表示することは HTTP 仕様上は特に要求されていないようですが、 表示しないWebブラウザーは Web互換とは言えなそうです。

[63] 最近の Chrome は表示しないみたいですね。

[64] ロボットアクセス拒否を目的に?基本認証を使っていて、 realm に credentials が書いてあるサイトもあるのですが、 Chrome ではそのことがわかりません。

歴史

RFC 第1世代

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

RFC 第2世代

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

RFC 第3世代

  • [24] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 ( 版) http://tools.ietf.org/html/rfc2616#section-14.8
  • [28] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-1.2
[1] RFC 2617 での定義
      realm       = "realm" "=" realm-value
      realm-value = quoted-string

The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme. Note that there may be multiple challenges with the same auth-scheme but different realms.

Digest 認証での用法

  • [25] RFC 2069 - An Extension to HTTP : Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2069#section-2.1.1
  • [31] RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication ( 版) http://tools.ietf.org/html/rfc2617#section-3.2.1

RFC 第4世代

  • [23] RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication ( 版) https://tools.ietf.org/html/rfc7235#section-2.2
  • [51] RFC 7617 - The 'Basic' HTTP Authentication Scheme ( 版) https://tools.ietf.org/html/rfc7617#section-3

統計

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

例

[5] >>4 より

WWW-Authenticate: Basic realm=""

[6] >>4 より

WWW-Authenticate: Basic

[7] >>4 より

WWW-Authenticate: Basic realm = "You need ID",

[8] >>4 より

WWW-Authenticate: Basic realm= /

[9] >>4 より

WWW-Authenticate: Basic realm=BSI SkimmerPlus Server 1.0.0.20 / 1.0.0.30

メモ

[60] RFC 7804 - Salted Challenge Response HTTP Authentication Mechanism ( 版) https://tools.ietf.org/html/rfc7804#section-5

[61] RFC 8053 - HTTP Authentication Extensions for Interactive Clients () https://tools.ietf.org/html/rfc8053#section-4.1

[62] RFC 8120 - Mutual Authentication Protocol for HTTP () https://tools.ietf.org/html/rfc8120#section-3.1