Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Last reviewed: February 20, 2026|Editorial standard: source-backed comparison guidance
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token", error_description="The access token expired"
{
"error": "invalid_token",
"message": "Access token is expired or malformed."
}HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer realm="api", error="insufficient_scope", scope="orders:write"
{
"error": "insufficient_scope",
"required_scope": "orders:write"
}Return 401. In bearer-token flows, include challenge error metadata (for example `invalid_token`) so clients can refresh or re-authenticate deterministically.
When HTTP authentication semantics are used, 401 should include a challenge describing expected auth scheme and recovery path.
Generally no. Missing or invalid credentials belong to 401, while 403 is for authenticated identities that still do not have required permission.
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Learn when to return 404 (missing or temporary absence) versus 410 (intentional permanent removal), including redirect and cache implications.