Ошибка 401 — что это значит и как исправить

If an error occurs, the request processing stops, and the server returns an HTTP response code that identifies the error. In addition to the code, the response contains a short error description.

The error message is returned in the format specified in the request URL after the method name or in the HTTP header.

The error description is passed in the parameter. This parameter contains the error code (the parameter) and a short error description (the parameter).

• For the 401 Unauthorized error:
• For the 403 Forbidden error:
• For the 404 Not Found error:
• For the 405 Method Not Allowed error:
• For the 415 Unsupported Media Type error:
• For the 420 Enhance Your Calm error:
• For the 503 Service Unavailable error:

GET /v2/campaigns.xml HTTP/1.1
Host: api.partner.market.yandex.ru
Accept: */*
Authorization: OAuth oauth_token=,oauth_client_id=b12320932d4e401ab6e1ba43d553d433

GET /v2/campaigns.json HTTP/1.1
Host: api.partner.market.yandex.ru
Accept: */*
Authorization: OAuth oauth_token=,oauth_client_id=b12320932d4e401ab6e1ba43d553d433

The 401 Unauthorized Error is an HTTP status code error that represented the request sent by the client to the server that lacks valid authentication credentials. It may be represented as 401 Unauthorized, Authorization required, HTTP error 401- Unauthorized. It represents that the request could not be authenticated. It consists of a www-Authenticate header which contains the hint on how to authorize correctly.

401 Unauthorized Error Occur: This error may occur due to the reasons described below:

• It may occur client does not provide the proper authentication credentials to the server within the request time.
• It may occur when the server rejects the request of the client for some reason even though the client provides proper authentication credentials.
• When the client is banned for some reason by the server.

• Check The URL: Due to manual errors in typing the URL, the 401 unauthorized error may occur. Hence, checking the URL and rectifying the mistakes in it will fix the 401 error status.
• Flush the DNS: Errors in DNS also creates 401 error status sometimes. Therefore, clearing the DNS will also rectify this error. In Windows, the DNS can be flushed by typing ipconfig/flushdns in the command prompt and clicking on ENTER.
• Clear Browser Cookie: In some situations, the cookies may not work smoothly leading to improper server authentication. Thus, by clearing the cookies, the error can be rectified.
• Logging out and Logging in again: This error may also occur during the maintenance time of the websites. Therefore, visiting the website and logging in again by providing the credentials may also rectify this error.

Some other ways of 401 Authentication error: This error can occur in the below forms also:

• 401.1: This error represents that the login has failed due to some reasons.
• 401.2: This error represents that the login has failed due to server configuration.
• 401.3: This error represents that the login has failed due to ACL(Access-control list) on the resource.
• 401.3: This error represents that the authorization has been failed by the filter.
• 401.501: This error represents that too many requests have been generated by the client i.e. maximum request limit has been reached by the client.
• 401.502: This error occurs when any specific client(sam IP) requests multiple times on a single server that the dynamic IP Restriction Concurrent request rate limit reached. Then this error will occur
• 401.503: This error represents that the IP address of the client is in the deny list of IP restrictions on the server-side.
• 401.504: This error represents that the Hostname of the client is in the deny list of IP restrictions on the server-side.

Trying to access a site and being met with an error page is at best inconvenient, whether that site is yours or someone else’s. As with many HTTP response codes, part of what makes a 401 error so frustrating is the lack of information it offers for diagnosing and resolving the issue.

The 401 error can happen with any browser, so it’s a pretty common issue people face. In most cases, this problem is relatively simple and straightforward to fix.

In this post, we’ll explain what 401 error messages are and why they happen. Then, we’ll walk you through five methods you can use to fix them.

Let’s get started!

The Internet Engineering Task Force (IETF) defines the error 401 Unauthorized as:

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 containing at least one challenge applicable to the target resource.

HTTP 400 status codes are encountered when there is a problem making a request. A 401 error, in particular, happens when your browser denies you access to the page you’re trying to visit.

As a result, instead of loading the web page, the browser will load an error message. 401 errors can happen within any browser so the message appearing may differ.

For example, in Chrome or Edge, you’ll likely see a paper icon along with a simple message telling you that the page in question isn’t working. It will include the phrase “HTTP Error 401” at the bottom, and instruct you to contact the site’s owner if the problem persists:

The 401 Error in Chrome

At other times and in other browsers, you might get a slightly less friendly warning that’s just a blank page with a “401 Authorization Required” message:

Nginx 401 Authorization Required error message

Other variations include:

