Authorization Required

状態符号 401 (HTTP)

[403] 401 (Unauthorized) は、HTTP認証が必要であって、 要求に適切な credentials が含まれていなかったことを示す状態符号です。

仕様書

意味

[5] 401 は、要求対象資源に対して妥当な認証credentials が含まれていなかったために要求を適用しなかったことを示す状態符号です >>3

[6] 要求credentials を含んでいた場合には、 401 応答はその credentials に対する認可を拒んでいることを示します >>3

構文

[410] 401 応答生成するサーバーは、 対象資源に適用される challenge を最低1つは含んだ WWW-Authenticate: ヘッダーを送信しなければなりません >>3, >>16, >>408, >>411, >>412, >>415, >>416, >>419, >>420

[28] が、これに従っていないサーバーもありますから、 クライアントはそれに依存することはできません。

[14] 401 応答payload は、認証に失敗した理由などを記述した簡単な HTML 文書とするのが一般的です。会員制サイトなどでは登録ページへのリンクを含めたりします。

[15] 現在の一般的な Webブラウザーでは、 payload文書が表示されるのは、 認証ダイアログをキャンセルした時です。認証前に利用者に伝えたい内容を記述するには不適切です。

文脈

[2] 起源鯖は、保護された資源に対する要求credentials がなかったり、 非妥当な credentials (例えば誤ったパスワード) が指定されていたり、 不完全な credentials (例えば複数回の往復が必要な認証方式の途中の段階) が指定されていたりする場合には、最低1つの (おそらくは新しい) challenge が指定された WWW-Authenticate: ヘッダーを含む 401 応答を送信するべきです >>1

[8] HTTP認証も参照。

[17] PROPFIND 要求に対する 207 応答内の status 要素では、 適切な認証のもとでしか値を表示できないことを表すために使うことができます >>18

[19] OAuth 1.0認証された要求が不適切なときに、 401 応答を返すべき場合があります。

[21] OAuth 2.0要求が不適切な時に、 401 を使える場合、使わなければならない場合があります。

処理

[7] 利用者エージェントは、 credentials を含む要求に対して 401 応答が返された時、新しい Authorization: ヘッダーを指定した要求を再度試みても構いません >>3

[406] 認証を通って 202 などの成功を表す応答が返されると、 以後、HTTP URL が同じ階層 (ディレクトリー) 以下の要求には利用者エージェントが自動的に同じ認証情報を付加するので、 側での合言葉の変更などで 401 が返されない限り、 利用者が再度認証情報を求められることはありません。

[407] 通常この認証情報の記憶は同一 Webブラウザーセッション内に限られます。 一般的な Webブラウザーは認証情報をセッションを越えて保存しますが、 自動的には送信せず、必ずセッションの最初の1回は明示的に利用者に問い合わせる仕組みになっています。

[9] realm も参照。

レンダリング

[404] Webブラウザーをはじめとする対話的HTTP 利用者エージェントは、普通、 HTTP要求に対して 401 応答が返されると、 利用者名前合言葉のような認証情報を問い合わせ、 それを含めて再度 HTTP要求を送信するようになっています。

[405] 入力された認証情報が不適当であった場合には再度 401 が返されますから、 Webブラウザーも再度利用者に入力を求め、以後これを繰り返します。 利用者が断念すると、 401 メッセージの内容をレンダリングします。

[418] 401 応答が以前の応答と同じ challenge を含んでいる場合で、利用者エージェントが既に何度か認証を試みていた場合には、 応答に含まれている表現に診断情報があるのが普通ですから、 これを利用者に提示するべきです >>3, >>416

[11] と仕様上はされていますが、実際には >>405 のような実装方法が一般的です。

[10] かつては 401 による認証情報の入力はモーダルダイアログとして実装するのが普通でした。そのために表示中のあるページで 401 が返されるとWebブラウザーのすべての機能が一旦使えなくなるという不便な状態でした。

