Certificate Based Authentication

Authentication
Authentication is the act of confirming or verifying the identity of a person or device. It is one of the most common features in systems/applications. There are different types of authentication available, which include password-based, biometric (facial recognition), social logins, etc.

There is another type known as CERTIFICATE-BASED-AUTHENTICATION, which we are going to discuss in this blog.

What is Certificate-Based-Authentication?

In this type of authentication, users do not have to provide passwords or usernames, rather they are authenticated with their electronic documents (digital certificates).

Asymmetric cryptography is used in certificate-based-authentication.

…quick recap (Symmetric v/s Asymmetric Cryptography)

In symmetric, there is only one key that is used for both encryption and decryption. On the other hand in asymmetric, there is a public-private key pair, public key is used to encrypt and to decrypt private key is being used. Also in asymmetric, public key is shared with others for encryption and Private key will remain with the entity for decryption.

…back to Certificate-Based-Authentication

So here the digital certificates are public-private key pairs. In this blog, we’ll be discussing the scenario in which the client wants to authenticate itself with the server. So the key-pair would be generated for the client.

Can you guess from the recap section that where the private key and the public key of the client should be?

You’re Right!! If your guess is that the public key will be on the server (for encryption) and private key (for decryption)will be on the client. (If you guessed the opposite case, then we can discuss it in the comments section).

The key pair can be generated either on the client or server end, it depends on the requirement. Let’s have a brief look at both scenarios.

Generation on the client
For instance, when we use Github with ssh the key-pair is generated on our machines (client end), and we can revoke the access by ourselves, as we are managing our accounts. In this scenario, we (client) will provide its public key to Github (server).

Generation on the server
But if there is a case in which only server is allowed for account creation and revocation, then the key-pair is generated on server end, and private key is being shipped to the client (there could be different options of shipping private key to the client, we’ll not discuss those options here).

In both cases, the client will have its private key and the server will have a client’s public key.

How does it work?

Let’s discuss each step in the above diagram (thanks to mermaid for providing ease to create sequence diagrams), gist can be found here:

1. The client wants to access a resource from the server, it will request to create a session with the server by sending its identifier.
2. The server after validating clients using the client’s identifier will generate a random phrase this phrase is a plain-text.
3. Server caches this plain-text against the client’s identifier.
4. Server encrypts this plain-text with the PUBLIC KEY of the client, and returns it back to the client
5. Client will try to decrypt this encrypted phrase with the PRIVATE KEY, and after decryption, it will get the plain text.
6. Client will send this decrypted plain-text to the server.
7. Server will verify the received decrypted text with the plain-text which was cached at step 3.
8. If verification is successful the server will respond with successful authentication otherwise response would be authentication failed.

This is how certificate-based-authentication works.

In this blog we have covered the conceptual part, the implementation (in python) will be covered in the next blog.