• “HTTP 401 Error – Unauthorized”
• “401 Unauthorized”
• “Access Denied”

These errors occur on websites that require a login in order to access them. In most cases, it means that something is either wrong with the credentials or with the browser’s ability to read them as valid.

The code is sent via the WWW-Authenticate header, which is responsible for identifying the authentication method used for granting access to a web page or resource.

The HTTP 401 error is all too common 🤦‍♀️ — and this guide will give you everything you need to fix it the next time you see that message showing up ✅Click to Tweet

If you encounter an error code in the 400s, you know you’re dealing with a client-side (or browser-side) issue. While the problem may be happening within your browser, however, it doesn’t necessarily always mean that’s the culprit, which we’ll explain in more detail later.

401 errors occur on restricted resources, such as password-protected pages of your WordPress site. So it’s safe to assume that the cause of the problem has something to do with the authentication credentials.

Outdated Browser Cache and Cookies

One of the most common reasons you might experience a 401 error is that your browser’s cache and cookies are out of date, preventing the authorization from successfully going through. If your browser isn’t using the valid authentication credentials (or any at all), the server will reject the request.

Plugin Incompatibility

At other times, this error is caused by a plugin incompatibility or error. For example, a firewall or security plugin can mistake your login attempt as malicious activity, and return a 401 error to protect the page.

Incorrect URL or Outdated Link

It’s also possible that the source of the problem can be attributed to a minor mistake. Common culprits in this category include an incorrectly-typed URL or an outdated link.

Now that we’ve gone through a bit of background on the 401 error, it’s time to discuss how you can resolve it.

Let’s take a look at five methods you can use:

We’ll start off with the easiest potential fix: making sure you used the correct URL. This may sound simple, but 401 errors can sometimes appear if the URL wasn’t correctly entered in.

Another possibility is that the link you used to visit the page in question points to the wrong URL. For example, it might be outdated, or leading to a page that no longer exists (and no redirects are in place).

Therefore, it’s worth double-checking the URL you used. If you typed it in yourself, verify that you spelled everything correctly. If you clicked on a link, confirm that it’s pointing to the page you’re trying to access (or try to visit that page directly through the website).

Clear Your Browser’s Cache

Your browser’s cache is designed to improve your online experience, by reducing page loading times. Unfortunately, sometimes it can also cause unwanted interruptions.

As we mentioned earlier, one of the common causes of the 401 error is outdated or incorrect cache data or cookies. Therefore, if you don’t notice any issues with the page’s URL, the next step is to clear your browser’s cache.

This will clean out any invalid information that’s locally stored in your browser, which could be interrupting the authentication process. Similarly, your browser’s cookies might contain authentication data that simply needs to be refreshed.

The Clear browsing data section in Google Chrome

A new window will open. Under the Basic tab, make sure all three boxes are selected, and then select Clear data:

The clear browsing data window in Chrome

The ‘clear recent history’ option in Firefox settings

In the panel that opens next, select Everything in the drop-down menu at the top, make sure “Cache” is selected, and then click on the Clear Now button:

The ‘Clear History’ panel in Firefox

If you’re using a different browser, please refer to this guide for clearing the cache

Flush Your DNS

Another method you can try to resolve the 401 error is flushing your Domain Name Server (DNS). While this is a rarer issue, it can be a possible cause, so it’s worth giving it a try if the first two solutions don’t work.

To do this in Windows, click on the Start button and type cmd into the search bar. Hit Enter, and the Command Prompt will open. Copy and paste the command ipconfig/flushdns, and then hit Enter again:

The Command Prompt interface in Windows

The Terminal application on Mac

Input the command line sudo killall -HUP mDNSResponder and press Enter. Then, you can try refreshing the page you were trying to visit, to see if the 401 error has been resolved.

Deactivate Your WordPress Plugins

The problem causing your 401 error might not be due to your browser. If you’re having trouble accessing your WordPress site, it’s also possible that one or more plugins are to blame.

Some plugins, especially security-focused plugins, are configured to show a 401 error when they suspect suspicious login activity that might indicate an attack. Others might just be suffering from compatibility issues. Therefore, it’s a good idea to deactivate all of your WordPress plugins and see if that resolves the issue.

The plugin deactivation setting in the WordPress dashboard

After that, try reloading the page that returned the 401 error to see if this has resolved the issue. If it has, you can manually activate each plugin one at a time, in order to determine which one is causing the problem.

Then you can remove that plugin, replace it with a new one, or contact its developer for assistance.

