403 Forbidden 与 401 Unauthorized HTTP 响应

Question

对于存在的网页，但用户没有足够的权限（他们未登录或不属于正确的用户组），要提供的正确 HTTP 响应是什么？

401 Unauthorized?
403 Forbidden?
还有别的事吗？

到目前为止，我所读到的关于两者之间的区别还不是很清楚。每个响应适合哪些用例？

Answer 1

从 daniel irvine ：

401未授权，http状态代码进行身份验证错误。这只是它：它是为了认证，而不是授权。 接收401响应是服务器告诉你的，“你不是 经过身份验证 - 无论是否全部或经过身份验证 不正确 - 但请重新认证并再试一次。“帮助你， 它将始终包含一个 www-authenticate 标题，描述了如何 进行身份验证。

这是一个通常由Web服务器返回的响应，而不是您的网络 应用。

也是非常暂时的;服务器要求你尝试 再次。

所以，对于授权，我使用 403 forbidden 响应。它的 永久，它与我的应用程序逻辑相关联，这是一个更具体的 响应于401。

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

总结，应使用A 401未经授权的响应丢失 或不良身份验证，应使用A 403禁止响应 之后，当用户经过身份验证但未授权时 对给定资源执行请求的操作。

另一个很好的图形格式如何如何使用。

Answer 2

看 rfc2616 ：

401未经授权：

如果请求已包含授权凭据，那么401响应表示授权已拒绝那些凭据。

403禁止：

服务器了解请求，但拒绝满足它。

更新

从您的用例中，似乎用户未经身份验证。我会返回401。

---

编辑： rfc2616 已过时，请参阅 rfc7231 和 RFC7235

Answer 3

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

Answer 4

  +-----------------------
  | RESOURCE EXISTS ? (if private it is often checked AFTER auth check)
  +-----------------------
    |       |
 NO |       v YES
    v      +-----------------------
   404     | IS LOGGED-IN ? (authenticated, aka has session or JWT cookie)
   or      +-----------------------
   401        |              |
   403     NO |              | YES
   3xx        v              v
              401            +-----------------------
       (404 no reveal)       | CAN ACCESS RESOURCE ? (permission, authorized, ...)
              or             +-----------------------
             redirect          |            |
             to login       NO |            | YES
                               |            |
                               v            v
                               403          OK 200, redirect, ...
                      (or 404: no reveal)
                      (or 404: resource does not exist if private)
                      (or 3xx: redirection)

.

检查通常按此顺序完成：

• 404如果资源是公开的，不存在或 3xx重定向
• 否则：
• 401如果未登录或会话已过期
• 403如果用户无权访问资源（文件，json，...）
• 404如果资源不存在或不愿意揭示任何内容，或 3xx重定向

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

forbidden ：状态代码（403）表示服务器理解请求但拒绝满足它。服务器已知的用户/代理但具有凭据不足。除非凭据发生变化，否则重复请求将无法正常工作，这在短时间内不太可能。 特殊情况：可以使用代替404，以避免揭示资源的存在或非存在（Credits @gingercodeninja）

未找到：状态代码（404），指示未使用所请求的资源。已知用户/代理但服务器不会显示任何关于资源的内容，就像它不存在一样。重复不会工作。这是404的特殊用途（例如，GitHub为例）。

如上所述，有一些选择重定向 3xx （301,302,303,307或根本没有重定向，并使用401）：

• 与http重定向代码之间的差异
• 浏览器缓存http 301s多长时间？
• 什么是正确的http状态重定向到登录页面时的代码？
• 一个302和307之间的区别重定向？

Answer 5

根据 rfc 2616 （http / 1.1）403在：

时发送

服务器了解请求，但拒绝履行它。授权不会有帮助，不应重复请求。如果请求方法不是头部，服务器希望宣传为什么未满足请求的原因，它应该描述实体中拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）而不是

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

Answer 6

假设HTTP身份验证 (WWW-Authenticate 和 授权 头) 在使用, 如果作为另一个进行身份验证用户将准予访问的请求的资源，那么401Unauthorized应该返回。

