403禁止vs 401未经授权的HTTP响应

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

401 Unauthorized ？
403 Forbidden吗？
还有吗

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

---

#1楼

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

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

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

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

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

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

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

---

#2楼

缺少其他答案的是，必须理解，在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 。

---

#3楼

假设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身份验证。

---

#4楼

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

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

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

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

6.5.3。 403禁止

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

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

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

无论使用哪种约定，重要的是要在整个站点/ API之间提供统一性。

---

#5楼

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

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

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

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

---

#6楼

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

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

---

#7楼

Resource exists ? (if private it is often checked AFTER auth check)
    |       |
 NO |       | YES
    v       v
   404      Is logged-in ? (authenticated, aka has session)
   or         |              |
   401     NO |              | YES
   403        |              |
              v              v
              401            Can access resource ? (permission, authorized) ?
         (404 no reveal)      |            |
             or 301        NO |            | YES
             redirect         |            |
             to login         v            v
                              403          OK 200, 301, ...
                      (or 404: no reveal)

通常按以下顺序进行检查：

• 401（如果未登录或会话已过期）
• 403，如果用户无权访问资源（文件，json，...）
• 404（如果资源不存在（或不愿透露任何内容））

UNAUTHORIZED ：状态码（401），指示请求需要身份验证 ，通常这意味着用户需要登录（会话）。 服务器未知的用户/代理。 可以重复使用其他凭据。 注意：这令人困惑，因为它应该被命名为“未经身份验证”而不是“未经授权”。 如果会话过期，登录后也可能发生这种情况。 特殊情况：可以代替404使用，以避免显示资源的存在或不存在（信用@gingerCodeNinja）

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

未找到 ：状态代码（404），指示请求的资源不可用。 用户/代理已知，但服务器不会显示任何有关资源的信息，就像不存在该信息一样。 重复将不起作用。 这是404的一种特殊用法（例如github）。

---

#8楼

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（未找到）

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

---

#9楼

根据RFC 2616 （HTTP / 1.1），在以下情况下发送403：

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

换句话说，如果客户端可以通过身份验证访问资源，则应发送401。

---

#10楼

参见RFC2616 ：

401未经授权：

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

403禁止：

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

更新资料

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

---

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

---

#11楼

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

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

---

#12楼

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

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

• 资源需要身份验证，但未指定 凭据 。

401 ：客户端应指定凭据。

• 指定的凭据格式无效 。

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

• 指定的凭据引用了不存在的用户 。

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

• 指定的凭据 无效，但指定了有效用户（如果不需要指定用户，则不要指定用户）。

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

• 指定的凭据已过期 。

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

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

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

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

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

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

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

---

#13楼

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

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

401未经授权

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

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

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

403禁止

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

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

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

---

#14楼

401 ：我不知道你是谁。 这是身份验证错误。 403 ：我知道你是谁 但是您没有访问此资源的权限。 这是授权错误。

---

#15楼

这些含义是：

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

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

---

#16楼

Daniel Irvine的明确解释：

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

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

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

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

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

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

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