403禁止と401不正HTTP応答
存在しているが十分な特権を持っていない（ログインしていない、または適切なユーザーグループに属していない）ユーザーのWebページの場合、適切なHTTP応答は何ですか？ 401？ 403？他に何か？私がこれまでに読んできたことは、両者の違いについてはあまり明確ではありません。各回答に適したユースケースはどれですか？
Daniel Irvine ：からの明確な説明
認証エラーのHTTPステータスコードである401 Unauthorized）に問題があります。認証用であり、認証用ではありません。401応答を受信すると、「認証されていません - 認証されていません。手助けをするために、認証方法を説明するWWW-Authenticate）ヘッダーが必ず含まれます。
これは通常、Webアプリケーションからではなく、Webサーバーから返される応答です。
それはまた非常に一時的なものです。サーバーがもう一度やり直すように求めています。
したがって、承認には403 Forbiddenresponse）を使用します。これは永続的なもので、アプリケーションロジックに関連付けられており、401より具体的な応答です。
403応答を受信すると、サーバーに「すみません。私はあなたが誰であるかを知っています - あなたがあなたが誰であると言っているか私は信じています - しかしあなたはこのリソースにアクセスする許可を持っていません。もしあなたがシステム管理者に頼みたいと思うなら、あなたは許可を得るでしょう。しかし、あなたの苦痛が変わるまで、私を邪魔しないでください。」
要約すると、401 Unauthorized応答は、欠落または不正な認証に使用されるべきであり、403 Forbidden応答は、ユーザーが認証されたが要求された操作の実行を許可されていない場合与えられたリソース.
もう1つの 素敵な絵の形式 httpステータスコードの使用方法の説明。
他の答えが欠けている何かはそれがRFC 2616の文脈における認証と承認がRFC 2617のHTTP認証プロトコルだけを参照することを理解しなければならないということです。 401と403のどちらを使用するかを決定するとき。
簡単な説明
Unauthorizedは、クライアントがRFC2617認証されておらず、サーバが認証プロセスを開始していることを示します。 「禁止」は、クライアントがRFC2617認証されていて許可を持っていないこと、またはサーバーが要求されたリソースに対してRFC2617をサポートしていないことを示します。
あなたがあなた自身のロール - あなた自身のログインプロセスを持ち、決してHTTP認証を使用しない場合は、403が常に適切な応答であり、401が使用されるべきではないという意味です。
詳細かつ詳細
RFC2616から
10.4.2 401未承認
要求にはユーザー認証が必要です。応答は、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダフィールド（セクション14.47）を含まなければならない。クライアントは適切なAuthorizationヘッダーフィールド（セクション14.8）で要求を繰り返すかもしれません。
そして
10.4.4 403禁止サーバーは要求を理解しましたが、それを満たすことを拒否しています。承認は助けにならないでしょうし、要求は繰り返されるべきではありません。
最初に覚えておくべきことは、この文書の文脈における「認証」と「許可」は、特にRFC 2617のHTTP認証プロトコルを指すということです。これらは、あなたが作成したロール独自の認証プロトコルを指すものではありません。ログインページなどを使用します。私はRFC2617以外の方法による認証と承認を参照するために "login"を使用します。
したがって、本当の違いは、問題が何であるか、または解決策があっても違います。違いは、サーバーがクライアントに次に実行することを期待していることです。
401はリソースを提供できないことを示しますが、サーバーはクライアントがHTTP認証を介してログインし、プロセスを開始するために応答ヘッダーを送信したことを要求しています。おそらくリソースへのアクセスを許可する承認があるかもしれませんが、それを試してみて何が起こるのか見てみましょう。
403は、リソースを提供できないことを示しています。現在のユーザーには、これをRFC2617で解決する方法はなく、試してみる意味もありません。これは、認証レベルが十分でないことが知られているため（たとえば、IPブラックリストのため）である可能性がありますが、ユーザーが既に認証済みで権限を持っていないためかもしれません。 RFC2617モデルは1人のユーザー、1つの資格情報なので、承認される可能性のある2番目の資格情報セットがユーザーにある場合は無視できます。ある種のログインページや他の非RFC2617認証プロトコルが助けになるかどうかを示唆も暗示もしていません - それはRFC2616標準と定義の外側にあります。
RFC 2616 によると、（HTTP/1.1）403は次の場合に送信されます。
サーバーは要求を理解しましたが、それを満たすことを拒否しています。承認は助けにならないでしょうし、要求は繰り返されるべきではありません。リクエストメソッドがHEADではなく、リクエストが満たされなかった理由をサーバが公表したい場合は、エンティティ内で拒否された理由を説明する必要があります。サーバーがこの情報をクライアントに利用可能にしたくない場合は、代わりにステータスコード404（Not Found）を使用できます。
つまり、クライアントが認証によってリソースにアクセスできる場合は、401が送信されます。
リソースは存在しますか？ | | NO | |はい v v 404ログイン（認証済み）ですか？ または| | | 401 NO | |はい 403 | | v v 401リソースへのアクセス、許可（許可）？ （404 no暴露）| | または301 NO | | YES リダイレクト| | v。[v] [v] [v] 403 [OK] 200、301、... （または404：表示されない）
チェックは通常次の順序で行われます。
- ログインしていないかセッションが期限切れの場合は401
- ユーザーがリソースにアクセスする権限を持っていない場合は403
- リソースが存在しない場合は404
_ unauthorized _ ：リクエストに authentication が必要であることを示すステータスコード（401）。通常、これはユーザーがログイン（セッション）する必要があることを意味します。サーバーが不明なユーザー/エージェント。他の資格情報で繰り返すことができます。注：これは「unauthorized」ではなく「unauthenticated」という名前になっているはずなので、これは紛らわしいです。セッションが期限切れになった場合、これはログイン後にも失敗する可能性があります。特別な場合：リソースの存在または不在を明らかにしないために404の代わりに使用できます（credit @gingerCodeNinja）
_禁止_ ：サーバーが要求を理解したがそれを実行することを拒否したことを示すステータスコード（403）。ユーザー/エージェントはサーバーに認識されていますが、 資格情報が不十分です 。資格情報が変更されない限り、要求を繰り返しても機能しません。これは短期間では非常に可能性が低いです。特別な場合：リソースの存在または不在を明らかにしないために404の代わりに使用できます（credit @gingerCodeNinja）
NOT FOUND ：要求されたリソースが利用できないことを示すステータスコード（404）。ユーザー/エージェントは認識されていますが、サーバーはリソースについて何も明らかにしません。あたかもそれが存在しないかのようにします。繰り返すことはうまくいきません。これは404の特別な使い方です（例えばgithubがやってくれます）。
HTTP認証を想定（ WWW-Authenticate および Authorization headers）使用中他のユーザーとして認証すると、要求されたユーザーにアクセスが許可されるその後、401 Unauthorizedが返されます。
403「禁止」は、HTTP認証に関連しない限り、リソースへのアクセスが全員に禁止されているか、特定のネットワークに制限されているか、またはSSLでのみ許可されている場合に使用されます。
HTTP認証が使用されていない場合そしてサービスは今日の標準であるクッキーベースの認証スキームであり、そして403か404が返されるべきです。
401に関しては、これはRFC 7235（ハイパーテキスト転送プロトコル（HTTP/1.1）：認証）からのものです。
3.1。 401未承認
401（Unauthorized）ステータスコードは、ターゲットリソースに対する有効な認証資格情報がないために要求が適用されていないことを示します。オリジンサーバは、ターゲットリソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダフィールド（4.4節）を送信しなければならない。 要求に認証資格情報が含まれている場合、401応答は承認がそれらの資格情報に対して拒否されたことを示します。クライアントは新しいか置き換えられたAuthorizationヘッダーフィールド（セクション4.1）で要求を繰り返すかもしれません。 401応答が前の応答と同じチャレンジを含み、ユーザエージェントがすでに認証を少なくとも1回試行している場合、通常は関連する診断情報を含むので、ユーザエージェントは同封の表現をユーザに提示する必要があります。
403（および404）のセマンティクスは時間の経過とともに変わりました。これは1999年からのものです（RFC 2616）：
10.4.4 403禁止されています
サーバーは要求を理解しましたが、それを満たすことを拒否しています。
承認は助けにはならないでしょうそして要求は繰り返されるべきではありません（SHOULD NOT）。
リクエストメソッドがHEADではなく、サーバーが作成したい場合
公に要求が満たされなかった理由で、それは実体における拒絶の理由を説明すべきである。サーバがこの情報をクライアントに利用可能にしたくない場合は、ステータスコード404
代わりに（見つかりません）を使用できます。
2014年にRFC 7231（ハイパーテキスト転送プロトコル（HTTP/1.1）：Semantics and Content）が403の意味を変更しました。
６．５．３。 403禁止します
403（禁止）ステータスコードは、サーバーが要求を理解したが承認を拒否したことを示します。要求が禁止されている理由を公開したいサーバーは、応答ペイロードにその理由を記述できます（もしあれば）。
認証資格情報が要求で提供された場合、
サーバーは、アクセスを許可するには不十分だと見なします。クライアント
同じものを使用して自動的に要求を繰り返すべきではありません。
資格情報。クライアントは新しいか異なった資格証明書で要求を繰り返すかもしれません。ただし、理由により要求は禁止される場合があります。
資格情報とは無関係です。現在の存在を「隠す」ことを望むOriginサーバ
禁止されたターゲットリソースは、代わりに以下のステータスコードで応答してもよい（MAY）。
404お探しのページが見つかりませんでした）。
したがって、403（または404）は今では何でもを意味するかもしれません。新しい認証情報を提供することは助けになるかもしれません...あるいはそうでないかもしれません。
これが変わった理由は、RFC 2616が、実際には今日のWebアプリケーションがフォームやクッキーなどを使ってカスタム認証スキームを構築するときにHTTP認証が使用されると想定しているためだと思います。
これは古い質問ですが、実際には提起されなかった1つの選択肢は404を返すことでした。セキュリティの観点からすると、最高得票数の回答には 情報漏洩の脆弱性 があります。たとえば、問題の安全なWebページがシステム管理者ページである、またはより一般的にはユーザーがアクセスできないシステム内のレコードであるとします。理想的には、悪意のあるユーザーがそこにページやレコードがあることを知っていることさえ望まないでしょう。このようなものを構築しているときは、認証されていない/承認されていない要求を内部ログに記録しようとしますが、404を返します。
OWASPには、攻撃者がこの種の情報を攻撃の一部としてどのように使用することができるかについての 詳細情報 があります。
この質問は少し前に聞かれましたが、人々の考え方は変わります。
セクション6.5.3 このドラフトの中の（Fielding and Reschkeによって書かれた）はステータスコード403に RFC 2616 で文書化されているものとわずかに異なる意味を与えます。
それは、多くの人気のあるWebサーバーやフレームワークによって採用されている認証と承認の仕組みで何が起こるかを反映しています。
私は私が最も際立っていると思う部分を強調しました。
6.5.3。403禁止
403（禁止）ステータスコードは、サーバーが要求を理解したが承認を拒否したことを示します。要求が禁止されている理由を公開したいサーバーは、応答ペイロードにその理由を記述できます（もしあれば）。
認証資格情報が要求で提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。 クライアントは同じ資格情報で要求を繰り返すべきではありません。クライアントは新しい資格情報または異なる資格情報で要求を繰り返すことができます。ただし、資格情報とは無関係の理由で要求は禁止されることがあります。
禁止されたターゲットリソースの現在の存在を「隠す」ことを望むOriginサーバは、代わりに404（Not Found）のステータスコードで応答してもよい（MAY）。
どのような規則を使用しても、重要なことはサイト/ 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禁じられています（10.4.4）
意味： 認証とは無関係
...承認は役に立ちません...
詳細：
サーバーは要求を理解しましたが、それを満たすことを拒否しています。
それは実体における拒絶の理由を説明するべきである
ステータスコード404（Not Found）を代わりに使用できます
（サーバーがクライアントからのこの情報を保持したい場合）
ログインしていないか、適切なユーザーグループに属していません。
あなたは2つの異なるケースを述べました。それぞれの場合は異なる反応を示すはずです。
- まったくログインしていない場合は、401 Unauthorizedを返してください。
- ログインしていても適切なユーザーグループに属していない場合は、403 Forbiddenを返す必要があります。
この回答に対して寄せられたコメントに基づくRFCのメモ：
ユーザーがログインしていない場合、認証されていません。これと同等のHTTPは401であり、RFCでは誤ってUnauthorizedと呼ばれています。 セクション10.4.2 として401 Unauthorizedの状態：
msgstr "要求にはユーザauthenticationが必要です。"
認証されていない場合は、401が正しい回答です。あなたが無許可の場合は、意味的に正しい意味で、403が正しい応答です。
私は、ブラウザに対して、401はユーザーに対して新しい資格情報を入力するための認証ダイアログを開始しますが、403は開始しないことを考慮することが重要です。ブラウザは、401が返された場合、ユーザーは再認証を受けるべきだと考えています。したがって、401は無効な認証を表し、403は許可の欠如を表します。
その論理の下で、認証または承認からエラーが返されるケースがいくつかあります。重要なフレーズは太字で示しています。
- リソースには認証が必要ですが、 認証情報がありません were 指定された 。
401 ：クライアントは資格情報を指定する必要があります。
- 指定された資格情報は 無効なフォーマット にあります。
400 ：構文エラーは常に400を返すはずなので、401でも403でもありません。
- 指定された信任状は user which が存在しない を参照しています。
401 ：クライアントは有効な認証情報を指定する必要があります。
- 指定された credentials are invalid しかし有効なユーザーを指定します（または指定されたユーザーが不要な場合はユーザーを指定しないでください）。
401 ：やはり、クライアントは有効な資格情報を指定する必要があります。
- 指定された 認証情報 have 期限切れ 。
401 ：これは一般に無効な認証情報を持つのと実質的に同じなので、クライアントは有効な認証情報を指定する必要があります。
- 指定された信任状は完全に有効ですが、 十分 特定の resource ではありません。
403 ：現在の信任状はすでに有効であるが許可だけを持っていないので、有効な信任状を指定してもリソースへのアクセスは許可されません。
- 特定の resource は アクセス不可 信任状に関係なく。
403 ：これは資格情報に関係なく、有効な資格情報を指定しても意味がありません。
- 指定された信任状は完全に有効ですが、特定の client は blocked から使用されていません。
403 ：クライアントがブロックされている場合、新しい認証情報を指定しても何も起こりません。
これは私の頭の中ではここのどこよりも簡単です。
401：これを見るにはHTTP基本認証が必要です。
403：あなたはこれを見ることができず、そしてHTTP基本認証は助けにならないでしょう。
ユーザーが自分のサイトの標準HTMLログインフォームを使用してログインするだけでよい場合、401はHTTP基本認証に固有のものであるため適切ではありません。
/includesのようなものへのアクセスを拒否するために403を使用することはお勧めしません。Webに関する限り、これらのリソースはまったく存在しないため404であるべきです。
これは403を "あなたはログインする必要がある"として残します。
つまり、403は「このリソースにはHTTP基本認証以外の認証が必要です」という意味です。
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2
401：あなたが誰なのかわかりません。これは認証エラーです。 4：私はあなたが誰であるか知っています。ただし、このリソースにアクセスする権限がありません。これは認証エラーです。
この問題に関する最新のRFC（ 7231 および 7235 ）を考えると、ユースケースはかなり明確に見えます（斜体を追加）。
- 401は unauthenticated （ "有効な認証がありません"）です。すなわち、「私はあなたが誰であるかわからない、または私はあなたがあなたがあなたであると言う人であることを信頼していない」。
401未承認
401（Unauthorized）ステータスコードは、リクエストがターゲットリソースの有効な認証がない認証情報であるために適用されていないことを示します。 401応答を生成するサーバは、ターゲットリソースに適用可能な少なくとも1つのチャレンジを含むWWW-Authenticateヘッダフィールド（セクション4.1）を送信しなければならない。
要求に認証資格情報が含まれている場合、401の応答は承認がそれらの資格情報に対して拒否されたことを示します。ユーザエージェントは新しいか置き換えられたAuthorizationヘッダーフィールド（セクション4.2）で要求を繰り返すかもしれません。 401応答が前の応答と同じチャレンジを含み、ユーザエージェントがすでに認証を少なくとも1回試行している場合、通常は関連する診断情報を含むので、ユーザエージェントは同封の表現をユーザに提示する必要があります。
- 403は unauthorized （ "承認を拒否する"）のためのものです。つまり、「私はあなたが誰であるかを知っていますが、このリソースにアクセスする権限がありません」
403禁止
403（禁止）ステータスコードは、サーバーが要求を理解したが認証を拒否 _であることを示します。要求が禁止されている理由を公開したいサーバーは、応答ペイロードにその理由を記述できます（もしあれば）。
認証資格情報が要求で提供された場合、サーバーはそれらをアクセスを許可するには不十分であると見なします。クライアントは同じ資格情報で要求を自動的に繰り返すべきではありません（SHOULD NOT）。クライアントは新しいか異なった資格証明書で要求を繰り返すかもしれません。ただし、認証情報とは無関係の理由で要求が禁止されることがあります。
禁止されたターゲットリソースの現在の存在を「隠す」ことを望むOriginサーバは、代わりに404（Not Found）のステータスコードで応答してもよい（MAY）。