/
179.txt
198 lines (149 loc) · 11.1 KB
/
179.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
[7] [DFN[[RUBYB[[[認証]]]@en[authentication]]]]は、[[合言葉]]その他の方法によって[[クライアント]]が[[鯖]]の[[資源]]にアクセスする権限を有しているか確認し、限定する機能です。
[[基本認証]]や [[OAuth]] が広く用いられています。
* 仕様書
[REFS[
- [5] '''[CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) <https://tools.ietf.org/html/rfc7235>'''
-- [10] [CITE@en[RFC 7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication]] ([TIME[2014-09-11 10:01:28 +09:00]] 版) <https://tools.ietf.org/html/rfc7235#section-2.1>
- [2] [CITE@en[RFC 3261 - SIP: Session Initiation Protocol]] ([TIME[2014-08-15 14:48:03 +09:00]] 版) <http://tools.ietf.org/html/rfc3261#section-22>
- [15] [CITE@en[RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)]] ([TIME[2014-09-21 17:04:59 +09:00]] 版) <http://tools.ietf.org/html/rfc4918#appendix-E>
]REFS]
* プロトコル要素
[3] [[HTTP認証]]に関わる次の[[HTTPヘッダー]]があります。
[FIG(short list)[
- [CODE(HTTP)@en[[[Authorization:]]]]
- [CODE(HTTP)@en[[[Proxy-Authorization:]]]]
- [CODE(HTTP)@en[[[WWW-Authenticate:]]]]
- [CODE(HTTP)@en[[[Proxy-Authenticate:]]]]
]FIG]
[4] [[HTTP認証]]に関わる次の[[HTTP状態符号]]があります。
[FIG(short list)[
- [CODE(HTTP)[[[401]]]]
- [CODE(HTTP)[[[407]]]]
]FIG]
[6] [[HTTP認証]]に関わる次の構文があります。
[FIG(short list)[
- [CODE(ABNF)@en[[[auth-scheme]]]]
- [CODE(ABNF)@en[[[auth-param]]]]
- [[challenge (HTTP)]]
- [[credentials]]
]FIG]
* 認証方式
[8] [[HTTP認証]]では[[基本認証]]や [[OAuth]] をはじめ、
色々な認証方式を用いることができます。詳しくは
[CODE(ABNF)@en[[[auth-scheme]]]] を参照してください。
* 処理モデル
[11] [[起源鯖]]は、保護された[[資源]]に対する[[要求]]で [[credentials]] がなかったり、
非妥当な [[credentials]] (例えば誤った[[パスワード]]) が指定されていたり、
不完全な [[credentials]] (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
[[challenge]] が指定された [CODE(HTTP)@en[[[WWW-Authenticate:]]]]
[[ヘッダー]]を含む [CODE(HTTP)[[[401]]]] [[応答]]を送信する[['''べきです''']] [SRC[>>10]]。
[12] 認証が必要な[[串]]は、[[要求]]で[[串]]についての [[credentials]] がなかったり、
非妥当な [[credentials]] (例えば誤った[[パスワード]]) が指定されていたり、
不完全な [[credentials]] (例えば複数回の往復が必要な認証方式の途中の段階)
が指定されていたりする場合には、最低1つの (おそらくは新しい)
[[challenge]] が指定された [CODE(HTTP)@en[[[Proxy-Authenticate:]]]]
[[ヘッダー]]を含む [CODE(HTTP)[[[407]]]] [[応答]]を送信する[['''べきです''']] [SRC[>>10]]。
;; [14] 認証が必要な[[串]]で認証に成功した場合には通常は
[CODE(HTTP)@en[[[Proxy-Authorization:]]]] [[ヘッダー]]を削除して[[転送]]しますが、
[[串]]の構成によってはそのまま[[転送]]することもあります。
[CODE(HTTP)@en[[[Proxy-Authorization:]]]] [[ヘッダー]]の項を参照。
[13] [[鯖]]は、妥当な [[credentials]] が含まれていて、なお適切なアクセス権を有しない場合には、
[CODE(HTTP)[[[403]]]] [[応答]]を返す[RUBYB[べき]@en[ought to]]です [SRC[>>10]]。
* 認証の検出
[16] [[HTTP]] では[[資源]]にどのような[[認証]]によるアクセス制御が適用されているか[[クライアント]]が確実に知る方法はありません。
[[認証]]の有無によって応答が成功するかエラーになるか異なる場合もありますが、
[[認証]]しない「匿名」権限でも一部のみアクセスできるような場合もあります。
[17] [CODE(HTTP)@en[[[If-Match:]]]] にダミーの[[実体タグ]]を指定してダミーの [CODE(HTTP)@en[[[PUT]]]]
[[要求]]を ([[認証]]なしで) 送信すると、[[認証]]が必要なら [CODE(HTTP)[[[401]]]]
[[応答]]と [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]が返され、
必要ないとしても [CODE(HTTP)@en[[[If-Match:]]]] の[[実体タグ]]と実際の[[実体タグ]]が一致しないので、
[CODE(HTTP)@en[[[PUT]]]] は実行されません。 [SRC[>>15]]
;; [18] [CODE(HTTP)@en[[[PUT]]]] に対応していないとしても [CODE(HTTP)[[[405]]]]
などが返されるはずです。[[クライアント]]は[[鯖]]がおそらく返さないであろう適当な[[実体タグ]]を生成する必要があります。
;; [19] [[認証]]より[[条件付きヘッダー]]が先に評価されてしまうと意図通りに動作しません
[SRC[>>15]] し、[[条件付きヘッダー]]が実装されていないと [CODE(HTTP)@en[[[PUT]]]]
が実行されてしまいます。
[20] [CODE(HTTP)@en[[[Authorization:]]]] [[ヘッダー]]に適当な
([[認証]]を通過しなそうな) 値を指定して送信することで、[CODE(HTTP)[[[401]]]]
[[応答]]と [CODE(HTTP)@en[[[WWW-Authenticate:]]]] [[ヘッダー]]が返されると期待できます
[SRC[>>15]]。
;; [21] しかし[[鯖]]が黙って無視するなら期待通り [[challenge]] を得ることはできません。
* 実装
[1]
[CITE[[IE5] Office ドキュメントを開くと認証ダイアログが表示される]] <http://support.microsoft.com/default.aspx?scid=kb;ja;415541>
>基本認証のかかったページ内にある Excel などの Office ドキュメントを Internet Explorer 5 上から開こうとすると、再度、認証ダイアログが表示される現象
>Office 2000 アプリケーションが Internet Explorer から起動される場合、Internet Explorer のキャッシュを利用せずに、Internet Explorer から渡された URL から自分自身で、ファイルをダウンロードして、ファイルを表示するようになっています。Internet Explorer は、他のプロセスにパスワードなどの認証情報を引き継がないため、Office 2000 アプリケーションが認証情報を設定せずに、Web サーバへリクエストを送信するためです。
* 関連
[9] [[HTTP]] では、 [[HTTP]] 本体の機能である [[HTTP認証]]の他に、
用途や個々の [[Webアプリケーション]]特有の色々な認証方式が用いられています。
例えば次のものがあります。
[FIG(short list)[
- [[Cookie認証]]
- [[OAuth 1.0]] ([[HTTP認証]]を使わないもの)
- [[OAuth 2.0クライアント認証]] ([[HTTP認証]]を使わないもの)
- [[OAuth 2.0]] [[ベアラートークン]]認証 ([[HTTP認証]]を使わないもの)
- [[APIキー]]
- [[Flickr Authentication API]]
- [[はてな認証API]]
- [[かんたんログイン]]
- [[TLS]] [[クライアント認証]]
- [[IPアドレス]]によるアクセス制限
]FIG]
[22] [[HTTPキャッシュ]]は [[HTTP認証]]については適切に処理するのが既定の動作になっていますが、
それ以外の[[認証]]方式には対応できないので、適宜 [CODE(HTTP)@en[[[Cache-Control:]]]]
[[ヘッダー]]などで制御する必要があります。 (通常は[[クライアント]]も[[鯖]]も、
相手との間に[[キャッシュ]]が存在するかどうか知り得ないので、両者共に適切な[[ヘッダー]]を指定する必要があります。)
* メモ
[1]
[CITE[HTTP Authentication with HTML forms : Paul James]] <http://www.peej.co.uk/articles/http-auth-with-html-forms.html>
[408] [CITE@en[draft-williams-websec-session-continue-proto-00 - Hypertext Transport Protocol (HTTP) Session Continuation Protocol]]
( ([TIME[2014-10-19 15:12:28 +09:00]] 版))
<http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00>
[409] [CITE@en[draft-williams-websec-session-continue-proto-00 - Hypertext Transport Protocol (HTTP) Session Continuation Protocol]]
( ([TIME[2014-10-19 15:12:28 +09:00]] 版))
<http://tools.ietf.org/html/draft-williams-websec-session-continue-proto-00>
[410] [CITE@en[draft-oiwa-httpauth-multihop-template-00 - Common Template for HTTP Message-based Multi-hop Authentication]]
( ([TIME[2014-10-18 15:08:43 +09:00]] 版))
<https://tools.ietf.org/html/draft-oiwa-httpauth-multihop-template-00>
[411] [CITE@en[draft-williams-httpbis-auth-classification-01 - A Proposals for Classification and Analysis of HTTPbis Authentication Proposals]]
( ([TIME[2014-10-16 14:58:39 +09:00]] 版))
<http://tools.ietf.org/html/draft-williams-httpbis-auth-classification-01>
[412] [CITE@en[draft-williams-httpbis-auth-classification-01 - A Proposals for Classification and Analysis of HTTPbis Authentication Proposals]]
( ([TIME[2014-10-16 14:58:39 +09:00]] 版))
<http://tools.ietf.org/html/draft-williams-httpbis-auth-classification-01>
[413] [CITE@en[Define authentication entries a bit better https://www.w3.org/Bugs/Publi... · bffaa17 · whatwg/fetch]]
( ([TIME[2014-11-04 03:21:52 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/bffaa17cdad4f7924548233d24ff14b0ae793bbb>
[414] [CITE[XEP-0070: Verifying HTTP Requests via XMPP]]
( ([TIME[2014-04-09 01:56:36 +09:00]] 版))
<http://xmpp.org/extensions/xep-0070.html>
[FIG(quote)[
[FIGCAPTION[
[23] [CITE[HTTP authentication - The Chromium Projects]]
([TIME[2015-03-21 10:14:33 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/http-authentication>
]FIGCAPTION]
> Chrome supports four authentication schemes: Basic, Digest, NTLM, and Negotiate. Basic, Digest, and NTLM are supported on all platforms by default. Negotiate is supported on all platforms except ChromeOS by default.
>
]FIG]
[FIG(quote)[
[FIGCAPTION[
[24] [CITE[HTTP authentication - The Chromium Projects]]
([TIME[2015-03-21 10:14:33 +09:00]] 版)
<https://www.chromium.org/developers/design-documents/http-authentication>
]FIGCAPTION]
> When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:
> Basic: 1
> Digest: 2
> NTLM: 3
> Negotiate: 4
> The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.
> So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.
]FIG]
[25] [CITE@en[Handling Authentication (Windows)]]
([TIME[2015-03-22 00:24:32 +09:00]] 版)
<https://msdn.microsoft.com/en-us/library/aa384220(VS.85).aspx>
[26] [CITE[Part3 - browsersec - Browser Security Handbook, part 3 - Browser Security Handbook - Google Project Hosting]]
([TIME[2015-03-31 16:50:41 +09:00]] 版)
<https://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication>