What is an Authentication Header and How Does It Work?

Decloak is an AI-powered web security intelligence platform that scans a site's HTTP/TLS posture, JavaScript, and third-party scripts to produce a report anyone can read. This guide is part of Decloak's library of practical, source-backed security guidance.

Key takeaways

• The authentication header is the Authorization request header that carries credentials.
• It follows the syntax Authorization: <auth-scheme> <credentials>.
• The server sends a WWW-Authenticate challenge before the client includes the header.
• Common schemes include Basic, Digest, Bearer, and AWS4-HMAC-SHA256.
• The header is stripped on cross - origin redirects for security.

What exactly is an authentication header?

An authentication header is a request header that carries the credentials a client uses to prove its identity to a server. The standard name for this header is Authorization.

How does the server request credentials?

The server responds with a 401 Unauthorized status and includes a WWW-Authenticate header that lists the supported authentication schemes. The client reads this challenge and then sends the Authorization header on subsequent requests.

What is the exact syntax of the header?

The header follows the pattern:

Authorization: <auth-scheme> <credentials>

<auth-scheme> identifies the authentication method (e.g., Basic, Digest, Bearer, Negotiate, AWS4-HMAC-SHA256). <credentials> contain the data required by that scheme, such as a Base64 - encoded username:password for Basic or a token for Bearer.

Which authentication schemes are most common?

• Basic - encodes username:password in Base64.
• Digest - uses a challenge - response hash to avoid sending clear text passwords.
• Bearer - carries a token such as a JWT or OAuth access token.
• Negotiate - used for Kerberos or SPNEGO.
• AWS4-HMAC-SHA256 - signs requests for AWS services. Each scheme defines how <credentials> are generated and validated.

Why is the header stripped on cross - origin redirects?

For security reasons browsers remove the Authorization header when following a redirect to a different origin. This prevents accidental credential leakage to sites the user did not intend to authenticate with.

How should developers implement the header?

1. Detect a 401 response that includes WWW-Authenticate.
2. Choose a supported scheme.
3. Generate the appropriate credential string.
4. Add the header to subsequent requests, e.g.:

GET /protected/resource HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

1. Ensure the header is not sent to third - party domains unintentionally.

Common pitfalls to avoid

• Sending the header on initial unauthenticated requests; the server will reject it.
• Storing plain - text credentials in client - side code; use secure storage or token - based schemes.
• Assuming the header works across all browsers for all redirect scenarios; test cross - origin behavior.

How does this relate to overall web security?

The Authorization header is a core part of HTTP authentication. Proper use protects resources from unauthorized access, while misuse can expose credentials or enable attacks such as credential leakage through redirects.

Further reading

• MDN Web Docs: Authorization header
• MDN Web Docs: WWW-Authenticate header