HTTP headers · Request
Authorization
Authorization carries credentials that prove the client may access the resource.
Key facts
| Type | Request |
|---|---|
| Syntax | <code>Authorization: Bearer <token></code> |
| Schemes | Basic, Bearer, Digest, custom |
| Basic | Base64 of user:password, not encryption |
| Caching | Must not be stored by shared caches |
| Redirects | Strip when the origin changes |
| Transport | TLS required in practice |
| Standard | RFC 9110 §11.6.2 |
A scheme plus credentials
The value starts with an authentication scheme, then scheme-specific data. Basic encodes the username and password in Base64, which is reversible and therefore only safe over TLS. Bearer carries an opaque token whose meaning is defined by the issuer, such as an OAuth 2.0 access token.
The server answers a missing or invalid credential with 401 and a WWW-Authenticate challenge. A 403 is different: the caller is authenticated but not allowed to perform the action.
Leaks and redirects
Authorization headers must not be written to logs, error reports or shared caches. When a client follows a redirect to another origin, the header must be removed; otherwise the credential leaks to a third party. Browsers implement this, but custom HTTP clients often do not.
Tokens should be short-lived and scoped to the smallest set of actions that works. A long-lived token in a mobile app or a script is a standing key to the account, not a session.
Frequently asked questions
Is Basic auth encrypted?
No. Base64 is an encoding. Only the TLS layer protects it in transit.
Should I put an API key in Authorization?
Yes, preferably with a scheme such as Bearer. Query-string keys end up in logs, browser history and referrers.