What is the difference between Basic and Bearer authentication?

Basic sends a base64-encoded username and password on every request, so it must run over TLS. Bearer sends an opaque or JWT token issued by an authorization server; anyone holding the token can use it until it expires, so short lifetimes and TLS are essential.

Is Basic authentication encrypted?

No. Basic only base64-encodes the credentials, which is trivially reversible. It provides no confidentiality on its own and must always be carried over HTTPS, where TLS supplies the encryption.

How does Digest authentication avoid sending the password?

Digest is a challenge-response scheme: the server sends a nonce, and the client returns a hash of the username, password, nonce and request details. The password itself never crosses the wire, though weak hash choices like MD5 and the lack of body integrity mean TLS is still preferred.

Why is NTLM discouraged in favour of Kerberos?

NTLM is vulnerable to relay and pass-the-hash attacks and authenticates per-connection rather than per-request. The Negotiate scheme prefers Kerberos, which provides mutual authentication and ticket-based security, and Microsoft now actively deprecates NTLM.

Where do I put the scheme name in the request?

The client sends it in the Authorization header, for example Authorization: Bearer eyJ.... The server advertises which schemes it accepts via the WWW-Authenticate header in a 401 response, or Proxy-Authenticate for a 407.

HTTP Authentication Schemes

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

When a server protects a resource it answers with 401 Unauthorized and a WWW-Authenticate header naming an authentication scheme; the client then resends the request with a matching Authorization header. The scheme name — Basic, Bearer, Digest, Negotiate and others — decides the entire credential format and security posture. This reference lists the registered schemes with their syntax and the caveats that matter.

How it works

HTTP authentication is a simple challenge cycle. The server’s WWW-Authenticate (or Proxy-Authenticate for proxies) lists one or more schemes and parameters such as a realm or a nonce. The client picks a scheme it supports and replies with Authorization: <scheme> <credentials>. Some schemes are single-shot (Basic, Bearer); others are multi-round handshakes that exchange several messages (Digest, Negotiate/NTLM, SCRAM).

Crucially, encoding is not encryption. Basic merely base64-encodes user:password, so it leaks credentials over plain HTTP and must run on TLS. Bearer tokens are equally sensitive — holding the token is enough to act as the user.

Tips and examples

Header forms you will see most often:

Authorization: Basic ZGVtbzpwYXNzd29yZA==
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Authorization: Digest username="demo", realm="api", nonce="...", response="..."
Authorization: Negotiate YIIZ...   (Kerberos / SPNEGO)

For modern APIs, prefer Bearer over TLS with short-lived, signed tokens whose signature, audience and expiry you validate server-side. Reserve Basic for internal tools behind TLS, avoid NTLM in favour of Negotiate/Kerberos for Windows SSO, and reach for Digest only when you cannot use TLS but still must avoid sending the password in clear.