403禁止使用在获取资源是禁止或限制每个人都要一定的网络或者只允许通过SSL，无论，只要它没有关于HTTP认证。

如果HTTP身份验证不是在使用 和服务cookie-based认证计划作为规范如今，然后403或404应该返回。

关于401，这是从RFC7235(超文件传输协议(HTTP/1.1):认证):

3.1.401Unauthorized

401(未经授权的)地位代码表示的请求 不适用，因为它缺乏有效的证书的认证 对于该目标的资源。起源服务器必须发出一个 WWW-Authenticate header field(第4.4节)含有至少一个 挑战，适用于该目标的资源。 如果请求 包括认证的凭证，然后401响应 表明这种授权已经拒绝的那些 凭据.客户可重复的请求与新的或 替换的授权标题领域(4.1节).如果401 响应包含相同的挑战，因为现有的响应， 用户代理已经试图认证至少一次，然后 用户的代理商应该本的封闭的代表 用户，因为它通常包含的相关诊断信息。

语义403(404)已经随着时间而改变。这是从1999年(RFC2616):

10.4.4 403禁止

服务器以理解的请求，但是拒绝履行它。
授权将无助 并请求不应当重复。
如果请求方不是头和希望使服务器
公共为什么请求没有被满足时，它应该描述 原因拒绝在的实体。如果服务器不希望 使这种信息提供给客户的状态码404
(找不到的)可以被用来代替。

在2014年RFC7231(超文件传输协议(HTTP/1.1):语义和内容)的改变的意义403:

6.5.3.403禁止

403(禁止)地位代码表示的服务器 理解的请求，但拒绝授权。一个服务器 希望让公众为什么请求已经被禁止可以 描述这一原因，在响应的有效载荷(如果有的话)。

如果认证的凭证都是在请求中提供，
服务器，认为它们不足以授予访问权限。客户
不应自动重复的请求，同
全权证书。客户可重复的请求与新的或不同的 全权证书。然而，一请求可能会被禁止的原因
无关的凭据。

一个起源服务器，希望"隐藏"目前存在的一个
禁止目标资源可以，而不是应有地位代码
404(未发现)。

因此，一个403(或404)现在可能意味着什么。提供新的证书可能有助于...或者，它可能不会。

我相信的理由，为什么这种情况已经改变是RFC2616假定HTTP的认证将使用当在实践今天的网络应用程序建立定义的认证方案的使用例如形式和饼干。

Answer 7

• 401未经授权：我不知道你是谁。这是一个身份验证错误。
• 403禁止：我知道你是谁，但你没有权限访问此资源。这是一个授权错误。

Answer 8

这是一个较旧的问题，但从未真正提出的一个选项是返回404.从安全角度来看，最高投票答案来自潜在的信息泄露漏洞。例如，如上所述，所讨论的安全网页是系统管理页面，或者更常见，是用户无法访问的系统中的记录。理想情况下，您不希望恶意用户甚至知道那里有页面/记录，更不用说他们没有访问权限。当我建立这样的东西时，我会尝试在内部日志中记录未经身份的/未经授权的请求，但返回404。

OWASP有一些关于攻击者如何使用这种类型作为攻击的一部分的信息。

Answer 9

这个问题在前段时间被问到，但人们的思想逐步举动。

第6.5.3节在此选秀中（由Fielding和Reschke撰写）给出状态代码403在 RFC 2616 。

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

我强调了我认为最突出的位。

6.5.3。 403禁止

403（禁止的）状态代码指示服务器理解请求但拒绝授权它。希望禁止禁止请求的服务器可以在响应有效载荷（如果有的话）中描述该原因。

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

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

无论您使用的任何惯例，重要的是在您的网站/ API中提供均匀性。

Answer 10

长话短说

• 401：与身份验证有关的拒绝
• 403：与身份验证无关的拒绝

实际例子

如果 阿帕奇 需要身份验证 （通过 .htaccess），然后你击中了 Cancel, ，它将响应一个 401 Authorization Required

如果 nginx 找到一个文件，但没有 访问权 （用户/组）读取/访问它，它将响应 403 Forbidden

