Authentication Design Doc

Authentication in Gymkhana Application

Author: Saket Patel
Reviewers: Priyansh Garg
Status: Draft | In Review | Approved

---

Why do we need authentication?
We want to restrict access to Gymkhana application to the people of the institute. We will identify them via their official email id.

There are two ways we could go about it:

1. Basic/Token authentication (email and password mechanism)
2. Social authentication (using Google oauth2)

Let's talk about pros and cons of both the methods.

Basic Authentication

This authentication mechanism allows users to authenticate themselves by using their official mail ID and a password of their choosing. Application will deny authentication if email id is not official.

Users will be shown a form for login and another for signup. Once they sign up, an OTP is sent to their official mail ID, which they need to enter before they are allowed the access to the website. While logging in OTP is not required initially. But later on MultiFactor Authentication can be provided as a feature to make platform more secure for the users.

Pros

• No extra library to be used rest_framework.authtoken can be used for token authentication, after basic authentication.
• Login will be available on the institute's intranet when Internet access goes down.

Cons

• Introduces complexity in the code as we are taking care of authentication, although we can delegate it to django/rest_framework, some additional mechanisms like sending/verifying OTP while signing user up will need to be taken care of.
• Storing passwords locally on the database.

Social Authentication

As our mail server is hosted on Google Workspace, we can leverage Google OAuth2 social authentication to sign/log users in. Users will be given an option to SignUp/LogIn using Official Mail ID on the landing page. When users click on that button they'll be redirected to accounts.google.com for authentication. Once user signs/logs in on the google, they'll be redirected back to the website with an access-token. This access-token is sent to our API which validates it and exchanges it for a local OAuth token for our API. Clients will then use this new OAuth token to authenticate themselves to the API.

Pros

• Minimum complexity in the implementation as these mechanisms can be handled by libraries like: drf-social-oauth,
• Some initial configuration might need to be done on Google Cloud Platform to create client-id and client-secret for our API.
• One click authentication for the users.

Cons

• Users won't be able to login/signup when the Internet access in the institute is down.

I am leaning towards having social authentication initially and if need arises we can always provide basic authentication additionally.

Design for Social Authentication

User interaction with the interface and corresponding processes in backend goes like the following:

1. User clicks on Login using Google -> Gets redirected to accounts.google.com for authentication.
2. User authenticates and allows access to information like emailID and public profile -> Gets redirected back to a redirect_uri configures with Google.
3. UI sends the access_token received from Google to the API -> API validates the token internally with Google and generates internal access_token
4. User receives the internal access_token and stores it in the sessionStorage to reuse it.
5. User is logged in -> Moving forward user needs to send this internal access_token with each request to the API.

Above is just the high level view of how it is going to be like. We might face some issues while implementation which are hard to estimate at this point.