HTTP status code 401 or 403? How authentication and authorization errors differ
401 Unauthorized indicates the client is not authenticated, requiring valid credentials. 403 Forbidden signifies the client is authenticated but lacks the necessary permissions to access the resource.
Product & Design
Every time you load a webpage, make a payment or log into an app, there’s an invisible conversation happening between your device and a server. It’s a bit like sending a message and waiting for a reply—sometimes it’s a thumbs-up, sometimes it’s a polite ‘try again,’ and occasionally, it’s an outright ‘no.’ These responses, known as HTTP status codes, are the unsung heroes of the internet, silently guiding the flow of communication and making sure everything runs smoothly—or at least letting you know when it doesn’t.
What are HTTP status codes
HTTP status codes are like signals in a conversation between a client (like your browser or app) and a server. They provide quick and clear updates about what happened when you made a request—whether everything went smoothly, something went wrong, or additional action is required. Let’s think of it like visiting a well-run bakery:
200: Everything is perfect
You ask for a croissant, and the baker smiles, hands it over, and says, “Here you go!” That’s an HTTP 200 OK—the request was successful, and everything worked as expected.
The 200 OK HTTP status code is one of the most commonly used codes, indicating that the request from the client was successfully received, understood, and processed by the server.
301: We’ve moved
You arrive at your favorite bakery, but there’s a sign saying, “We’ve moved to 123 New Street.” This is a 301 Moved Permanently. The server tells your browser to go to the new address automatically.
The 301 Moved Permanently HTTP status code indicates that the requested resource has been permanently moved to a new URL. This status code informs the client (e.g., a browser or API client) to update its records and use the new URL for future requests.
404: Sorry, it’s not here
You ask for a chocolate scone, and the baker says, “We don’t make those here.” That’s a 404 Not Found—the resource you’re looking for doesn’t exist on the server.
The 404 Not Found HTTP status code indicates that the server could not find the requested resource. This response means the client’s request was valid, but the server couldn’t locate the resource it was asked for.
401: Who are you?
You try to enter the VIP lounge, but the bouncer stops you and says, “You need to show your membership card.” That’s a 401 Unauthorized—authentication is required before you can access the resource.
The 401 Unauthorized HTTP status code indicates that the client’s request has not been applied because it lacks valid authentication credentials. The server requires the client to authenticate itself to access the requested resource.
403: Not for you
You show your membership card, but the bouncer says, “Only platinum members can enter.” That’s a 403 Forbidden—you’re authenticated but don’t have the permissions needed to access the resource.
The 403 Forbidden HTTP status code indicates that the server understands the client’s request but refuses to fulfill it because the client does not have the necessary permissions. This is different from a 401 Unauthorized status, as the client is authenticated (or the request doesn’t require authentication), but access to the resource is explicitly denied.
500: The oven’s on fire
You place an order, but suddenly smoke starts pouring out of the kitchen. The baker says, “We can’t fulfill your order; something went wrong internally.” That’s a 500 Internal Server Error—the server encountered an unexpected issue.
The 500 Internal Server Error HTTP status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request. It is a generic error response and does not provide specific details about what went wrong.
503: Temporarily unavailable
You visit the bakery, but there’s a “Closed for Maintenance” sign. The bakery will reopen later. That’s a 503 Service Unavailable—the server is temporarily unable to handle your request, often due to overload or maintenance.
The 503 Service Unavailable HTTP status code indicates that the server is temporarily unable to handle the request. This could be due to server overload, maintenance, or other temporary conditions. Unlike a 500 Internal Server Error, a 503 implies that the issue is expected to be resolved soon.
HTTP status codes are key for maintaining efficient communication between clients and servers. They quickly inform clients whether their requests succeeded, failed, or require further action. For developers and IT professionals, understanding these codes helps debug issues, design better error handling, and improve overall user experience.
Think of them as professional, standardized signals in the ongoing conversation of the internet.
In this article, I want to focus on the 401 and 403 errors, as they are closely related to authentication (AuthN) and authorization (AuthZ).
When to use 401 Unauthorized?
The 401 Unauthorized HTTP status code is used when the client request requires authentication, but it is either missing, invalid or has failed. It tells the client that they need to authenticate themselves to access the requested resource. The relationship between authentication and the 401 Unauthorized status code lies in the role of authentication in determining whether a request can proceed.
401 unauthorized must include a WWW-Authenticate header, providing details on how to authenticate.
So, what are common scenarios for using 401 Unauthorized?
-
Authentication missing
The request does not include the required authentication credentials. For example: A request to a protected API endpoint is made without an Authorization header.
-
Invalid authentication credentials
The client provides credentials, but they are incorrect or do not match what the server expects. For example, a user sends an invalid API key or a malformed token.
-
Expired authentication token
The authentication token is valid but has expired, requiring the client to re-authenticate. For example, a JWT token with a past expiration date (exp claim).
-
Missing or malformed authorization header
The authorization header is required but is either not provided or incorrectly formatted.
-
Authentication scheme not supported
The server does not support the authentication method provided by the client. For example: The client sends a Basic authentication header, but the server only supports Bearer tokens.
-
Invalid session or token revocation
The user’s session has been invalidated, or their token has been revoked. For example: A user logs out, but the same token is used to access a protected resource.
Example response
When to use 403 Forbidden?
The 403 Forbidden HTTP status code means the server understands the request and the client’s identity (if authenticated) but denies access due to insufficient permissions. It clearly signals, “You are not allowed to do this,” ensuring clear access boundaries and reinforcing security policies.
The distinction between 401 Unauthorized and 403 Forbidden lies in their roles within authentication and authorization contexts.
Authorization is a separate mechanism from authentication. While authentication identifies who you are, authorization determines whether you can access specific resources and what actions you can perform on them.
To check out the detailed difference about authN and authZ. Check out those following articles.
So what are the common scenarios for using 403 Forbidden?
-
Authenticated but lacks permission
The client is logged in or authenticated but does not have the required permissions or role. For example, a user with a “viewer” role tries to delete a file, which requires “editor” privileges.
-
Resource access restricted
Access to the resource is intentionally restricted to specific users or groups. For example: A private document shared with specific users is accessed by someone not on the access list.
-
IP or geographic blocking
The client’s IP address or geographic location is blocked by the server. For example: a user from a restricted region tries to access a service that only operates in specific countries.
-
Blocked actions by policy
The client is attempting an action prohibited by server-side policies or rules. For example: a user tries to modify a resource that is marked as “read-only.”
-
Blocked static resources
The server denies access to specific static files or directories for security reasons.
Example: A user tries to access a .htaccess file or a server’s configuration file.
-
Account suspended or disabled
The client’s account is disabled or blocked due to violations or inactivity. For example: A user with a suspended account tries to log in or access resources.
-
Action requires elevated permissions
The requested action requires special privileges (e.g., admin or superuser). For example: A standard user tries to access admin-only endpoints.
Example Response:
How can I troubleshoot a 401 unauthorized error
A 401 error typically indicates that authentication is required and has failed.
Check credentials
Ensure the Authorization header is present and correctly formatted and verify the credentials (API key, token, or password) are correct and not expired. Entering the wrong username or password is one of the most frequent causes of a 401 error.
Confirm authentication method
The server may expect a different authentication method than what is being provided. This can happen if the client and server are not aligned on the authentication protocol. Use the correct method (e.g., Basic, Bearer, API Key) as specified by the server and check for proper syntax in the headers.
Inspect the server response
Review the response body for error details and Look at the WWW-Authenticate header for authentication instructions.
Verify the request
Confirm the endpoint, query parameters, and host are correct and ensure the resource you’re accessing requires authentication.
Check token issues
Decode and inspect the token (e.g., with https://logto.io/jwt-decoder) for validity, expiration, and claims and match the token’s audience (aud) to the API’s requirements.
How can I troubleshoot a 403 forbidden error
A 403 forbidden error typically means the authorization process was completed, but access was denied. To troubleshoot this error, considering the following conditions:
Verify permissions
Confirm that your account, API key, or token has the required permissions for the resource. Check if the resource is restricted to specific roles or groups.
Ensure authentication is correct
Make sure you’re authenticated properly (e.g., with a valid token or credentials).
Double-check the authentication method required by the server.
Validate the resource
Confirm that the requested resource exists and you have access to it. If using APIs, verify endpoint requirements in the documentation.
Look for IP or location blocking
Check if your IP address or geographic location is restricted by the server.
Review server policies
Ensure the requested action doesn’t violate server-side rules or policies (e.g., accessing a read-only resource).
Inspect the server response
Examine the response body for details explaining the reason for the 403 error.
Can a single request return both 401 and 403 status codes
No, a single HTTP request cannot return both 401 Unauthorized and 403 Forbidden status codes simultaneously because an HTTP response can only include one status code.
The practical use of 401 and 403 error codes in authentication and authorization
In modern application development, 401 Unauthorized and 403 Forbidden are two HTTP status codes developers encounter frequently. While they may seem similar, their meanings and use cases are distinctly different. To clarify their differences, this article explores practical examples of these codes in scenarios like authentication, authorization, multi-tenancy, and multi-factor authentication (MFA).
- Log in scenario: A user tries to access a protected page without logging in or providing a valid credentials. The server responds and throws a 401 Unauthorized error: “You need to log in or provide valid credentials to access this page.”
- Access control scenario: The same user logs in successfully but tries to access an admin-only page without the required admin role. The server responds and throws a 403 Forbidden: “You are logged in, but you don’t have permission to access this page.”
- Multi-tenant scenario: The same user logs in but belongs to Tenant A and tries to access a resource in Tenant B, where they don’t have access. The server responds and throws a 403 Forbidden: “You are authenticated, but you don’t have permission to access this resource in Tenant B.”
- MFA scenario: A user tries to log in but hasn’t completed the required Multi-Factor Authentication (MFA). The server responds and throws a 401 Unauthorized error: “Authentication is incomplete. Please complete MFA to proceed.”
Using Logto as an authentication and authorization provider
Logto is primarily an authentication provider, offering key methods like passwordless login, email and password, MFA, Enterprise SSO, and social login, all based on open-standard protocols such as OIDC, OAuth 2.0, and SAML.
Logto Cloud also provides essential authorization features, including Role-Based Access Control (RBAC), Organizations (Multi-Tenancy), and Custom Token Claims to meet a variety of authorization needs.