对于存在的网页，但用户没有足够特权（他们没有登录或不属于适当的用户组）的网页，可以提供什么适当的HTTP响应？

401 Unauthorized？
403 Forbidden？
还有别的吗

到目前为止，我对两者的区别还不清楚。每种使用情况适合哪些用例？

Daniel Irvine的明确解释：

401 Unauthorized出现问题，身份验证错误的HTTP状态代码。就是这样：它用于身份验证，而不是授权。服务器收到401响应后，会告诉您：“您没有通过身份验证-完全没有身份验证或身份验证不正确-但请重新进行身份验证，然后重试。” 为了帮助您，它将始终包含描述如何进行身份验证的WWW-Authenticate标头。

这是通常由您的Web服务器而不是Web应用程序返回的响应。

这也是非常临时的。服务器要求您重试。

因此，对于授权，我使用403禁止响应。它是永久的，与我的应用程序逻辑相关，并且比401更具体。

服务器收到403响应，告诉您：“很抱歉。我知道您是谁-我相信您说的是谁-但您只是没有访问此资源的权限。也许如果您很好地询问系统管理员，您将获得许可。但是请不要再困扰我，直到您的困境改变为止。”

总之，当用户通过身份验证但无权对给定资源执行请求的操作时，应使用401未经授权的响应来进行丢失或错误的身份验证，然后使用403禁止响应。

另一种不错的图片格式，说明应如何使用http状态代码。

参见RFC2616：

401未经授权：

如果请求已包含授权凭证，则401响应指示已拒绝这些凭证的授权。

403禁止：

服务器理解了该请求，但拒绝执行该请求。

更新资料

从您的用例来看，似乎用户未通过身份验证。我会返回401。

编辑：RFC2616已过时，请参阅RFC7231和RFC7235。

缺少其他答案的是，必须理解，在RFC 2616上下文中的身份验证和授权仅引用RFC 2617的HTTP身份验证协议。HTTP状态码不支持通过RFC2617之外的方案进行身份验证，因此不考虑在决定使用401还是403时。

简明扼要

未经授权表示客户端未通过RFC2617认证，服务器正在启动认证过程。“禁止”表示客户端已通过RFC2617认证并且没有授权，或者服务器不支持所请求资源的RFC2617。

这意味着，如果您有自己的自备登录过程并且从不使用HTTP身份验证，则403始终是正确的响应，并且永远不应使用401。

详细和深入

从RFC2616

10.4.2 401未经授权

该请求需要用户认证。响应必须包括一个WWW-Authenticate头域（第14.47节），其中包含适用于所请求资源的质询。客户可以用合适的授权头域（第14.8节）重复请求。

和

10.4.4 403禁止服务器理解了请求，但拒绝执行。授权将无济于事，并且不应重复该请求。

首先要记住的是，本文档中的“身份验证”和“授权”是专门指RFC 2617中的HTTP身份验证协议。它们不涉及您可能创建的任何自带身份验证协议使用登录页面等。我将使用“登录”来指通过RFC2617以外的方法进行身份验证和授权

因此，真正的区别不在于问题是什么，甚至不是解决方案。区别在于服务器希望客户端接下来执行的操作。

401指示无法提供资源，但是服务器正在请求客户端通过HTTP身份验证登录，并已发送了答复标头以启动该过程。可能有一些授权将允许访问该资源，也许没有，但是让我们尝试一下看看会发生什么。

403表示无法提供资源，对于当前用户，没有办法通过RFC2617解决此问题，也没有尝试的意义。这可能是因为已知没有足够的身份验证级别（例如，由于IP黑名单），但是可能是因为用户已经通过身份验证并且没有权限。RFC2617模型是一个单用户单凭证，因此可以忽略用户可能拥有第二组可以授权的凭证的情况。它既不暗示也不暗示某种登录页面或其他非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）

禁止：状态代码（403）指示服务器理解了该请求，但拒绝执行该请求。服务器已知的用户/代理，但凭据不足。除非更改凭据，否则重复请求将不起作用，这在很短的时间内是非常不可能的。特殊情况：可以代替404使用，以避免显示资源的存在或不存在（信用@gingerCodeNinja）

未找到：状态代码（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身份验证和授权头）在使用中，如果认证作为另一个用户将授予访问所请求的资源，那么401未授权应返回。

403 Forbidden用于禁止所有人访问资源或限制访问给定网络或仅通过SSL允许访问资源，只要与HTTP身份验证无关即可。

