存在するが、ユーザーに十分な権限がない（ログインしていない、または適切なユーザーグループに属していない）Webページの場合、適切なHTTP応答は何ですか？

401 Unauthorized？
403 Forbidden？
他に何か？

これまでにそれぞれについて読んだことは、2つの違いについてはあまり明確ではありません。各応答に適切なユースケースは何ですか？

Daniel Irvineからの明確な説明：

認証エラーのHTTPステータスコードである401 Unauthorizedに問題があります。そして、それだけです。認証ではなく、承認のためです。401応答を受信すると、サーバーから「認証されていません-まったく認証されていないか、正しく認証されていません-再認証して、もう一度お試しください。」と通知されます。あなたを助けるために、それは常に認証する方法を説明するWWW-Authenticateヘッダーを含みます。

これは通常、Webアプリケーションではなく、Webサーバーによって返される応答です。

また、これは非常に一時的なものです。サーバーは再試行を要求しています。

したがって、承認には403 Forbidden応答を使用します。これは永続的で、私のアプリケーションロジックに関連付けられており、401よりも具体的な応答です。

サーバーが403応答を受信すると、「ごめんなさい。私はあなたが誰であるかを知っています–あなたがあなたが誰であるかを信じています–しかし、あなたにはこのリソースにアクセスする許可がありません たぶん、システム管理者にきちんと尋ねれば許可を得るでしょう。しかし、あなたの苦境が変わるまで、再度私を悩ませないでください。」

要約すると、401 Unauthorized応答は、認証の欠落または不良に使用する必要があり、403 Forbidden応答は、ユーザーが認証されているが、特定のリソースで要求された操作を実行する権限がない場合に使用する必要があります。

httpステータスコードを使用する方法のもう1つの素晴らしい画像形式。

RFC2616を参照してください。

401無許可：

要求にすでに認証資格情報が含まれている場合、401応答は、それらの資格情報の認証が拒否されたことを示します。

403禁止します：

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。

更新

ユースケースから、ユーザーは認証されていないようです。401を返します。

編集：RFC2616は廃止されました。RFC7231およびRFC7235を参照してください。

他の答えが欠けているのは、RFC 2616のコンテキストでの認証と承認がRFC 2617のHTTP認証プロトコルのみを参照することを理解する必要があることです。RFC2617以外のスキームによる認証は、HTTPステータスコードではサポートされておらず、考慮されません。 401と403のどちらを使用するかを決定するとき。

簡潔で簡潔

無許可は、クライアントがRFC2617認証されておらず、サーバーが認証プロセスを開始していることを示します。Forbiddenは、クライアントがRFC2617で認証され、承認されていないか、サーバーが要求されたリソースのRFC2617をサポートしていないことを示します。

独自のロール独自のログインプロセスがあり、HTTP認証を使用しない場合、403は常に適切な応答であり、401は使用しないでください。

詳細かつ詳細

RFC2616から

10.4.2 401無許可

リクエストにはユーザー認証が必要です。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダーフィールド（セクション14.47）を含める必要があります。クライアントは適切なAuthorizationヘッダーフィールド（セクション14.8）を使用してリクエストを繰り返すことができます（MAY）。

そして

10.4.4 403 Forbiddenサーバーは要求を理解しましたが、要求の実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。

最初に覚えておかなければならないのは、このドキュメントのコンテキストでの「認証」と「承認」は、RFC 2617のHTTP認証プロトコルを特に指しているということです。これらは、作成した独自のロール認証プロトコルを指すものではありません。ログインページなどを使用します。RFC2617以外の方法による認証と承認を参照するには、「ログイン」を使用します。

したがって、本当の違いは問題が何であるか、または解決策がある場合でもです。違いは、サーバーがクライアントに次に行うことを期待していることです。

401は、リソースを提供できないことを示しますが、サーバーは、クライアントがHTTP認証を介してログインし、プロセスを開始するための応答ヘッダーを送信したことを要求しています。おそらく、リソースへのアクセスを許可する承認があるかもしれませんが、そうでないかもしれませんが、試してみて何が起こるか見てみましょう。

