Authentication at Avanti

What is an authentication layer?

Authentication is a term that refers to the process of proving that some fact or some document is genuine. In computer science, this term is typically associated with proving a user’s identity. When we say a layer, it is usually “in-between”. Hence, an authentication layer is between the user and a resource they are trying to access, wherein the user proves their identity by providing their credentials, that is, an agreed piece of information shared between the user and the system.

The need for Avanti to have one?

Avanti’s resources are public, i.e. anyone with the address (or URL) of the resource can access it. This means we had no data about who all are using our resources and at what frequency, and we need this data to improve the products and services we offer. Therefore, we realised that a layer was needed between the user and the resource to track or record any activity. Many existing authentication products in the market could be used like Google Authentication, Okta, etc. But after user research, we realised that none of these products was a good fit for us.

The factors that contributed to the decision were:

• Our main users are students from low-income government schools across the country. This means, that each school would have a different kind of unique identifier for a student. For example, a school in Haryana would use a 10-digit number as the identifier, whereas a school in Delhi would use a string of 11 alphanumeric characters. The auth layer would have to support these different situations without adding a whole lot of overhead for us.
• Some could point out that email addresses would be a good choice of identifier. But through the user research, we found out that not all students have email addresses and even if we were to assign one, there were quite a lot of cases where the user would not be able to remember their email id. Hence, we decided to go with identifiers that they are already familiar with, for example, a registration number that they were assigned when they first enrolled into the school.
• Through the research, we also found out that there were cases where more than one student would access a resource using a single device. In these instances, we realised that the product should also have a feature to accommodate the entry of multiple credentials. This would help in identifying all the students trying to access the resource.
• Our list of resources is extensive. They can vary from a Plio to a live class on Google Meet. It could also be a Zoom meeting or a YouTube Live. We needed a product that could accommodate this list of resources without a lot of hassle.
• Another important feature that we wanted was tracking users accessing a particular resource. Currently, there was no way to keep track of which resources were being accessed by a given user. This is very helpful in trying to understand user behaviour and also, assess product performance. Apart from knowing who the user is, we also get to know information like at what time of the day is a particular resource more “popular”, how many students are attending online classes, how is attendance over a timeframe and so much more.
• Our users also comprise teachers who use our resources and content library to aid their teaching. We recognized that we needed some kind of tracking mechanism to understand how this section of our users interact with our products because this will indirectly reflect the impact our resources have on our students.

With all the above use cases in mind, we reached the conclusion that we needed to build our authentication layer that would be a good fit for the needs of our users. Building the auth layer was important for us because it helps us quantify the impact of our work and understand how we can help our users better.

How does it work?

CAPTION: In this picture, the user is a student studying in a Haryana government school, hence their unique identifier is a Student Registration Number (SRN).

To use any resource from Avanti, a user has to pass through the auth layer. The user has to enter a unique identifier (or credential) to gain access to the resource. If this credential matches the entry in the database, then the user is granted access. If the identifier does not match, there are several ways we deal with such a situation. One way is to restrict access if the credentials are wrong. In our case, since our users are students, we didn’t want to restrict their flow as the resources are usually learning tools like a live class or a Plio. Instead, we give them a second chance to type a correct ID. If they happen to enter an incorrect ID even the second time, we let the user through the auth layer but we store this activity in our database.

The main and useful difference between the entry of a “correct” ID vs an “incorrect” ID is how it is stored in our database. In our backend, we have a flag that is set to true if the ID is correct or validated. It is set to false if the ID is incorrect. This will help verify how many students know/remember their identifier. For instance, currently, we have data that shows about 70–80% of IDs being entered are valid. This will help the operations team on the ground to ramp up efforts in spreading awareness about the auth layer and about entering correct credentials.

Information about any attempt made by a user to pass through the auth layer is recorded in our database. The following are some details we store in our database for analytics:

• Date and time of when the user tried to pass through the auth layer
• What type of resource are they trying to gain access to? Is it a Plio, Google Meet, Zoom, YouTube Live or our content library?
• The ID of the specific resource. Eg-Plio ID or Meet ID
• The unique identifier that the user has entered
• Whether this unique identifier exists in our database of users

Another important feature of the auth layer is to strictly follow the paradigm of single responsibility and separation of concerns. What it means is that it does not care what the user is going to be doing with the resource or where the user has come from. All it needs to know is where the user wants to go and if they are allowed to go there.

CAPTION: In this picture, the user is a student studying in a Haryana government school, hence their unique identifier is a Student Registration Number (SRN)

CAPTION: Here, the user has entered two correct IDs, hence they are allowed to either type another ID or they can simply “submit” their IDs and access the resource.

CAPTION: In this case, the user hasn’t entered a valid ID, therefore, they are shown an error message.

Interested in the technical aspects?

Following is the tech stack used to build the auth layer:

• Frontend: VueJS, TailwindCSS
• Database: Firestore, BigQuery
• Backend: Firebase Cloud Functions, AWS Lambda
• Continuous Deployment (CD): Github Actions

Future roadmap

• Enabling One Time Password (OTP) as an authentication method.
• Restricting access to resources based on time, e.g. if an online class hasn’t started yet, then the auth layer isn’t going to allow students to enter that class.
• For now, the auth layer is being used in Haryana. Soon, we’ll be ramping up Delhi and Himachal Pradesh as well.
• Adding support for Google Form as a destination resource