HTTP Authentication

Flow

The challenge and response flow works like this:

The server responds to a client with a 401 (Unauthorized) or 407 (Proxy Authentication Required) response status and provides information on how to authorize with a WWW-Authenticate or Proxy-Authenticate response header containing at least one challenge.
A client that wants to authenticate itself with the server can then do so by including an Authorization or Proxy-Authorization request header with the credentials.
Usually a client will present a password prompt to the user and will then issue the request including the correct Authorization or Proxy-Authorization header.

HTTP Authentication Sequence Diagram

Basic: base64-encoded credentials. See RFC 7617 - The ‘Basic’ HTTP Authentication Scheme (2015.9).
Digest: SHA-256 algorithm credentials. See RFC 7616 - HTTP Digest Access Authentication (2015.9).
Bearer (also called token): bearer tokens to access OAuth 2.0 (with bearer format JWT). See RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage and Swagger - Bearer Authentication.
HOBA See RFC 7486, Section 3, HTTP Origin-Bound Authentication, digital-signature-based
Mutual See RFC 8120
Negotiate / NTLM See RFC 4599
VAPID See RFC 8292
SCRAM See RFC 7804
AWS4-HMAC-SHA256 See AWS docs. This scheme is used for AWS3 server authentication.

WWW-Authenticate: Basic realm="<str>"

Authorization: Basic <base64-str>

location /status {
    auth_basic            "Access to the staging site";
    auth_basic_user_file  /etc/apache2/.htpasswd;
}

WWW-Authenticate: Digest realm="<str>", nonce="<random-str>", algorithm="SHA512"

Authorization: Digest username="<username>" realm="<str>" algorithm="SHA512" nonce="<random-str>" response="<md-str>"