Authentication protocols work as the first line of defence within computer networks, allowing access to valuable data to only those who are approved and authenticated. Authentication is one of the most preferred data protection methods for secure communication between two parties, with organisations often utilising Multi-Factor Authentication as an extra layer of protection. Each authentication protocol is used to provide an exact series of steps required for the execution of the authentication.
There are various authentication models available, including:
- Basic Authentication
- Token Bearer Authentication
- Token Authentication
- Oauth2 Authentication
A method that isn’t hugely popular but is a very secure way of authentication is Digest Authentication, which is being explored in this blog post. Digest authentication is a protocol that allows service providers to securely verify credentials through a web browser.
The major advantage of Digest Authentication is that it doesn’t require the username and password to be sent using plaintext, because it uses a one-time number from the server. This is what differs it from basic authentication and makes the protocol immune to replay-attacks.
How does digest authentication work?
The server gives the client a one-time use number (Nonce) that it combines with the username, realm, password and Uniform Resource Identifier (URI) request.
The client runs all those fields through an MD5 hashing method to produce a hash key. It sends this hash key to the server along with the username and the realm to attempt to authenticate.
Server side, the same method is used to generate a hash-key, only instead of using the password typed into the browser, that server looks up the expected password for the user from the user database.
It looks up the stored password for this username, runs it through the same algorithm and compares it to what the client sent. If they match, access is granted. Otherwise, it can send back a 401 Unauthorised (no login or login failed) or a 403 Forbidden (access denied)
In simple, digest authentication works by:
1. Client makes request.
2. Client gets back a nonce from the server and a 401-authentication request.
3. Client sends back the following response array (username, realm, generate_md5_key(nonce, username, realm, URI, password given by user to browser)).
4. Server takes the username and realm (already knows the URI the client is requesting) and it looks up the password for that username. It then does it’s own version of the generate_md5_key (nonce, username, realm, URI, password assigned for this user in the database)
5. It compares the output of generate_md5() that it got with the one the client sent. If they match, the client sent the right password. If there is no match, the password sent was incorrect.
Digest Authentication in Business Central
If you are looking to integrate a third-party solution with Microsoft Dynamics 365 Business Central and utilise Digest Authentication protocols, we have created a function, shown below.
The first step is to get access to the authentication URL with the username and password.
Once successfully authenticated, we get the ‘Nonce’
The Nonce is then used to get the token using the algorithm.
Now using the Nonce value, we get the Session ID.
Blog information provided by: Naval Kosambe
Interested in learning more about digest authentication?
Leave your details in the contact form to get started.