Check the WWW-Authenticate Header Response

At this point, if the issue hasn’t been fixed, it may be caused by a server-side problem. This means our last fix will be a bit more involved.

In a nutshell, you’ll want to check and see if the header response was sent, and more specifically, what authentication scheme was used. At the very least, this can help narrow down the cause of the problem, and bring you one step closer to a solution.

To do this, go to the web page that’s displaying the 401 error, and access the developer console in Chrome. You can right-click on the page and select Inspect, or use Ctrl+Shift+J.

Next, click on the Network tab and reload the page. This will generate a list of resources. Select the Status header to sort the table and locate the 401 status code:

The 401 status code in the developer console in Chrome

Select that entry, and then click on the Headers tab. Under Response Headers, locate the WWW-Authenticate header:

The Response Headers section of the developer console

The information that is present in the response header, particularly the authentication schemes, can give you more information about what’s happening and point you towards a solution. It can help you understand what type of authentication the server is expecting.

HTTP 401 errors, begone! 🧙‍♂️ 5 ways to stop those pesky messages (no magic required) ✨Click to Tweet

Summary

When your browser and server have trouble communicating or authenticating requests, you’re sometimes forced to deal with errors such as the 401 error. While this problem is irritating, the message is usually temporary and fixable.

Here are five methods you can use to fix the 401 error:

• Look for errors in the URL.
• Clear your browser’s cache.
• Flush your DNS.
• Deactivate your WordPress plugins.
• Check the WWW-Authenticate header response.

Get all your applications, databases and WordPress sites online and under one roof. Our feature-packed, high-performance cloud platform includes:

• Easy setup and management in the MyKinsta dashboard
• 24/7 expert support
• Global audience reach with up to 35 data centers and 275 PoPs worldwide

Get started with a free trial of our Application Hosting or Database Hosting. Explore our plans or talk to sales to find your best fit.

The 401 Unauthorized Error is an HTTP response status code indicating that the client could not authenticate a request.

In this article, we’ll examine the 401 Error in more detail. We’ll show you how to diagnose and debug this error within your own application.

Server- or Client-Side?

All HTTP response status codes in the 4xx category are client error responses. These messages contrast with server error responses in the 5xx category, such as the 503 Service Unavailable Error.

However, the appearance of a 401 error code or any 4xx error doesn’t necessarily mean the client is the issue, where the client is the web browser or device used to access the application.

For example, if you’re trying to diagnose an issue with your application, you can ignore most client-side code. This includes HTML, cascading style sheets (CSS), client-side JavaScript, etc.

On the other hand, this doesn’t rule out the client as the actual cause of a 401 Unauthorized Error. While it’s probably not the HTML or CSS, it could be that the client may be sending a request that doesn’t contain any authentication information.

Even though the 401 Unauthorized Error is a client error response, it doesn’t mean we can rule out the server as the culprit. The server is still the network object producing the 401 Unauthorized Error and returning it as the HTTP response code to the client.

Start With a Thorough Application Backup

Before attempting any changes to the system, make sure to perform a full backup of your application, database, etc. If you can, create a complete copy of the application onto a secondary staging server. This will give you a clean testing ground to test all potential fixes without threatening the sanctity of your live application.

As discussed in the introduction, a 401 Unauthorized Error indicates that the client (the web browser, in most cases) has requested a restricted resource (such as a web page) from the server. Still, the client has failed to provide valid authentication credentials.

A 401 Error might occur in one of a handful of possible scenarios:

• The client sent its authentication credentials to the server, but the server rejected the credentials.
• The client failed to provide any authentication credentials within the request.
• The client is banned. Some applications use 401 Unauthorized Errors to restrict access requests from specific IP addresses.

Troubleshooting on the Client-Side

Since the 401 Unauthorized Error is a client error response code, it’s best to start by troubleshooting potential client-side issues.

Here are a handful of tips to try on the browser or device giving you problems.

Check the Requested URL

Double-check the exact URL returning the 401 error to ensure that it is the actual resource you intend to request.

Clear Relevant Cookies

are tiny pieces of data stored on your local device. Websites and applications then use cookies to «remember» information about this particular browser and/or device.

You only need to worry about cookies relevant to the website or application causing the problem in most cases. Cookies are stored based on the location of the domain, meaning you can remove only cookies that match the website domain (e.g., airbrake.io).

However, if you’re not experienced with manually removing certain cookies, it’s easier to clear all cookies at once.

Here are a few how-to articles to clear cookies depending on your browser:

Clear the Cache

