401 - Unauthorized
HTTP 401 Unauthorized means the request lacks valid authentication credentials for the target resource.
Last reviewed: March 6, 2026|Editorial standard: source-backed technical guidance
What Does Unauthorized Mean?
Authentication did not succeed, so the server challenges the client and blocks access until valid credentials are presented for this resource.
Common Causes
- -JWT audience claim targets another API resource, so auth middleware rejects token even though signature validation succeeds.
- -Server clock drift beyond allowed skew causes nbf or exp checks to fail for otherwise valid bearer tokens.
- -Reverse proxy strips Authorization header on internal redirects, so upstream receives unauthenticated requests consistently.
How to Fix Unauthorized
- 1Inspect authentication challenges and confirm the expected auth scheme is being used.
- 2Refresh or replace credentials and ensure auth headers survive all gateway hops.
- 3Retest with a known-good credential path and verify unauthorized responses are cleared.
Step-by-Step Diagnosis for Unauthorized
- 1Capture the exact request and authentication challenge details returned with Unauthorized (401).
- 2Validate credential source, expiration, and forwarding behavior across proxy or gateway layers.
- 3Check authentication headers (including challenge headers) and confirm scheme compatibility end to end.
- 4Retest with one known-good credential path to isolate middleware or environment-specific auth drift.
Challenge and Scheme Alignment
- -Inspect
WWW-Authenticatechallenges and verify the client responds with the expected auth scheme (example: server challenges for Bearer while client still sends Basic). - -Validate realm/audience expectations from the challenge path (example: token minted for wrong API audience despite valid signature).
Credential Lifecycle and Transport
- -Audit token issuance, expiry, and refresh behavior under real traffic (example: refresh race emits expired token for one request window).
- -Trace Authorization header preservation across proxies and service mesh (example: ingress strips header on internal redirect).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 401 Unauthorized
# {"error":"Unauthorized","code":"401"}const response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' }
});
if (response.status === 401) {
console.error('Handle 401 Unauthorized');
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'}
)
if response.status_code == 401:
print('Handle 401 Unauthorized')How to Verify the Fix
- -Re-run the same request and confirm 401 is cleared with valid authentication context.
- -Confirm challenge and credential flows behave correctly under normal and peak traffic.
- -Review logs to verify repeated authentication failures no longer appear for the same route.
How to Prevent Recurrence
- -Automate credential rotation and expiration monitoring across all runtime environments.
- -Standardize authentication libraries and proxy forwarding rules for authorization metadata.
- -Add pre-deploy checks for auth scheme, challenge handling, and token validity windows.
Pro Tip
- -alert on spikes in 401 grouped by
WWW-Authenticatechallenge value to detect auth-scheme drift before user-facing outages.
Decision Support
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Playbook
Auth Incident Playbook (401 / UNAUTHENTICATED)
Use this playbook to separate missing, expired, or invalid identity proof from authorization and transport failures, and apply credential-source-correct fixes safely.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.