Is it correct that there are various ways that a HTTP client can authenticate itself with a HTTP server?
Yes. There are many, many ways. Custom authentications schemes are common.
Are the following such ways?
- authorization header: for various authorization protocols (e.g. basic, digest, ...)
- digital certificates: as used in HTTPS.
- specify user name and passwords in HTTP request's message body, by applying HTTP POST method on form data
Yes. Those are all ways authentication can happen. Although, nota bene, client certificate authentication usually involves the Authorization
header with protocol = digest. Also sending username and password in a POST body is sloppy unless you're creating an account. It works, but it's sloppy. unusual unless the request is coming from an actual HTML form.
Are they used individually or together? Are they used for the same or different purposes? When is each way used?
Only one authentication scheme is used at a time. Digest authentication is used when replay attacks are a real threat. Digest authentication involves a nonce such that the same MAC will not work twice. Basic authentication is more vulnerable to replay attacks but TLS encryption would need to be broken (or absent) to make this possible.
Client certificates are used when the server wants to check the veracity of the client's claimed identity using a trusted third party.
In the second way, is digital certificates specified in some HTTP request header(s)? (In curl, it is specified via --cerf
)
The client certificate itself would be specified in the body of an HTTP request. Client certificate authentication requires multiple requests and responses passed statefully.
In the third way, when specify user name and passwords in HTTP request's message body, are they encrypted? Does the server know how to decrypt them?
They are encrypted if the request body itself is encrypted. This is the case in any https
request. If you want details of the encryption and decryption system, read about TLS/SSL.