The HyperText Transfer Protocol provides a few authentication methods within the protocol. Due to the implementation, these are not often used for a typical user login as they are not considered user friendly, but can be handy with automation.
Basic Authentication
HTTP Basic Authentication is defined by RFC 7617. It is a simple authentication scheme built into HTTP which utilizes the Authorization header to send user credentials.
The header needs to contain the word Basic followed by a space and a base64 encoded string containing the username and password, separated by a colon.
For example, to authorise with the username Example and the password insecurePassword you would need to send the following header:
Authorization: Basic RXhhbXBsZTppbnNlY3VyZVBhc3N3b3Jk
Base64 can be reversed easily, as such, if you are using Basic Authentication you should ensure that HTTPS is enabled so that your credentials are transported securely.
Digest Authentication
Digest Authentication was originally defined by RFC 2069, which has now been replaced by RFC 2617. We'll look at the RFC 2069 implementation first, as the RFC 2617 implementation adds to it.
Whilst MD5 is a hash function, it is not considered secure. As such, if using Digest Authentication you should ensure that HTTPS is enabled so that your credentials are transported securely.
RFC 2069
With Digest Authentication, the server will return a WWW-Authenticate header when a client attempts to access a restricted resource. This header will contain a 'realm', a 'nonce', and an 'opaque'. The client will use these, and the user credentials to create the response. The nonce is used to generate a hash for the client response and should be unique for each request. The opaque is a string sent to the client that is expected to be in the client response unaltered. Finally, the realm is a string sent to the user to allow them to identify which credentials they need to present.
When the client receives a WWW-Authenticate header it then calculates hashes based on the username, realm, password, request method, request URI, and the nonce. Specifically, three hashes are computed:
Hash1 is the MD5 output of username:realm:password
Hash2 is the MD5 output of requestMethod:requestURI
And finally, the response that will be sent back to the server is computed as the MD5 output of Hash1:nonce:Hash2
The client then sends an Authorization header back to the server with the following data:
Authorization: Digest username="%s", realm="%s", nonce="%s", opaque="%s", uri="%s", response="%s"
RFC 2617
RFC 2617 enhances Digest Authentication specified in RFC 2069 by adding 'qop', 'nc', and 'cnonce' values to the response.
qop stands for 'Quality of Protection' and is specified in the WWW-Authenticate header with either a value of 'auth' or 'auth-int', if set to auth-int the client is required to include the request body in the response, allowing the server to determine if the request has been tampered with.
cnonce stands for 'Client Nonce' which is similar to the nonce already covered, but is instead generated by the client. This is added into the response digest, but is also passed in the Authorization header to allow the server to compare and ensure the integrity of the request. If qop is sent by the server, the client must provide a client nonce.
Finally, nc stands for 'nonce count' and is a hexadecimal count of the number of requests the client has sent with that nonce value. This allows the server to prevent replay attacks.
When the client receives a WWW-Authenticate header it then calculates hashes based on the username, realm, password, request method, request URI, nonce, client nonce, qop and nonce count. Specifically, three hashes are computed:
Hash1 is the MD5 output of username:realm:password
If auth-int is specified in the qop Hash2 is the MD5 output of the request method, the URI and the MD5 output of the response body, separated by :'s. RequestMethod:URI:responseBodyMD5 else Hash2 is the MD5 output of requestMethod:requestURI
And finally, the response that will be sent back to the server is computed as the MD5 output of Hash1:nonce:nc:cnonce:qop:Hash2
The client then sends an Authorization header back to the server with the following data:
Authorization: Digest username="%s", realm="%s", nonce="%s", uri="%s", qop="%s", nc="%s", cnonce="%s", response="%s", opaque="%s"
Certificate Authentication
First defined in RFC 2247, Certificate Authentication (also known as Mutual Authentication) adds an extra step to the initial TLS Handshake which requests a certificate from the client. Typically TLS is used to verify the identity of the server you are connecting to via a certificate, however, it is also possible for the server to verify the client via a certificate too. We'll only cover the TLS1.3 implementation here, which is defined in RFC 8446.
If enabled, after the client hello and server hello messages the server will request a Client Certificate, which is then verified in the same manner as the Server Certificate, via Certificate Authorities. Once the server has verified the certificate is valid and legitimate symmetric encryption can be established instead of the typical asymmetric encryption.
If you have any questions about Origin Authentication or would like to know how to implement it for your use-case, feel free to contact through ticket by emailing hi@stackpath.com.