403は、リソースを提供できず、現在のユーザーがRFC2617を使用してこれを解決する方法がなく、試行する意味がないことを示します。これは、認証のレベルが十分ではないことがわかっているため（IPブラックリストなどが原因）、ユーザーがすでに認証されており、権限がないことが原因である可能性があります。RFC2617モデルは1ユーザー1クレデンシャルであるため、ユーザーが許可される可能性のある2番目のクレデンシャルセットを持っている場合は無視できます。これは、ある種のログインページやその他の非RFC2617認証プロトコルが役立つかどうかを示唆も示唆もしていません。これは、RFC2616標準と定義の範囲外です。

編集：RFC2616は廃止されました。RFC7231およびRFC7235を参照してください。

  + -----------------------
  | リソースは存在しますか？（プライベートの場合、認証チェックの後に頻繁にチェックされます）
  + -----------------------
    | |
 いいえ| vはい
    v + -----------------------
   404 | ログインしていますか？（認証済み、別名セッションまたはJWT Cookieがあります）
   または+ -----------------------
   401 | |
   403いいえ| | はい
   3xx vv
              401 + -----------------------
       （404明らかにしない）| リソースにアクセスできますか？（許可、承認済み、...）
              または+ -----------------------
             リダイレクト| |
             ログインしない| | はい
                               | |
                               vv
                               403 OK 200、リダイレクト、...
                      （または404：非公開）
                      （または404：プライベートの場合、リソースは存在しません）
                      （または3xx：リダイレクト）

チェックは通常、次の順序で行われます。

• リソースが公開されていて存在しない場合は404、または3xxリダイレクト
• さもないと：
• ログインしていない場合、またはセッションが期限切れの場合は401
• 403ユーザーがリソース（ファイル、jsonなど）にアクセスする権限を持っていない場合
• リソースが存在しないか、何も公開しない場合は404、または3xxリダイレクト

UNAUTHORIZED：リクエストに認証が必要であることを示すステータスコード（401）。通常、これはユーザーがログイン（セッション）する必要があることを意味します。サーバーで不明なユーザー/エージェント。他の資格情報で繰り返すことができます。注：これは「無許可」ではなく「非認証」と名付けられているはずなので、混乱を招きます。これは、セッションの有効期限が切れた場合、ログイン後にも発生する可能性があります。特殊なケース：404の代わりに使用して、リソースの存在または非存在を明らかにしないようにすることができます（クレジット@gingerCodeNinja）

FORBIDDEN：サーバーが要求を理解したが、要求の実行を拒否したことを示すステータスコード（403）。サーバーはユーザー/エージェントを認識していますが、資格情報が不十分です。資格情報が変更されない限り、リクエストの繰り返しは機能しません。これは、短期間ではほとんどありません。特殊なケース：404の代わりに使用して、リソースの存在または非存在を明らかにしないようにすることができます（クレジット@gingerCodeNinja）

NOT FOUND：リクエストされたリソースが利用できないことを示すステータスコード（404）。ユーザー/エージェントは既知ですが、サーバーはリソースについて何も公開せず、存在しないかのように表示します。繰り返しは機能しません。これは404の特別な使用法です（たとえば、githubがそれを行います）。

@ChrisHで述べたように、リダイレクト 3xxにはいくつかのオプションがあります（301、302、303、307、またはまったくリダイレ​​クトせず、401を使用）。

• HTTPリダイレクトコードの違い
• ブラウザはどのくらいの期間HTTP 301をキャッシュしますか？
• ログインページにリダイレクトするときの正しいHTTPステータスコードは何ですか？
• 302リダイレクトと307リダイレクトの違いは何ですか？

RFC 2616（HTTP / 1.1）によると、403は次の場合に送信されます。

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。リクエストメソッドがHEADではなく、サーバーがリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます

つまり、クライアントが認証によってリソースにアクセスできる場合は、401を送信する必要があります。

HTTP認証（WWW-AuthenticateおよびAuthorizationヘッダー）が使用されていると仮定すると、別のユーザーとして認証すると、要求されたリソースへのアクセスが許可される場合は、401 Unauthorizedが返されます。

403 Forbiddenは、リソースへのアクセスがすべてのユーザーに禁止されているか、特定のネットワークに制限されているか、HTTP認証に関連しない限り、SSL経由でのみ許可されている場合に使用されます。