RFC（2616 第 10 节）

401 未经授权 (10.4.2)

含义1： 需要认证

该请求需要用户身份验证。...

含义2： 认证不足

...如果请求已包含授权凭据，则 401 响应表明这些凭据的授权已被拒绝。...

403 禁忌 (10.4.4)

意义： 与认证无关

...授权没有帮助...

更多细节：

• 服务器理解该请求，但拒绝满足它。

• 它应该描述实体拒绝的原因

• 可以使用状态码 404（未找到）来代替

  （如果服务器想向客户端保留此信息）

Answer 11

它们未登录或不属于正确的用户组

你已经说过两种不同的情况;每种情况都应具有不同的响应：

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

在RFC上的注意，根据收到的评论为此答案：

如果用户未登录它们是未认证的，则其HTTP等效于401并且在RFC中误授予不授权。作为第10.4节状态为 401未经授权：

“请求需要用户身份验证。”

如果您未经认真验证，则401是正确的响应。但是，如果您未经授权，在语义上正确的意义上，403是正确的响应。

Answer 12

英文：

401

您可能允许访问，但出于某种原因您的要求 否认。比如密码差？重试，正确的请求 你会得到一个成功的回复。

403

允许，你不是。您的名字不在列表中，您不会 永远进入，消失，不要发送重新尝试请求，它会被拒绝， 总是。离开。

Answer 13

这些是含义：

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

403 ：用户身份验证，但他的角色或权限不允许访问请求的资源，例如用户不是管理员，请求的页面用于管理员

Answer 14

在这里比在这里的任何地方更简单，所以：

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

403：你看不到这个，HTTP Basic Auth无济于事。

如果用户只需要使用网站的标准HTML登录表单，那么401将不合适，因为它是特定于HTTP基本验证。

我不建议使用403拒绝访问生成的东西，因为就网关而言，这些资源根本不存在，因此应该为404。

这将离开403作为“需要登录”。

换句话说，403表示“此资源需要HTTP基本AUTH以外的某种形式的AUTH”。

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

Answer 15

我认为要考虑的是，到浏览器，401启动用户的身份验证对话框，以便输入新凭据，而403则不会。浏览器认为，如果返回401，则用户应重新验证。所以401代表无效的身份验证，而403代表缺乏许可。

以下是某些情况下的逻辑，其中错误将从身份验证或授权返回，重要的短语粗体。

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

401 ：客户端应指定凭据。

• 指定的凭据是无效格式。

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

• 指定的凭据引用 user 哪个不存在。

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

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

401 ：再次，客户端应指定有效凭据。

• 指定的凭据具有已过期。

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

• 指定的凭据完全有效，但不足以特定的资源，尽管有可能具有更多权限的凭据。

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

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

403 ：这意味着无论凭据如何，所以指定有效凭据无法帮助。

• 指定的凭据完全有效，但特定 client 是阻止从使用它们。

403 ：如果客户端被阻止，则指定新凭据不会做任何事情。

Answer 16

Given the latest RFC's on the matter (7231 and 7235) the use-case seems quite clear (italics added):

• 401 is for unauthenticated ("lacks valid authentication"); i.e. 'I don't know who you are, or I don't trust you are who you say you are.'

401 Unauthorized

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2). 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 agent SHOULD present the enclosed representation to the user, since it usually contains relevant diagnostic information.

• 403 is for unauthorized ("refuses to authorize"); i.e. 'I know who you are, but you don't have permission to access this resource.'

403 Forbidden

The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

Answer 17

In the case of 401 vs 403, this has been answered many times. This is essentially a 'HTTP request environment' debate, not an 'application' debate.

There seems to be a question on the roll-your-own-login issue (application).

In this case, simply not being logged in is not sufficient to send a 401 or a 403, unless you use HTTP Auth vs a login page (not tied to setting HTTP Auth). It sounds like you may be looking for a "201 Created", with a roll-your-own-login screen present (instead of the requested resource) for the application-level access to a file. This says:

"I heard you, it's here, but try this instead (you are not allowed to see it)"