Authorization

Accessing a protected resource requires presenting credentials. The HTTP Authorization request header carries these credentials, authorizing the client to interact with the resource.

Table of Contents

Usage
Directives
- authentication-scheme
Example
Troubleshooting
Basic vs Bearer
See also

Usage

The Authorization request header obtains access to a protected resource and is typically sent after the client is informed access is restricted. For example, after receiving a 401 Unauthorized HTTP response from the server including the WWW-Authenticate header, the client submits credentials in this fashion.

Note

Browsers strip the Authorization header when a request is redirected to a different origin. This prevents credential leakage when a redirect points to a third-party server. The behavior is defined in the WHATWG Fetch Standard and is supported in all modern browsers. Applications relying on Authorization headers across cross-origin redirects need to handle re-authentication at the final destination. Tools like curl, Python Requests, and Go's HTTP client follow the same convention.

Directives

authentication-scheme

The authentication-scheme is a mandatory directive, accompanied by optional scheme-specific parameters. The scheme defines the encoding method for credentials. Common approaches include Basic, Bearer, Digest, and Negotiate.

Example

In this example, the client uses the basic Authentication scheme. As a required parameter, the credentials are a base64-encoded username:password pair.

Authorization: Basic RXhhbXBsZTphaQ==

A Bearer token is common with OAuth 2.0 APIs. The token is an opaque string or a signed JWT issued by an authorization server.

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

Troubleshooting

Authorization failures often surface as unexpected 401 responses or silently dropped credentials.

Credentials stripped on cross-origin redirect. Browsers and HTTP clients remove the Authorization header when a request redirects to a different origin. The fix is to send credentials directly to the final destination or re-authenticate after the redirect completes. Inspect redirect chains with curl -L -v to confirm where the header disappears.
Base64 encoding errors in Basic authentication. The encoded string must contain exactly one colon separating username and password. A missing colon or double-encoded value produces a garbled token the server rejects. Verify the raw value with echo -n "user:pass" | base64 and compare against the header value sent in the request.
Bearer token expired or malformed. Tokens carry an expiration claim, and servers reject expired tokens with 401. Decode a JWT at jwt.io or with echo "<token>" | base64 -d to inspect the exp field. Token refresh logic must run before the token expires, not after the server rejects the request.
401 loop when server omits WWW-Authenticate. The server returns 401 but does not include the WWW-Authenticate header, leaving the client with no indication of the expected scheme. Check the response headers with curl -I https://example.re/resource and confirm the server configuration includes the header. In nginx, the auth_basic directive adds the header automatically. Custom backends need to set the header explicitly.
CORS preflight blocking the Authorization header. Cross-origin requests carrying Authorization trigger a preflight OPTIONS request. The server must respond with Access-Control-Allow-Headers: Authorization on the preflight. A missing or incorrect value causes the browser to block the request before sending credentials. DevTools Network tab shows the preflight as a separate OPTIONS entry.
curl sends credentials to the wrong endpoint. Running curl -H "Authorization: Bearer ..." with -L follows redirects but strips the header on cross-origin hops. Use curl -v without -L to send the header to the exact endpoint, or pass --location-trusted to force credential forwarding across redirects (use with caution on trusted domains only).

Basic vs Bearer

Basic and Bearer are the two most common Authentication schemes, serving different use cases.

Basic sends a Base64-encoded username:password pair on every request. The encoding is trivially reversible, making HTTPS mandatory. Credentials are static and tied to a user account, so a compromised password requires changing the password itself. Basic works well for internal tools and simple integrations where token management adds unnecessary complexity.

Bearer uses opaque tokens (often JWTs) issued by an authorization server. Tokens expire, carry scoped permissions, and are revocable without changing the underlying password. Bearer is the standard mechanism for APIs and OAuth 2.0 flows. A stolen token has a limited lifetime and limited scope, reducing the blast radius compared to a leaked password.

Both schemes transmit credentials in cleartext within the header value. Neither provides encryption on its own. HTTPS is required regardless of the scheme chosen.

A cross-origin API request with a Bearer token using the Fetch API.

fetch('https://api.example.re/data', {
  headers: {
    'Authorization': 'Bearer eyJhbGci...'
  }
})