Authorization: credentials on a request
Authorization carries credentials for the target resource, written as a scheme name followed by the credential itself, most often Basic or Bearer.
At a glance
- Direction
- Request only. The challenge that asks for it is WWW-Authenticate.
- Defined in
- RFC 9110, with Basic in RFC 7617 and Bearer in RFC 6750
- When absent
- The server treats the request as anonymous, and answers 401 with a challenge if credentials were required.
- Structure
- A scheme token, a space, then the credentials: Bearer eyJhbGciOi...
- Basic
- Base64 of user:password. Encoding, not encryption, so it needs HTTPS.
- Across redirects
- Well behaved clients drop it when the redirect goes to a different host.
- In CORS
- Never covered by an Access-Control-Allow-Headers wildcard; it must be named.
In detail
The value is a scheme and a credential. Basic encodes a user name and password with base64, which is reversible by anyone who sees it and therefore only acceptable over HTTPS. Bearer carries a token whose meaning is entirely up to the issuer, which is why the header itself tells you nothing about whether that token is a session identifier, a signed assertion or an API key.
It is scoped to the target host. Clients that follow redirects are expected to drop the header when the destination is a different host, because forwarding credentials to whatever a redirect names would leak them to any site that could influence the redirect. That is the reason a command line request that works directly fails after a redirect unless you explicitly opt in to forwarding.
A response to an authorised request is not cacheable by a shared cache unless it says so explicitly, which is a deliberate default that stops one user's data being served to another. Marking such a response public without thinking through who the shared cache serves is one of the more damaging caching mistakes available.
In CORS it has a rule of its own: an Access-Control-Allow-Headers wildcard never covers it. Any cross-origin API that authenticates with a bearer token has to name Authorization in its allow list explicitly, no matter how permissive the rest of its policy is.
Examples
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9printf 'alice:s3cret' | base64
# YWxpY2U6czNjcmV0
Authorization: Basic YWxpY2U6czNjcmV0Base64 is an encoding, not a protection. Anyone who can read the request can read the password.
Things that catch people out
- Base64 is not encryption. Basic credentials over plain HTTP are readable by anything on the path.
- Following a redirect to another host drops the header in most clients, so a resource that works directly can fail behind a redirect for reasons that never appear in the logs.
- Logging full request headers writes live credentials into your log store, which is a durable copy of something meant to be short lived.
Try it: HTTP Headers Checker
Check a live URL or paste headers you already have. It grades six security headers from A+ to F and lists every other header the response returned.
HTTP Headers Checker
LOCAL · Browser-OnlyView HTTP response headers for any URL
Enter any website URL to fetch and analyze its HTTP response headers. We'll automatically add https:// if needed.
Why Check Security Headers?
Security headers protect your website against common attacks like XSS, clickjacking, and MIME sniffing. They're set by your web server and cost nothing to implement. Missing security headers are one of the most common findings in security audits.
Related HTTP headers
All http headers →WWW-Authenticate: the challenge that comes with a 401
What a 401 challenge must contain, what realm means to a browser, how Bearer error codes are reported, and why a 401 without this header is malformed.
Proxy-Authorization: credentials for the proxy itself
How proxy authentication differs from origin authentication, why the header is hop by hop, what a 407 means, and how tunnelled connections handle it.
Access-Control-Allow-Headers: permitted request headers
Which request headers trigger a preflight, how to answer with the right allow list, and the one header a wildcard never covers.
Cache-Control: directives for browsers and shared caches
Every Cache-Control directive that matters, the difference between no-cache and no-store, and how to cache immutable assets forever without breaking deploys.
Cookie: what the browser sends back
How the Cookie header is formatted, why attributes never come back, how the browser decides which cookies to include, and what the size limits are.
Set-Cookie: attributes, SameSite and cookie prefixes
Every Set-Cookie attribute explained, why SameSite=None needs Secure, what the __Host- prefix guarantees, and how Max-Age and Expires interact.
Tools for this
- HTTP Request Builder Free online HTTP request builder - build and test HTTP requests with custom headers and body
- HTTP Headers Checker Free online HTTP headers checker - view HTTP response headers for any URL