401 Unauthorized vs 403 Forbidden

401 = 'I don't know who you are' (missing or invalid credentials). 403 = 'I know who you are, you can't have this'. Misusing them confuses clients and breaks browser auth flows.

intermediate RFC 7235 §3.1 (401), RFC 7231 §6.5.3 (403)

What the RFC says

401 Unauthorized: The server generated this response when the request requires user authentication... A user agent that wishes to authenticate will usually do so by including an Authorization header field containing the credentials. (RFC 7235 §3.1) — RFC 7235 §3.1 (401), RFC 7231 §6.5.3 (403)

Example

GET /api/users HTTP/1.1
Authorization: (none)

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

# vs.

GET /api/admin HTTP/1.1
Authorization: Bearer <valid token, but role=user>

HTTP/1.1 403 Forbidden

Real-world implementations

Browsers retry 401 with credentials prompt; they do NOT retry 403.
OAuth flows return 401 when access token is expired (refresh and retry); 403 when scope is insufficient (no auto-fix possible).
Cloudflare Access returns 401 for unauthenticated requests, 403 for authenticated-but-blocked requests.

Common misuses (don't do this)

Using 403 when no credentials were sent → client can't trigger a re-auth flow.
Using 401 without `WWW-Authenticate` header → spec violation, clients confused.
Returning 403 to hide that a resource exists — better to return 404, since 403 confirms existence.

Use cases

API authentication design
OAuth / OIDC flow troubleshooting
WAF / security middleware behavior
Single sign-on integration

Get the RFC reference for any HTTP response

httpwut takes a curl response and explains the status code + headers + the RFC sections you should actually read. Built for HTTP debugging that goes deeper than 'lol 500'.

Open httpwut