Quick authentication solution

Client Requirements

A client asked EPAM to build a platform from scratch in a very short term supporting several features including user management for the end-user and for administration side as well. The solution is hosted in AWS, so the decision has been made to build it around the AWS services and reusing what is available there.

This article is focusing on the authentication and the custom registration part of the solution in order to show, how it could accelerate the delivery and meet the requirements if it is approached from the right angle.

Implemented Architecture

To support this simple, but at the same time custom flow, also, to meet the other requirements including strict regulatory requirements, the following high-level architecture has been implemented:

There are several ways to build an authentication and authorization solution, there are standards like SAML, OAuth 2.0, etc. which enable the easy integration and focusing on the business functionalities instead of the technical challenges. Moreover, it is a good practice to utilize the existing services instead of trying to build any of them from scratch- which expects a different expertise and much more available time that we didn’t have. According to these principles, the following AWS components have been utilized:

• AWS Cognito: Identity and access management for the system
• User pool: to store the end-users secured data

Admin pool: to store the system administrator's account in a secured way

• API Gateway: API Product, staging and versioning support.
  • Public API: to support REST APIs without authentication/authorization, such as registration.
  • User API: The APIs are integrated with the required user pool in Cognito in order to guarantee the exclusive access for the signed-in users
  • Admin API: The APIs are integrated with the required admin pool in Cognito in order to guarantee the exclusive access for the signed-in admin
• AWS Lambda functions

• PreSign-up trigger: it is used to automatically confirm the verified state via Lambda functions which are required because Cognito supports the Registration/Verification flow in two different phases.

  Example code:

exports.handler = (event, context, callback) => {

event.response.autoConfirmUser = true;

event.response.autoVerifyEmail = true;

context.done(null, event);

};

• PreAuth trigger: it makes the calls to the external fraud detection service provider to check the user’s validity and avoid any disruption.

• PreToken generation trigger: it extends the generated Access token with the required information, such as userId, etc.

• AWS SNS: Used for SMS sending, as we cannot utilize the same feature in Cognito because of the custom user journey.

The Registration flow is implemented in the User Management Service via the following APIs:

• POST /registration: Validates the incoming data and saves the user account in the PRE_REGISTERED state or overwrites it if it exists already in the same state with the same email
• PUT /registration: Saves the data into the user table and sends an SMS code to the user to the given mobile number.
• POST /registration/smscode: Validates the SMS code provided by the user and if it is matching then changes the user status from PRE_REGISTERED to REGISTERD and at the same time it creates the account in Cognito.

In a summary, the API Gateway is integrated with the Cognito and the dedicated APIs are connected to the relevant user pool. This guarantees that the User and Admin APIs will be available only for those user accounts which belong to the relevant user pool. One service could have multiple APIs, like in the case of User Management Service, it should support the Registration (Public API/User), the Profile page of the user (User API//users/{id}/profile) or even the Users list (Admin API/users/). Each API covers its resources, so even if the User Management Service provides a resource for getting the list of the users, this will be published only in the Admin API set.