Key takeaway
A 401 response must include a WWW-Authenticate challenge. A 403 means the request was understood but refused; the reason may be unrelated to credentials. Compare the challenge with server logs.
401 signals an authentication challenge
HTTP 401 indicates that authentication was not correctly supplied or accepted. RFC 9110 requires a server returning 401 to send a WWW-Authenticate challenge identifying the applicable authentication scheme; check the scheme, realm and whether a proxy passes the header. HTTP 403 means the server understood the request but refuses to fulfill it; the reason may be a policy, resource state or another condition unrelated to authentication. Identify which layer responded: proxy, identity provider or application.
Checks for users, applications and administrators
A user can check login details, sign out and back in, and check the device clock; if the problem persists, clear cookies for that site. An API client should check the Authorization scheme, token expiry, refresh flow and current API documentation. A comparison using a known-good credential helps isolate a client, credential or server problem. For an OAuth Bearer token with insufficient scope, the standard calls for 403; distinguish this from 401 for an invalid token. Administrators should review SSO or identity-provider configuration, time synchronization, proxy and firewall header handling, revoked keys and account status.
Use authentication failures as a control signal
A rise in 401 responses may indicate credential stuffing, brute force or a broken integration. Compare IP, account, application, time, successful logins and location; do not classify one failed request as an attack. Use MFA, short-lived tokens with refresh, least privilege and centralized revocation. Never log secrets such as tokens or passwords.