如果未使用HTTP身份验证，并且按当今的标准为基于cookie的身份验证服务提供服务，则应返回403或404。

关于401，这来自RFC 7235（超文本传输​​协议（HTTP / 1.1）：身份验证）：

3.1。401未经授权

401（未经授权）状态码表示该请求尚未应用，因为它缺少针对目标资源的有效身份验证凭据。源服务器必须发送一个包含至少一个适用于目标资源的质询的WWW-Authenticate头域（第4.4节）。 如果请求中包含身份验证凭据，则401响应指示已拒绝这些凭据的授权。客户端可以用一个新的或替换的Authorization头域（4.1节）重复请求。如果401响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，则用户代理应向用户呈现随附的表示，因为它通常包含相关的诊断信息。

403（和404）的语义已随时间而改变。这是从1999（RFC 2616）开始的：

10.4.4 403禁止

服务器理解了该请求，但拒绝执行该请求。
授权将无济于事，不应重复该请求。
如果请求方法不是HEAD，并且服务器希望
公开为什么未满足请求，则应在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户端，则
可以改用状态代码404 （未找到）。

2014年，RFC 7231（超文本传输​​协议（HTTP / 1.1）：语义和内容）更改了403的含义：

6.5.3。403禁止

403（禁止）状态码表示服务器理解了请求，但拒绝授权。希望公开为什么禁止请求的服务器可以在响应有效负载（如果有）中描述该原因。

如果请求中提供了身份验证凭据，则
服务器认为它们不足以授予访问权限。客户端
不应使用相同的
凭据自动重复该请求。客户端可以用新的或不同的证书重复请求。但是，出于
与凭据无关的原因，可能会禁止请求。

希望“隐藏”当前存在的
禁止目标资源的原始服务器可以使用状态代码
404（未找到）进行响应。

因此，403（或404）现在可能意味着任何事情。提供新的凭据可能会有所帮助...或可能没有帮助。

我相信这已经改变的原因是RFC 2616假定在当今的Web应用程序在实践中使用例如表单和cookie构建自定义身份验证方案时将使用HTTP身份验证。

这是一个比较老的问题，但是从未真正提出过的一种选择是返回404。从安全角度来看，投票率最高的答案有潜在的信息泄漏漏洞。例如，假设所讨论的安全网页是系统管理页面，或者更常见的是，它是用户无法访问的系统中的记录。理想情况下，您甚至不希望恶意用户知道那里有一个页面/记录，更不用说他们没有访问权限了。当我构建类似这样的东西时，我将尝试在内部日志中记录未认证/未授权的请求，但返回404。

OWASP提供了有关攻击者如何在攻击过程中使用此类信息的更多信息。

• 401未经授权：我不知道您是谁。这是身份验证错误。
• 403 Forbidden：我知道您是谁，但您无权访问此资源。这是授权错误。

这个问题是在不久前提出的，但是人们的想法在不断发展。

该草案（由Fielding和Reschke撰写）的6.5.3节为状态代码403赋予了与RFC 2616中所记录的含义稍有不同的含义。

它反映了许多流行的Web服务器和框架采用的身份验证和授权方案中发生的情况。

我强调了我认为最突出的一点。

6.5.3。403禁止

403（禁止）状态码表示服务器理解了请求，但拒绝授权。希望公开为什么禁止请求的服务器可以在响应有效负载（如果有）中描述该原因。

如果请求中提供了身份验证凭据，则服务器认为它们不足以授予访问权限。 客户端不应使用相同的凭证重复请求。客户端可以用新的或不同的证书重复请求。 但是，出于与凭据无关的原因，可能会禁止请求。

希望“隐藏”当前存在的禁止目标资源的原始服务器可以使用状态代码404（未找到）进行响应。

无论使用哪种约定，重要的是要在整个站点/ 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（未找到）

  （如果服务器希望从客户端保留此信息）

他们没有登录或不属于正确的用户组

您陈述了两种不同的情况；每种情况应有不同的响应：

1. 如果根本没有登录，则应返回401未经授权
2. 如果他们已登录但不属于正确的用户组，则应返回403 Forbidden

根据对此答案收到的评论，在RFC上进行说明：

如果用户未登录，则他们未经身份验证，其HTTP等效项是401，并且在RFC中被误称为“未经授权”。如第10.4.2节所述，针对401未经授权：

“该请求需要用户验证。”

如果您未经身份验证，则401是正确的响应。但是，如果您未经授权，则从语义上正确的意义上来说，403是正确的响应。

