保護空間

realm 引数 (HTTP)

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

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

文脈

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

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

基本認証の場合

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

ダイジェスト認証の場合

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

[54] ダイジェスト認証では、 realm は、 利用者が指定するべき利用者名合言葉を知るために表示される文字列です >>53。少なくても認証を行うホストの名前は含んでいるべきで、 それに加えて利用者がアクセスできるであろう集成をも示すことができます >>53challenge でも 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.0realm 引数を追加して構わないとしています >>30。逆に言えば省略しても構わないということで、 >>14 と矛盾していました。

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

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

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

処理

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

レンダリング

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

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

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

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

歴史

RFC 第1世代

RFC 第2世代

RFC 第3世代

[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 認証での用法

RFC 第4世代

統計

[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