HTTP認証が使用されておらず、サービスが現在の標準であるCookieベースの認証スキームである場合、403または404が返されます。

401に関しては、これはRFC 7235（Hypertext Transfer Protocol（HTTP / 1.1）：Authentication）によるものです。

3.1。401無許可

401（無許可）ステータスコードは、ターゲットリソースの有効な認証資格情報がないため、要求が適用されなかったことを示します。オリジンサーバーは、ターゲットリソースに適用可能なチャレンジを少なくとも1つ含むWWW-Authenticateヘッダーフィールド（4.4節）を送信する必要があります。 要求に認証資格情報が含まれている場合、401応答は、それらの資格情報の承認が拒否されたことを示します。クライアントは、新しいまたは置き換えられたAuthorizationヘッダーフィールド（セクション4.1）を使用して要求を繰り返すことができます（MAY）。401応答に前の応答と同じチャレンジが含まれ、ユーザーエージェントが少なくとも1回認証を試みた場合、ユーザーエージェントは通常、関連する診断情報を含むため、囲まれた表現をユーザーに提示する必要があります。

403（および404）のセマンティクスは時間とともに変化しました。これは1999年のものです（RFC 2616）。

10.4.4 403 Forbidden

サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。
承認は役に立たず、リクエストは繰り返されるべきではありません。
リクエストメソッドがHEADではなく、サーバー
がリクエストが実行されなかった理由を公開したい場合は、エンティティで拒否の理由を説明する必要があります。サーバーがこの情報をクライアントに提供したくない場合は、
代わりにステータスコード404 （見つかりません）を使用できます。

2014年にRFC 7231（Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content）は403の意味を変更しました：

6.5.3。403禁止します

403（禁止）ステータスコードは、サーバーが要求を理解したが、承認を拒否したことを示します。要求が禁止された理由を公開したいサーバーは、その理由を応答ペイロード（存在する場合）に記述できます。

要求で認証資格情報が提供された場合、
サーバーはそれらをアクセスを許可するには不十分であると見なします。クライアント
は同じ
資格情報でリクエストを自動的に繰り返すべきではありません。クライアントは、新しいまたは異なる資格情報で要求を繰り返すことができます。ただし、
資格情報とは無関係の理由により、要求が禁止される場合があります。

禁止されているターゲットリソースの現在の存在を「非表示」にするオリジンサーバーは、代わりにステータスコード
404（Not Found）で応答する場合があります。

したがって、403（または404）は現在、何についても意味する可能性があります。新しい資格情報を提供すると役立つ場合とそうでない場合があります。

これが変更された理由は、RFC 2616がHTTP認証を実際に使用して、今日のWebアプリがフォームやCookieなどを使用してカスタム認証スキームを構築するときに使用されると想定しているためだと思います。

これは古い質問ですが、実際に取り上げられなかったオプションの1つは404を返すことでした。セキュリティの観点から、投票数の多い回答には、情報漏えいの脆弱性が存在する可能性があります。たとえば、問題の安全なWebページがシステム管理ページである、またはおそらくより一般的には、ユーザーがアクセスできないシステムのレコードであるとします。理想的には、悪意のあるユーザーにページ/レコードがあることを知らせたくないだけでなく、アクセスできないことも望まないでしょう。このようなものを構築しているときは、認証されていない/許可されていないリクエストを内部ログに記録しようとしますが、404を返します。

OWASPには、攻撃者がこの種の情報を攻撃の一部としてどのように使用できるかについて、いくつかの詳細情報があります。

• 401 Unauthorized：私はあなたが誰なのかわかりません。これは認証エラーです。
• 403 Forbidden：私はあなたが誰であるか知っていますが、このリソースにアクセスする権限がありません。これは認証エラーです。

この質問は少し前に尋ねられましたが、人々の考えは変わりません。

このドラフトの6.5.3（Fielding and Reschkeが作成）は、ステータスコード403にRFC 2616で文書化されているものとは少し異なる意味を与えています。

これは、多くの一般的なWebサーバーおよびフレームワークで採用されている認証および承認スキームで何が発生するかを反映しています。

