Authentication Module

authentication bc

Figure 1. Module’s DDD Diagram

It has been decided that we will integrate with Google’s OAuth service, this is a safe protocol that simply passes through Google’s Auth Services in order to validate a user, if it’s successfully validated we will then just save the Google Metadata in the system. (This takes away the need to create a user through the system and simply leverage a Google account). This is a fundamental design choice, we are coupled with Google OAuth due to this.

Two-Factor Authentication

In order to add an extra layer of security to the application, 2FA can be enabled for a user (the user himself has the capacity to do that for himself). This will also integrate with an external 2FA application. The ones that have been tested and are recommended are: Google Auth, Microsoft Auth.

Once the user "switches on" 2FA, a small flow in order to register with an Auth App is triggered, and every-time the user logs into the system he will be asked for the 2FA code. (TBD: We could also enable a small check to ask the user if he wants to remember the device so that 2FA is not asked on this device).

Whilst for "ease-of-use" an option can be checked to remember the device, we have to be mindful that this is a financial management system. It holds critical information in regards to a person. So we have to add an extra confirmation check for the user explaining the meaning of remembering the device. This is the pilar of how the system should be understood.

Google OAuth

In order to ease login and registering operations, the system leverages Google OAuth 2. Meaning that the authentication and authorization side of things in order to get user meta-data will be leveraged through Google APIs.

This integration consists of building URLs specifically for a web application, that the user then interacts with, and after the flow is successful we can retrieve information in order to talk to Google APIs on the user’s behalf and get basic data around them, both in order to create a user, but also to log him into the system without the need to ask for password or user.

User flows

first-time-user-uc-diagram

Figure 2. First Time User

recurring-user-uc-diagram

Figure 3. Internal User

As a summary, the way we will offer an entrypoint to the user will be as follows:

  1. We will leverage Google Auth basically for the most part. We won’t store user passwords whatsoever, and will act as a proxy with Google Auth. If a user is a guest, we will trigger a flow that talks between Google, the API, Web Client so that by the end gets Google’s info on the user and creates under the hood an Internal User that will be saved on KakeiBro’s side.

  2. The moment we have an internal-user, the way to interface with it, will be through its e-mail. If we find that e-mail we will keep an internal check of the user token that was saved there, if it’s within the grace period, we will pass it onto the client allowing for the user to log-in. Otherwise the authentication with Google will have to take place again, but instead of creating an internal user we will simply update the token that it has assigned to it.

  3. In case the grace period has been fulfilled, we will ask the user to re-authenticate, however this will just request for another OAuth token and we will update that on the already existing internal user table, we will also invalidate the previous token on the Google OAuth side.

We are putting as the Grace Period an interval of Two Weeks.

The value

We are leveraging automation in the way that we don’t want for the user to have to fill-in all their details and for us to manage all of that, we are assuming they have a gmail email, and we are forcing them to use it so that we can interface with Google and get that user’s info directly and setup everything under the hood. Giving a much more smooth user experience. Besides if we have to interface with Google in whatever capacity, may it be just for sending e-mails, we are 100% sure that we will have the user’s email in order to send emails to him.

Extra Detail: Another trend when it comes to a smooth UX with Google OAuth is to launch its flow on a small new window that mimics what a dialog would look like. Once the whole flow is done, the main app web page refreshes and it then launches into the home.

Security concerns

Due to us having to store the Google Auth token, we have to keep it under tight wraps. And so we will encrypt it, and pass it onto the client only after a handshake is established and the grace period since the token was created hasn’t been achieved.

And so the e-mail will be bumped in level of importance from just one part of the authentication equation to the sole key. This won’t work on an open-ditributed type of system, but since this is aimed at personal finances. We are assuming it will be consumed only by a select group of people. Trying to use the system for a SAAS is highly discouraged. Unless a password and extra security mechanisms are implemented, if someone gets a hold of the e-mail he can easily log into the user’s environment and access everything, this being financial information, which is sensitive. Even though we have optionally 2FA, a way to mitigate risk would be to make 2FA mandatory.

It’s also worth noting that the frontend will never save the token. These are stateful tokens in a way, since the backend will be always giving the frontend the token it has saved (encrypted) on its side, we will also have the encrypted form of the token in the web client’s memory.