[12] alert などのモーダルダイアログに少し遅れて10年代半ばにはタブに対してモーダルとなり、 他のタブの操作は妨害しないように改善されています。

[13] 素朴な実装方法だと XHR で次々に 401 を返す URL を開き続ける方法で利用者を妨害し続けるブラクラを作ることができてしまいます。 alert などのモーダルダイアログと同様に、 キャンセル時に以後そのタブないし起源401 による認証ダイアログの表示を抑制するオプションが必要でしょう。

[24] 利用者エージェントは、 navigate の際に、 認識できる challenge を含まない 401 応答200 応答のように表示しなければなりません >>22

[23] 利用者エージェントは、認識できる challenge を含む 401 応答であっても、 200 応答のように表示すると共にモーダルダイアログでない形でログインできるようにしても構いません >>22

[402] FirefoxPOST 時や XHR401 が返された時の扱いが一部バグっているようです。 (詳しい再現条件はよくわからないのですが・・・。) 普通なら合言葉の入力ダイアログ箱が出るところなのですが、出なかったりもして、謎です。

[25] 最近の Firefox は、フレーム内の navigate401 に遭遇し、保存済みの credentials がないときは、 ダイアログを表示せずに 401 応答を表示するようです。

[26] しかしそのような動きはWeb互換ではありません。

[27] >>25 の不具合はその後修正されたようです。

歴史

RFC 第1世代

RFC 第2世代

RFC 第3世代

[413] RFC 1945 (HTTP/1.0); RFC 2068 & 2616 (HTTP/1.1) 10.4.2 401 Unauthorized

The request requires user authentication. The response {1945} must {2068,2616} MUST include a WWW-Authenticate header field ({1945} Section 10.16 section {2068} 14.46 {2616} 14.47) containing a challenge applicable to the requested resource. The client {1945} may {2068,2616} MAY repeat the request with a suitable Authorization header field ({1945} Section 10.2 {2068,2616} section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user {1945} should {2068,2616} SHOULD be presented the entity that was given in the response, since that entity {1945} may {2068} MAY {2616} might include relevant diagnostic information. HTTP access authentication is explained in {1945} Section 11 {2068} section 11 {2616} "HTTP Authentication: Basic and Digest Access Authentication" [43] .

要求は利用者認証を必要としています。応答は、要求された資源に適用可能な誰何を含んだ WWW-Authenticate 頭欄を含んでいなければなりません。クライアントは、適当な Authorization 頭欄と共に要求を繰り返しても構いません。 要求が既に Authorization 証明書を含んでいる場合、 401 応答はその証明書について認証が拒否されたことを示します。 401 応答が前の応答と同じ誰何を含んでおり、利用者エージェントが既に最低一度は認証を試みている時は、 応答に含まれている実体には関係する診断情報が含まれているかもしれませんから、 (訳注)利用者エージェントはこれを利用者に提示するべきです

[421] RFC 7252 - The Constrained Application Protocol (CoAP) ( ( 版)) <http://tools.ietf.org/html/rfc7252#section-5.9.2.2>

RFC 第4世代

関連

[414] 起源鯖によって使われる 401 に対して、によって使われる 407 もあります。

[422] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) <http://tools.ietf.org/html/rfc2660#section-5.2.1>

[20] Other Authentication Methods | GitHub API ( 版) <https://developer.github.com/v3/auth/>

The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found. This may cause problems for HTTP libraries that assume a 401 Unauthorized response.

[29] Make navigate's resource handling more explicit ( (annevk著, )) <https://github.com/whatwg/html/commit/806bc62caaee78a696a6c929558a5b801cceeec4>

[30] Move 401/407 into the network realm (annevk著, ) <https://github.com/whatwg/fetch/commit/ec6f5ef5f99cb6b0dd6c701b49791810fb380b04>

[31] Make CORS-preflight fetches set the CORS flag (annevk著, ) <https://github.com/whatwg/fetch/commit/9334fcbd34dc17e4508582c9fdc57f20ba5b728e>