Like cookies, local browser caches can cause 401  Unauthorized Error to appear. A cache is a collection of storage that retains local copies of web content on your device for later use. A browser’s cache typically stores compressed snapshots of webpages you frequently visit, including images and other binary data your browser often accesses.

With a local copy of these resources on your device, your browser doesn’t need to spend the time or bandwidth to download identical data every time you return to the same page.

Since your browser’s cache stores local copies of web content and resources, it’s possible that a change to the live version of your application is conflicting with the cached version already on your device, causing a 401 Unauthorized Error.

Try clearing your browser’s cache to see if that fixes the issue. As with cookies, clearing the cache is browser-dependent. Here are a few links to that relevant documentation for the most popular browsers:

Log Out and Log In

Since the application in question likely contains some form of authentication, the last client-side step to try is to log out and then log back in.

Clearing browser cookies will usually log you out automatically the next time you load the page. So, all you need to do is log back in.

In some situations, the application may be running into a problem with your previous session, which is a string that the server sends to the client to identify that client during future requests.

Your device stores session tokens (session strings) via cookies. The client then transfers these tokens to the server during a request. The problem is if the server doesn’t recognize the session token sent by the client or the token is invalid. This will result in a 401 error.

For most web applications, logging out and logging back in will force the local session token to be recreated.

Debugging Common Platforms

Common software packages and content management systems (CMS) can also be responsible for the 401 Unauthorized Error. If you’re seeing this error, take a look at the stability and functionality of these platforms.

The most common content management systems — like WordPress, Joomla!, and Drupal — are all typically well-tested. Still, once you start making modifications to the underlying extensions or PHP code (the language in which nearly all modern content management systems are written), it’s too easy to cause an unforeseen issue resulting in a 401 error.

Here are a few tips to help you troubleshoot some of these popular software platforms.

Rollback Recent Upgrades

If you recently updated your CMS and now you’re seeing a 401 error, consider rolling back to the previous version on your CMS.

Similarly, any extensions or modules you may have recently upgraded can also cause server-side issues. If you believe this is why you’re seeing an error, revert to your previous CRM version.

However, certain CMSs don’t provide a version downgrade capability in some cases. This indicates that the base application, along with each new version released, is stable and bug-free. You’ll typically see this with more popular platforms.

Uninstall New Extensions, Modules, or Plugins

Extensions, modules, or plugins serve the same purpose across every system. They improve the capabilities and features of your CMS.

But you should be cautious with extensions because they can take full control of the system and make virtually any changes to the PHP code, HTML, CSS, JavaScript, or database. As such, uninstall any new extensions that you added before the 401 error.

Check for Unexpected Database Changes

It’s worth noting that if you uninstall an extension through the CMS dashboard, this doesn’t that changes made by the extension will fully revert. This is particularly true for WordPress extensions that have been given carte blanche within the application. This often includes full access rights to the database.

There are scenarios where an extension may modify database records that don’t “belong” to the extension itself. The extension may not know how to revert alterations to database records in those scenarios, even if you uninstall it.

If you’re reasonably convinced an extension is a likely culprit for the status code 401 error, open the database and manually look through tables and records likely modified by the extension.

Troubleshooting on the Server-Side

If you aren’t running a CMS application or you’re confident the 401 Unauthorized Error isn’t related to your CSM — here are some additional tips to help you troubleshoot what might be causing the issue on the server-side.

According to the , a 401 Unauthorized Error response code sent by a server must also response header, which contains one or more challenges. Each challenge is a string indicating how proper authentication can be obtained to access the requested resource.

For example, a WWW-Authenticateheader of WWW-Authenticate: Basic realm=»Access to the production server» indicates to the client that authentication requests should be Basic (an id and password credential combination). This will give access to the “production server.”

With this knowledge in hand, you can attempt to diagnose the 401 Unauthorized Error you’re seeing on your application by confirming that the application is sending a valid WWW-Authenticate response header. This header can give you extra information that may lead to a solution, such as showing which particular are expected by the server.

You can view HTTP headers either from the server or the client web browser. View headers in Google Chrome by pressing F12 to open the developer console, select the Network tab, then load or reload the specific page/resource showing the 401 Error. This will show the list of all resources involved in the transaction, including everything from the actual document to individual images.

Sort the results by the Status by clicking the Status table header, then find the “401” status code. Select that entry in the list, and you should be able to view the Headers tab for that request. Look under Response Headers for the associated WWW-Authenticate header.

Check Your Web Server Configuration

