HTTP 401 Unauthorized — What It Means and How to Fix It

What causes this error

HTTP 401 means the request lacked valid authentication. Common causes: missing `Authorization` header, expired JWT or session token, malformed Bearer token (extra whitespace, missing `Bearer ` prefix), token issued for a different audience or issuer, cookie not sent due to `SameSite` restrictions, or the `Authorization` header being stripped by a reverse proxy.

How to fix it

1. 01

   step 1

   Check the WWW-Authenticate response header

   RFC 9110 requires the server to include a `WWW-Authenticate` header on 401 responses describing the expected auth scheme. It often includes an `error` param (`invalid_token`, `expired_token`, `missing_token`) that pinpoints the exact failure.

   curl -si https://api.example.com/endpoint | grep -i 'www-authenticate'

   Copy
2. 02

   step 2

   Decode your JWT and check expiry

   Copy your token to jwt.io and check the `exp` claim. Tokens expire by design. If `exp` is in the past, your client needs to refresh the token before retrying. In production, build token refresh logic — don't rely on long-lived tokens.

   // Decode JWT payload (no verification — only for debugging)
   const payload = JSON.parse(atob(token.split('.')[1]))
   console.log('Expires at:', new Date(payload.exp * 1000))
   console.log('Issued for:', payload.aud, payload.iss)

   Copy
3. 03

   step 3

   Verify the Authorization header format

   The header must be exactly `Authorization: Bearer <token>` — one space between `Bearer` and the token, no extra quotes, no newlines. A common mistake is including the word 'Bearer' twice or adding a trailing space.

   # Correct
   curl -H 'Authorization: Bearer eyJhbGci...token...'
   
   # Wrong (double Bearer)
   curl -H 'Authorization: Bearer Bearer eyJhbGci...'
   
   # Wrong (Basic instead of Bearer)
   curl -H 'Authorization: Basic eyJhbGci...'

   Copy
4. 04

   step 4

   Check if the proxy is stripping the Authorization header

   Nginx, AWS ALB, and some API gateways strip `Authorization` headers in certain configurations — especially when `proxy_pass` is used without forwarding headers explicitly. Add `proxy_set_header Authorization $http_authorization;` in Nginx.

   # nginx.conf
   location /api/ {
       proxy_pass http://backend;
       proxy_set_header Authorization $http_authorization;
       proxy_set_header Host $host;
   }

   Copy
5. 05

   step 5

   Debug cookie-based auth with SameSite issues

   If using session cookies, cross-origin requests won't send cookies unless `SameSite=None; Secure` is set. Check Chrome DevTools → Application → Cookies to confirm the cookie is being sent. Also ensure the server sets `Access-Control-Allow-Credentials: true` and the client uses `credentials: 'include'`.

   // Fetch with credentials (cookies sent cross-origin)
   const res = await fetch('https://api.example.com/me', {
     credentials: 'include',  // required for cross-origin cookies
   })

   Copy

How to verify the fix

• The 401 no longer appears after sending a valid, non-expired token.
• The `WWW-Authenticate` header is absent from successful responses.
• Token refresh logic is in place so sessions don't expire silently in production.