最も目立つと思うビットを強調しました。

6.5.3。403禁止します

403（禁止）ステータスコードは、サーバーが要求を理解したが、承認を拒否したことを示します。要求が禁止された理由を公開したいサーバーは、その理由を応答ペイロード（存在する場合）に記述できます。

要求で認証資格情報が提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。 クライアントは、同じ資格情報でリクエストを繰り返さないでください。クライアントは、新しいまたは異なる資格情報で要求を繰り返すことができます。 ただし、資格情報とは無関係の理由により、要求が禁止される場合があります。

禁止されているターゲットリソースの現在の存在を「非表示」にするオリジンサーバーは、代わりにステータスコード404（Not Found）で応答する場合があります。

どのような規則を使用する場合でも、重要なことは、サイト/ API全体に均一性を提供することです。

TL; DR

• 401：認証に関連する拒否
• 403：認証とは何の関係もない拒否

実例

Apache が（を介して.htaccess）認証を必要とする場合、を押すCancelと、401 Authorization Required

場合nginxのは、ファイルを見つけますが、何も持っていないアクセス権（ユーザー/グループ）読むために/アクセスそれを、それがで応答します403 Forbidden

RFC（2616セクション10）

401無許可（10.4.2）

意味1：認証が必要

リクエストにはユーザー認証が必要です。...

意味2：認証が不十分

...要求にすでに認証資格情報が含まれている場合、401応答は、それらの認証情報の承認が拒否されたことを示します。...

403 Forbidden（10.4.4）

意味：認証とは無関係

...承認は役に立ちません...

詳細：

• サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。

• エンティティでの拒否の理由を説明する必要があります

• 代わりにステータスコード404（見つかりません）を使用できます

  （サーバーがクライアントからのこの情報を保持したい場合）

ログインしていないか、適切なユーザーグループに属していません

あなたは2つの異なるケースを述べました。ケースごとに異なる応答が必要です。

1. ログインしていない場合は、401 Unauthorizedを返す必要があります
2. ログインしているが適切なユーザーグループに属していない場合は、403 Forbiddenを返す必要があります。

この回答に対して受け取ったコメントに基づくRFCに関するメモ：

ユーザーがログインしていない場合、ユーザーは認証されていません。これに相当するHTTPは401であり、RFCでは誤ってUnauthorizedと呼ばれています。セクション10.4.2で401 Unauthorizedの状態として：

「リクエストにはユーザー認証が必要です。」

認証されていない場合は、401が正しい応答です。ただし、無許可の場合、意味的に正しい意味では、403が正しい応答です。

これらは意味です：

401：ユーザーは（正しく）認証されていません。リソース/ページには認証が必要です

403：ユーザーは認証されましたが、その役割または権限では要求されたリソースへのアクセスが許可されていません。たとえば、ユーザーは管理者ではなく、要求されたページは管理者用です

これは私の頭の中でここのどこよりも簡単なので、：

401：これを表示するには、HTTP基本認証が必要です。

403：これを見ることができず、HTTP基本認証は役に立ちません。

ユーザーがサイトの標準HTMLログインフォームを使用してログインする必要があるだけの場合、401はHTTP基本認証に固有であるため、適切ではありません。

403を使用してへのアクセスを拒否することはお勧めしません/includes。Webに関する限り、これらのリソースはまったく存在しないため、404にする必要があります。

これにより、403は「ログインする必要があります」として残ります。

つまり、403は「このリソースにはHTTP基本認証以外の認証が必要」を意味します。

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

ブラウザに対して、401はユーザーが新しい資格情報を入力するための認証ダイアログを開始し、403は開始しないことを考慮することが重要だと思います。ブラウザは、401が返された場合、ユーザーは再認証する必要があると考えています。したがって、401は無効な認証を表し、403は権限の欠如を表します。

そのロジックの下で、認証または承認からエラーが返されるいくつかのケースを以下に示します。重要なフレーズは太字で表示されています。

• リソースには認証が必要ですが、資格情報が指定されていません。

401：クライアントは資格情報を指定する必要があります。

• 指定された資格情報は無効な形式です。

400：構文エラーは常に400を返すため、これは401でも403でもありません。

