401 Unauthorized

401 Unauthorized means the request lacks valid authentication credentials for the target resource, or the credentials supplied were rejected. Despite the name, it is about authentication, who you are, not authorization, what you're allowed to do, a subtlety the status name itself gets wrong. RFC 9110 requires that a 401 response include a WWW-Authenticate header naming at least one authentication scheme the server accepts, such as Basic, Bearer, or Digest, along with a realm identifying the protection space. A client that receives a 401 is expected to be able to retry the same request with credentials and succeed.

Modern APIs overwhelmingly authenticate with bearer tokens, typically JWTs, sent as Authorization: Bearer <token>. A 401 here usually means the token is missing, malformed, expired, or has been revoked; well-designed APIs distinguish these in the WWW-Authenticate header or response body using OAuth 2.0's Bearer error codes, such as error="invalid_token" for an expired JWT versus a simple absent header. JWT expiry is the single most common cause of 401s in production: the access token's exp claim has passed, and the client needs to use its refresh token to obtain a new one rather than treating the failure as fatal.

The 401-versus-403 distinction trips up many API designers. Use 401 when the server does not know who the caller is, or the credentials it received are invalid; the appropriate response is to authenticate or re-authenticate. Use 403 once the server does know who the caller is and has decided, based on that identity, to deny access regardless of credentials. Returning 403 for an unauthenticated request leaks information about resource existence without giving the client a path forward, while returning 401 for a permissions problem sends the client into a pointless login retry loop.

Browsers historically show a native credential prompt for 401 responses carrying a WWW-Authenticate: Basic header, which is why sites avoid Basic auth for user-facing pages. Single-page applications instead intercept 401 responses in an HTTP client interceptor, attempt a silent token refresh, and only redirect to a login screen if the refresh also fails. Clock skew between client and server is a quieter cause: if the server's clock is ahead, a token that looks valid to the client can appear expired to the server.