MRG - Auth Architecture

Project

Project Description

Based on the situation, not being able to do the /logout in OKTA, and therefore not finishing a session in OKTA, this is a sketch of a new way to manage our users without losing control of them by applying the following premises:

OKTA is the point of truth when it comes to user management.

Change the least possible from existing authentication and authorization flows.

It doesn’t save passwords, but still facilitates the login and user creation experience.

Thinking about those topics I put together an initial sketch that we can evolve according to the discussions, following the principle of blocks and fittings, modularizing the user.

Roles

Solutions Architect, Back-End, Front-End, Dev Ops

Responsibilities

Understanding of the applications data providers such as tipalti, sage, sendgrid , okta apis and other data providers;

Application viability study in serverless context given business requirements;

Creating Frontend and Backend architectures diagram;

Creating Frontend and SSO integration, session, auth module with okta;

Building Various frontend components like , auth, session, events, authors, checkout components;

Building Endpoints like /payment , /auth, /venues, /products, /orders;

Debugging and resolving application issues;

Writing integration tests using Jest;

Optimizing API and UI applications performance;

Identity Providers

First, we will get the initial information from the identity providers, collecting data like (name, profile, personal data, and photo), then we will use Next-Auth as we use nowadays, but in a complete way, we will configure the following providers: Google, OKTA and Facebook in it with direct communication, so Next-Auth can manage this communication and abstract the complexity of this layer by itself.

Validation Layers

Existing User in the Application Database

It will validate if the user that authenticated exists in our database. If it exists it will go to the second layer of validation (next topic), otherwise, this user will be directed to the SignUp screen (User Registration) so it will create all users in our database and also create them in OKTA via API’s using the client credentials format.

Existing Users in OKTA

It will validate the user that exists in OKTA, if it exists we will go to the third layer of validation (next topic), otherwise, the user will be created in OKTA via APIs, ensuring that OKTA and the database keep the same information.

User Linkage

It will validate the user that already exists in OKTA and in the application database, ensuring it is linked to the provider that provided us with more information, by answering the following questions:

Can we understand from which provider we get user information?

Can we identify this provider in OKTA?

Are the Providers correctly replicated in the two databases? OKTA and Mongo ?

Activation Flow Okta for New Users

When a user is created on okta, okta will send an account activation email to the new user with the template that was created in the okta console, after activation the user will be redirected to the sign in screen.

Audit Session

Finally, it will generate a new Audit session of login type in the application database with control and logging purposes. During /logout we will simply generate a new Audit session of logout type again, reminding that each action will generate an audit session that will initially have the following types: login, logout, signup, modify.

Application link:

AdmitONE Original

Create your own event listings with AdmitONE Original, the original ticket.

https://original.admitone.com/

Alexsandro Carvalho de Freitas Full Stack Engineer