这些含义是：

401：用户未（正确）经过身份验证，资源/页面需要身份验证

403：用户已通过身份验证，但其角色或权限不允许访问请求的资源，例如，用户不是管理员，而请求的页面是针对管理员的

在我看来，这比这里任何地方都简单，因此：

401：您需要HTTP基本身份验证才能看到此信息。

403：您看不到这一点，HTTP基本身份验证也无济于事。

如果用户只需要使用您网站的标准HTML登录表单登录，则401不适用，因为它特定于HTTP基本身份验证。

我不建议使用403拒绝访问诸如之类的东西/includes，因为就网络而言，这些资源根本不存在，因此应为404。

这将403保留为“您需要登录”。

换句话说，403的意思是“此资源需要除HTTP基本身份验证以外的某种形式的身份验证”。

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

我认为重要的是要考虑到，对于浏览器，401会启动一个身份验证对话框供用户输入新的凭据，而403则不会。浏览器认为，如果返回401，则用户应重新进行身份验证。因此401代表无效身份验证，而403代表缺少权限。

在这种逻辑下，在某些情况下会从身份验证或授权返回错误，并用粗体显示重要的短语。

• 资源需要验证，但没有凭据进行了规定。

401：客户端应指定凭据。

• 指定的凭据格式无效。

400：既不是401也不是403，因为语法错误应始终返回400。

• 指定的凭证引用用户其不存在。

401：客户端应指定有效的凭据。

• 指定的证书是无效的，但指定一个有效的用户（或不指定用户如果不需要指定的用户）。

401：同样，客户端应指定有效的凭证。

• 指定的凭据已过期。

401：这实际上与通常具有无效凭据的相同，因此客户端应指定有效凭据。

• 指定的凭据完全有效，但不能满足特定资源的需求，尽管具有更多权限的凭据可能会出现。

403：指定有效凭据不会授予对资源的访问权限，因为当前凭据已经有效，但没有权限。

• 无论凭证如何，都无法访问特定资源。

403：这与凭据无关，因此指定有效的凭据无济于事。

• 指定的凭据是完全有效的，但在特定的客户端被阻止使用它们。

403：如果客户端被阻止，则指定新凭据将无济于事。

用英语：

401

可能允许您访问，但是由于某些原因，您被拒绝了。如密码错误？再试一次，如果请求正确，您将获得成功回复。

403

您永远不会被允许。您的名字不在清单上，您永远也不会进入，离开，不发送重试请求，它将始终被拒绝。走开。

考虑到最新的RFC（7231和7235），用例似乎很清楚（斜体添加）：

• 401用于未认证（“缺少有效认证”）；即“我不知道你是谁，或者我不相信你是你所说的你。”

401未经授权

401（未经授权）状态代码表示该请求尚未应用，因为它缺少目标资源的有效身份验证凭据。产生401响应的服务器必须发送WWW-Authenticate头域（4.1节），该域包含至少一个适用于目标资源的质询。

如果请求包括身份验证凭据，则401响应指示已拒绝这些凭据的授权。用户代理可以用一个新的或替换的Authorization头域（4.2节）重复请求。如果401响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，则用户代理应向用户呈现随附的表示，因为它通常包含相关的诊断信息。

• 403用于未授权（“拒绝授权”）；即“我知道您是谁，但您无权访问此资源。”

403禁止

403（禁止）状态码表示服务器理解了请求，但拒绝授权。希望公开为什么禁止请求的服务器可以在响应有效负载（如果有）中描述该原因。

如果请求中提供了身份验证凭据，则服务器认为它们不足以授予访问权限。客户端不应该自动使用相同的凭据重复请求。客户端可以用新的或不同的证书重复请求。但是，出于与凭据无关的原因，可能会禁止请求。

希望“隐藏”当前存在的禁止目标资源的原始服务器可以使用状态代码404（未找到）进行响应。

在401 vs 403的情况下，已经回答了很多次。这本质上是“ HTTP请求环境”辩论，而不是“应用程序”辩论。

关于“自己动手登录”问题（应用程序）似乎存在一个问题。

在这种情况下，除非您使用HTTP身份验证而不是登录页面（与设置HTTP身份验证无关），否则仅不登录就不足以发送401或403。听起来您可能正在寻找“ 201 Created”（创建201），其中存在“您自己登录”屏幕（而不是请求的资源），以供应用程序级访问文件。这说：

“我听说过，它在这里，但请尝试一下（不允许您看到它）”