Most modern web servers provide one or more configuration files that allow you to easily adjust the server behavior based on a wide range of circumstances. For example, the server may reject requests to certain directories or URLs, resulting in a 401 Unauthorized Error.

Configuration options for each type of web server can vary dramatically. Here’s a list of a few popular servers:

Look Through the Logs

Finally, if all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from by manually debugging your application and parsing through application and server logs.

Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, allowing you to recreate the exact scenario where the 401 Unauthorized Error occurred.

software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state-of-the-art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. Plus, Airbrake makes it easy to customize exception parameters, so you only gather the errors that matter most.

Airbrake’s error monitoring software today and see why so many of the world’s best engineering teams use Airbrake!

Frances Banks

There’s a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization.
Receiving a 401 response is the server telling you, “you aren’t
authenticated–either not authenticated at all or authenticated
incorrectly–but please reauthenticate and try again.” To help you out,
it will always include a WWW-Authenticate header that describes how
to authenticate.

This is a response generally returned by your web server, not your web
application.

It’s also something very temporary; the server is asking you to try
again.

So, for authorization I use the 403 Forbidden response. It’s
permanent, it’s tied to my application logic, and it’s a more concrete
response than a 401.

Another nice pictorial format of how http status codes should be used.

12 gold badges79 silver badges121 bronze badges

answered Aug 4, 2011 at 6:24

Edit: RFC2616 is obsolete, see RFC9110.

If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials.

The server understood the request, but is refusing to fulfill it.

10 gold badges43 silver badges51 bronze badges

answered Jul 21, 2010 at 7:28

99 gold badges880 silver badges1004 bronze badges

Something the other answers are missing is that it must be understood that Authentication and Authorization in the context of RFC 2616 refers ONLY to the HTTP Authentication protocol of RFC 2617. Authentication by schemes outside of RFC2617 is not supported in HTTP status codes and are not considered when deciding whether to use 401 or 403.

Brief and Terse

Unauthorized indicates that the client is not RFC2617 authenticated and the server is initiating the authentication process. Forbidden indicates either that the client is RFC2617 authenticated and does not have authorization or that the server does not support RFC2617 for the requested resource.

Meaning if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

Detailed and In-Depth

10.4.2 401 Unauthorized

10.4.4 403 Forbidden
The server understood the request but is refusing to fulfil it. Authorization will not help and the request SHOULD NOT be repeated.

The first thing to keep in mind is that «Authentication» and «Authorization» in the context of this document refer specifically to the HTTP Authentication protocols from RFC 2617. They do not refer to any roll-your-own authentication protocols you may have created using login pages, etc. I will use «login» to refer to authentication and authorization by methods other than RFC2617

So the real difference is not what the problem is or even if there is a solution. The difference is what the server expects the client to do next.

401 indicates that the resource can not be provided, but the server is REQUESTING that the client log in through HTTP Authentication and has sent reply headers to initiate the process. Possibly there are authorizations that will permit access to the resource, possibly there are not, but let’s give it a try and see what happens.

Edit: RFC2616 is obsolete, see RFC7231 and RFC7235.

answered Feb 5, 2013 at 17:14

1 gold badge17 silver badges4 bronze badges

Checks are usually done in this order:

• 404 if resource is public and does not exist or 3xx redirection
• OTHERWISE:
• 401 if not logged-in or session expired
• 404 if resource does not exist or not willing to reveal anything, or 3xx redirection

answered Feb 23, 2015 at 11:00

According to RFC 2616 (HTTP/1.1) 403 is sent when:

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead

In other words, if the client CAN get access to the resource by authenticating, 401 should be sent.

answered Jul 21, 2010 at 7:26

1 gold badge24 silver badges32 bronze badges

If HTTP authentication is not in use and the service has a cookie-based authentication scheme as is the norm nowadays, then a 403 or a 404 should be returned.

Regarding 401, this is from RFC 7235 (Hypertext Transfer Protocol (HTTP/1.1): Authentication):

3.1. 401 Unauthorized

The semantics of 403 (and 404) have changed over time. This is from 1999 (RFC 2616):

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

In 2014 RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content) changed the meaning of 403:

6.5.3. 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.

I believe the reason why this has changed is RFC 2616 assumed HTTP authentication would be used when in practice today’s Web apps build custom authentication schemes using for example forms and cookies.

answered Feb 27, 2013 at 9:44

• 401 Unauthorized: I don’t know who you are. This an authentication error.
• 403 Forbidden: I know who you are, but you don’t have permission to access this resource. This is an authorization error.