• 指定された資格情報は、存在しないユーザーを参照しています。

401：クライアントは有効な資格情報を指定する必要があります。

• 指定された資格情報は無効ですが、有効なユーザーを指定してください（または、指定されたユーザーが必要ない場合はユーザーを指定しないでください）。

401：ここでも、クライアントは有効な資格情報を指定する必要があります。

• 指定された資格情報は有効期限が切れています。

401：これは、一般的に無効な資格情報を持つことと実質的に同じであるため、クライアントは有効な資格情報を指定する必要があります。

• 指定された資格情報は完全に有効ですが、特定のリソースでは不十分ですが、より多くの権限を持つ資格情報が可能である可能性があります。

403：現在の資格情報は既に有効ですが、権限がないため、有効な資格情報を指定してもリソースへのアクセスは許可されません。

• 資格情報に関係なく、特定のリソースにアクセスできません。

403：これは資格情報に関係なく、有効な資格情報を指定しても役に立ちません。

• 指定された資格情報は完全に有効ですが、特定のクライアントはそれらの使用をブロックされています。

403：クライアントがブロックされている場合、新しい資格情報を指定しても何も起こりません。

英語で：

401

アクセスが許可されている可能性がありますが、何らかの理由でこのリクエストで拒否されました。不正なパスワードなど？もう一度お試しください。正しいリクエストを送信すると、代わりに成功の応答が返されます。

403

あなたは許可されていません。あなたの名前はリストに載っていません、あなたは入ったり出たりすることはなく、再試行リクエストを送信しないでください、それは常に拒否されます。どこかに行って。

問題に関する最新のRFC（7231および7235）を考えると、ユースケースは非常に明確に見えます（斜体を追加）：

• 401は非認証（「有効な認証がない」）の場合です。すなわち、「私はあなたが誰であるかを知らない、または私はあなたがあなたがあなたであると言う人であると信頼していません。」

401無許可

401（無許可）ステータスコードは、ターゲットリソースの有効な認証資格情報がないため、要求が適用されなかったことを示します。401応答を生成するサーバーは、ターゲットリソースに適用可能なチャレンジを少なくとも1つ含むWWW-Authenticateヘッダーフィールド（セクション4.1）を送信する必要があります。

要求に認証資格情報が含まれている場合、401応答は、それらの資格情報の承認が拒否されたことを示します。ユーザーエージェントは、新しいまたは置き換えられたAuthorizationヘッダーフィールド（セクション4.2）を使用して要求を繰り返すことができます（MAY）。401応答に前の応答と同じチャレンジが含まれ、ユーザーエージェントが少なくとも1回認証を試みた場合、ユーザーエージェントは通常、関連する診断情報を含むため、囲まれた表現をユーザーに提示する必要があります。

• 403は不正なものです（「承認を拒否」）。つまり、「私はあなたが誰であるか知っていますが、このリソースにアクセスする権限がありません。」

403禁止します

403（禁止）ステータスコードは、サーバーが要求を理解したが、承認を拒否したことを示します。要求が禁止された理由を公開したいサーバーは、その理由を応答ペイロード（存在する場合）に記述できます。

要求で認証資格情報が提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。クライアントは同じ資格情報でリクエストを自動的に繰り返すべきではありません。クライアントは、新しいまたは異なる資格情報で要求を繰り返すことができます。ただし、資格情報とは無関係の理由により、要求が禁止される場合があります。

禁止されているターゲットリソースの現在の存在を「非表示」にするオリジンサーバーは、代わりにステータスコード404（Not Found）で応答する場合があります。

401対403の場合、これは何度も回答されています。これは本質的に「アプリケーション」の議論ではなく、「HTTPリクエスト環境」の議論です。

自分のログインのロールの問題（アプリケーション）に質問があるようです。

この場合、HTTP認証とログインページ（HTTP認証の設定に関連付けられていない）を使用しない限り、401または403を送信するには、単にログインしていないだけでは不十分です。ファイルへのアプリケーションレベルのアクセスのために（要求されたリソースではなく）自分のログイン画面が表示されている「201 Created」を探しているようです。これは言う：

「聞いたよ、ここにあるが、代わりにこれを試してください（あなたはそれを見ることができません）」