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.

What is the HTTP Authentication Schemes?

Searchable reference for HTTP authentication scheme names used in the Authorization and WWW-Authenticate headers, including Basic, Bearer, Digest, Negotiate, NTLM and SCRAM, with syntax, RFC and security guidance. Bundled offline. It runs free in your browser on Gera Tools, with nothing uploaded.

HTTP Authentication Schemes

Name: HTTP Authentication Schemes
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

The challenge-response cycle

Client  ──GET /api/resource──►  Server
Client  ◄──401 WWW-Authenticate: Bearer realm="api"──  Server
Client  ──GET /api/resource, Authorization: Bearer <token>──►  Server
Client  ◄──200 OK──  Server

The WWW-Authenticate header names one or more schemes and their parameters (such as realm for both human display and credential scoping, or nonce for Digest). The client picks a scheme it supports and replies with the matching Authorization header. Proxy authentication follows the same pattern using Proxy-Authenticate (server→client) and Proxy-Authorization (client→proxy), with 407 Proxy Authentication Required replacing 401.

Scheme comparison

Scheme	Header form	Password on wire?	Multi-round?	Typical use
`Basic`	`Basic base64(user:pass)`	Yes (encoded, not encrypted)	No	Internal tools over TLS
`Bearer`	`Bearer <token>`	No (token)	No	REST APIs, OAuth 2.0
`Digest`	`Digest username="...", nonce="...", response="..."`	No (hashed)	No (1 challenge)	Legacy HTTP auth avoiding cleartext
`Negotiate`	`Negotiate <SPNEGO blob>`	No (Kerberos ticket)	Yes	Windows SSO / Kerberos
`NTLM`	`NTLM <blob>`	No (challenge-response)	Yes (3-way)	Legacy Windows auth
`SCRAM-SHA-256`	`SCRAM-SHA-256 ...`	No (proof)	Yes	Modern SASL-based auth

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. 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 (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.

The four you actually encounter

Basic — simplest, most dangerous without TLS

Authorization: Basic ZGVtbzpwYXNzd29yZA==

ZGVtbzpwYXNzd29yZA== is just btoa("demo:password"). Use only over HTTPS.

Bearer — the modern API standard

Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

The token is typically a signed JWT. Validate the signature, audience (aud) and expiry (exp) on the server. Use short lifetimes (15–60 minutes) and refresh tokens for long sessions.

Digest — avoided for new systems

Authorization: Digest username="demo", realm="api", nonce="abc123",
               uri="/resource", qop=auth, nc=00000001, cnonce="xyz",
               response="<MD5 hash>"

Sends a hash of credentials rather than the credentials themselves. MD5-based Digest is considered weak; prefer Bearer over TLS.

Negotiate — Windows SSO via Kerberos

Authorization: Negotiate YIIZ...

SPNEGO wrapping a Kerberos or NTLM token. The Negotiate scheme prefers Kerberos; fall back to NTLM only when Kerberos is unavailable. Microsoft actively deprecates standalone NTLM due to relay attack vulnerabilities.