HTTP 401 Unauthorized: Causes and Fixes

HTTP 401 Unauthorized means the request failed authentication: the server could not tell who you are because you did not provide valid credentials. The main cause is a missing, wrong, or expired token or session. Per the standard, the server must return a WWW-Authenticate header that hints which authentication scheme is required.

This article covers the standard's wording, the role of the WWW-Authenticate and Authorization headers, the key difference between 401 and 403, the main schemes (Basic, Bearer, Digest), client-side and server-side causes, and how to fix the error.

What HTTP 401 Unauthorized means

Status 401 Unauthorized belongs to the 4xx class of client errors. Per RFC 9110, §15.5.2, it means the request "has not been applied because it lacks valid authentication credentials for the target resource." The name is misleading: despite the word "Unauthorized", this is about authentication — the server could not establish your identity.

The standard requires that a 401 response must include a WWW-Authenticate header with at least one challenge applicable to the resource. This header tells the client which authentication scheme to use.

What a 401 response looks like

HTTP/1.1 401 UnauthorizedWWW-Authenticate: Bearer realm="api", error="invalid_token"Content-Type: application/json{ "error": "token_expired" }

The role of the WWW-Authenticate and Authorization headers

HTTP authentication is a dialogue between two headers. First the server replies with 401 and a WWW-Authenticate challenge ("identify yourself this way"). Then the client repeats the request with an Authorization header carrying the credentials in the required scheme.

GET /api/profile HTTP/1.1Host: example.comAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

If Authorization is missing, wrong, or the token inside it has expired, the server returns 401 again.

401 vs 403: what's the difference

These two codes are the most commonly confused. In short: 401 means "I don't know who you are" (an authentication problem), while 403 means "I know who you are, but you can't come in" (an authorization problem). The table below breaks down the differences.

Authentication schemes: Basic, Bearer, Digest

The WWW-Authenticate header names the scheme. The three most common are:

• Basic — username and password encoded in Base64 (SSL/TLS проверку only!). Authorization: Basic dXNlcjpwYXNz
• Bearer — an access token (usually JWT or OAuth 2.0). Authorization: Bearer <token>
• Digest — a hashed response to the server's challenge; never sends the password in the clear.

Basic authentication example

curl -v https://example.com/private   -H "Authorization: Basic dXNlcjpwYXNzd29yZA=="

Causes of a 401 error and how to fix it

Causes split into client-side and server-side.

• Expired token or session — the most common cause with API документацию. Fix: refresh the access token via the refresh token, or log in again.
• Wrong credentials — a typo in the login/password, or a wrong API key. Fix: double-check the credentials.
• Missing Authorization header — the client sent no credentials at all. Fix: add the header.
• Wrong scheme — the server expects Bearer but the client sends Basic. Fix: match the WWW-Authenticate header.
• Server configuration — for example, auth_basic is enabled in nginx or an API key is required.

Server-side Basic Auth in nginx

location /admin/ {    auth_basic           "Restricted Area";    auth_basic_user_file /etc/nginx/.htpasswd;}

With this configuration, any request to /admin/ without a valid Authorization header gets a 401 and a Basic challenge.

Tokens and sessions: why a 401 hits logged-in users

The paradox "I logged in but I get a 401" is explained by the token lifecycle. In modern APIs the access token is deliberately short-lived — from a few minutes to an hour. This limits the damage if the token leaks. When it expires, the server responds with 401, and the client must exchange a long-lived refresh token for a new access token.

POST /oauth/token HTTP/1.1Host: example.comContent-Type: application/x-www-form-urlencodedgrant_type=refresh_token&refresh_token=def502...&client_id=app

A well-built client intercepts the first 401, refreshes the token automatically, and retries the original request — the user never notices the pause. Without this logic, the user sees a sudden logout. That is why handling 401 is a mandatory part of any API client.

Common server-side causes of a 401 in APIs

• Key rotation — the old API key was revoked, but the app still sends it.
• Clock skew — a JWT with an exp claim is seen as expired due to wrong server time.
• Wrong realm or audience — the token was issued for a different service.
• Revoked session — an administrator forcibly ended the user's session.

How to check headers and authentication

To see the response code and the WWW-Authenticate header, use the free HTTP header and response code checker on enterno.io — it instantly shows the status and every response header. To assess the endpoint's overall security posture and the correctness of authentication schemes, our security scanner helps. Checking response headers is especially useful when you need to learn which scheme (Basic, Bearer, Digest) the server expects — that information always lives in the WWW-Authenticate challenge.

Related reading

To master response codes, see the HTTP status code reference and the breakdown of the 403 Forbidden error, which is often confused with 401. It also helps to understand how HTTP headers work, since they carry the credentials.

Frequently Asked Questions

How does 401 differ from 403?

401 Unauthorized means authentication failed: the server could not establish your identity because of missing, wrong, or expired credentials. 403 Forbidden means authorization failed: the server knows who you are but you lack sufficient rights. Re-authenticating helps with 401; with 403 only an administrator granting more rights will help.

Why do I get a 401 even though I am clearly logged in?

Most likely your access token or server session has expired. Access tokens are short-lived (minutes), and once they expire the server responds with 401. Refresh the token via the refresh token or log in again. Also verify that the Authorization header is actually being sent and holds a current value.

Is the WWW-Authenticate header mandatory in a 401 response?

Yes. Per RFC 9110, a server returning 401 must include a WWW-Authenticate header with at least one challenge applicable to the resource. It tells the client which authentication scheme to use — Basic, Bearer, Digest, and so on. A 401 without this header violates the standard.

How do I fix a 401 when calling an API?

Check in order: whether the Authorization header is sent, whether the scheme is correct (Bearer vs Basic), whether the token has expired, and whether the API key is valid. Run the request through curl -v to see the sent headers and the server response, including WWW-Authenticate with the error description.

Is Basic authentication secure?

Basic sends the username and password merely Base64-encoded — that is reversible encoding, not encryption. It is acceptable only over HTTPS, where all traffic is encrypted by TLS. Without HTTPS the credentials are effectively sent in the clear. For APIs, the Bearer scheme with short-lived tokens is preferable.