26 gold badges236 silver badges179 bronze badges

answered Aug 6, 2019 at 12:37

OWASP has some more information about how an attacker could use this type of information as part of an attack.

answered Dec 25, 2014 at 9:09

This question was asked some time ago, but people’s thinking moves on.

Section 6.5.3 in this draft (authored by Fielding and Reschke) gives status code 403 a slightly different meaning to the one documented in RFC 2616.

It reflects what happens in authentication & authorization schemes employed by a number of popular web-servers and frameworks.

I’ve emphasized the bit I think is most salient.

6.5.3. 403 Forbidden

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT 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.

Whatever convention you use, the important thing is to provide uniformity across your site / API.

answered May 22, 2014 at 10:54

7 silver badges11 bronze badges

These are the meanings:

answered Nov 19, 2019 at 10:17

1 gold badge86 silver badges77 bronze badges

TL;DR

• 401: A refusal that has to do with authentication
• 403: A refusal that has NOTHING to do with authentication

Practical Examples

If apache requires authentication (via .htaccess), and you hit Cancel, it will respond with a 401 Authorization Required

RFC (2616 Section 10)

Meaning 1: Need to authenticate

Meaning 2: Authentication insufficient

403 Forbidden (10

Meaning: Unrelated to authentication

(If the server wants to keep this information from client)

answered Feb 25, 2015 at 9:03

8 gold badges50 silver badges50 bronze badges

You have stated two different cases; each case should have a different response:

Note on the RFC based on comments received to this answer:

If you’re unauthenticated, 401 is the correct response. However if you’re unauthorized, in the semantically correct sense, 403 is the correct response.

answered Oct 1, 2012 at 14:34

9 gold badges66 silver badges88 bronze badges

I have created a simple note for you which will make it clear.

answered Nov 11, 2021 at 12:19

3 silver badges7 bronze badges

401: Who are you again?? (programmer walks into a bar with no ID or invalid ID)

403: Oh great, you again. I’ve got my eye on you. Go on, get outta here. (programmer walks into a bar they are 86’d from)

answered Aug 11, 2022 at 23:10

You are potentially allowed access but for some reason on this request you were
denied. Such as a bad password? Try again, with the correct request
you will get a success response instead.

You are not, ever, allowed. Your name is not on the list, you won’t
ever get in, go away, don’t send a re-try request, it will be refused,
always. Go away.

answered Apr 8, 2020 at 14:23

5 gold badges36 silver badges48 bronze badges

401: You need HTTP basic auth to see this.

403: This resource exists but you are not authorized to see it, and HTTP basic auth won’t help.

I don’t recommend using 403 to deny access to things like /includes, because as far as the web is concerned, those resources don’t exist at all and should therefore 404.

In other words, 403 means «this resource requires some form of auth other than HTTP basic auth (such as using the web site’s standard HTML login form)».

answered Sep 23, 2017 at 12:33

3 gold badges38 silver badges40 bronze badges

Here are some cases under that logic where an error would be returned from authentication or authorization, with important phrases bolded.

401: The client should specify credentials.

400: That’s neither 401 nor 403, as syntax errors should always return 400.

401: The client should specify valid credentials.

401: Again, the client should specify valid credentials.

401: This is practically the same as having invalid credentials in general, so the client should specify valid credentials.

403: Specifying valid credentials would not grant access to the resource, as the current credentials are already valid but only do not have permission.

403: This is regardless of credentials, so specifying valid credentials cannot help.

answered Jun 2, 2018 at 23:34

• An access token is missing.
• An access token is either expired, revoked, malformed, or invalid.

answered Feb 17, 2022 at 11:16

4 gold badges41 silver badges50 bronze badges

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

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.

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.

answered Jun 5, 2018 at 15:26

6 gold badges42 silver badges62 bronze badges

I have a slightly different take on it from the accepted answer.

It seems more semantic and logical to return a 403 when authentication fails and a 401 when authorisation fails.

Here is my reasoning for this:

When you are requesting to be authenticated, You are authorised to make that request. You need to otherwise no one would even be able to be authenticated in the first place.

If your authentication fails you are forbidden, that makes semantic sense.

On the other hand the forbidden can also apply for Authorisation, but
Say you are authenticated and you are not authorised to access a particular endpoint. It seems more semantic to return a 401 Unauthorised.

Spring Boot’s security returns 403 for a failed authentication attempt

answered Apr 6, 2022 at 22:44

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)»

answered Dec 12, 2014 at 19:01