How to Securely Manage User Identification

Obviously, in the era of cloud computing, a multitude of solutions are offered by major cloud providers and even by companies that specialize in this field. We are therefore talking about identity provider services in the form of “Software as a Service” (or SaaS).

The principle is that in a few clicks or lines of script, we can have at our disposal a complete system that allows for the management and identification of users for a web or mobile application. These services also offer a large number of advanced features and the possibility to interconnect with existing user systems—all at no cost for tens of thousands of users.

Guillaume Dussault, Solutions Architect, provides an overview of the different features offered with these solutions, as well as a few comparisons and the main challenges encountered when integrating these services into our applications.

Summary:

1. Understanding the advantages of cloud services
2. The offerings of paid cloud services
3. Which identity provider to choose?
4. The integration challenges to be overcome

Historically, applications were developed by directly incorporating user and identity management features. This had several disadvantages:

• Impossible to reuse user management data and features for other systems;
• Too much responsibility for the system;
• Risks of impact on the identification system with each modification of the system’s core features, and vice versa.

But the biggest risk concerns security: As a developer or architect, I never want to touch sensitive information such as user names and passwords. The principle is simple: We can’t expose data that we don’t handle. It is therefore the best way to mitigate risk. Below, I illustrate a summary diagram of identification in this context.

The strategy commonly employed by cloud services is to delegate the responsibility for these features to a third-party system with the aim of not handling, transmitting, or storing this sensitive data. Tokens provided by the identity provider are therefore used in the user identification stage. In addition, the managed services of identity providers offer the baseline level of compliance required for SOC, PCI, HIPAA, and others. These days, AWS Cognito and Azure AD B2C are the two most popular major cloud providers.

They also offer a large number of features, such as:

• Use of the popular OAuth2 protocol;
• Password resetting;
• Multi-factor authentication (MFA or authentication via email, text, etc.);
• Support for authentication via a third party, such as Google, Facebook, Twitter, and Microsoft;
• Use of a customizable web user interface.

The best part of all this is that the cost of the service at AWS and Azure is free for use by fewer than 50,000 active users per month!

The following diagram shows the authentication flow without the application knowing the user’s sensitive information by communicating the user’s token instead.

Several companies also offer identity provider services, such as Okta and Auth0 (which also belongs to Okta). However, these services are considerably more expensive. Taking the least expensive of the two, Auth0, it will be necessary to pay approximately $0.03 per user. This would represent a monthly amount of $300 for 10,000 users.

The main differences relate to the user interface of the configuration console, which is more polished and user-friendly, as well as the API, which is a little richer and presents some other more marginal features.

Within our projects, we have observed that the features offered by the free services are more than sufficient to meet the needs of our clients.

At a high level, we can see that the offerings for these services is relatively similar. On the other hand, there are certainly use cases where integrating the service of a particular provider will make more sense in the solution - especially when it comes to interacting with other cloud services.

In the case of Azure, if you already use Azure Monitor for the observability and alerts of your applications, it would be totally logical to opt for Azure AD B2C to aggregate the events and possibly create alerts in case of threats or suspicious interactions. For systems operationalization, it’s good to have a limited source of data for your systems, so aggregating them in Azure Monitor would be a good option.

Along the same lines, if your infrastructure is on AWS, AWS Cognito easily integrates with the other AWS services. For example, you can control access to API Gateway routes for AWS Cognito users.

In any event, each of these services uses the standard OAuth2 protocol, which makes it possible to integrate one cloud provider with the other. For example, it is therefore possible to use Auth0 for its advanced features, but also to unite a user pool on AWS Cognito and thereby get the best of both worlds (plus the Auth0 fees, of course).

The most common challenge that arises in the integration of an identity provider isn’t a technical challenge, but rather a debate between the security aspect and the user experience. For example, asking the user to identify themselves to the application too often will create an irritant for the user.

The other challenge is to successfully present the login or authentication interface to the user. The difference between the following two scenarios is particularly obvious in the creation of a mobile application.

The first scenario is to offer user authentication that is fully integrated into the mobile application without leaving it. This means that the application must briefly handle the user name and password in order to send it to the identity provider. This could involve a security flaw. However, you get a perfectly integrated experience, the possibility to use the device’s biometrics features, and the assurance that password management applications will be supported.

The second possible scenario is to display a web page within the mobile application to allow the user to log in. This page is directly hosted by the identity provider, so the user’s login information isn’t handled. However, the flow of the experience is less smooth and might seem less integrated to the user. It’s possible to mask everything in order to appear more integrated in the application. You also lose the possibility to use the device’s biometrics. Finally, the development cost for this option is lower.

There is therefore no clear answer. As with many dilemmas in custom solution development, it will depend on the context of the project, the objectives, and the resulting restrictions.

Regardless of the solution that you choose for user and identity management, the important thing is to keep the resulting features out of the other business systems and applications in order to separate the responsibility of the systems. It will therefore be possible for you to reuse the solution to integrate it into your future applications.

It is also a safe bet that the information contained in the identity provider service is the most sensitive information that your systems will deal with, so try to minimize the handling of this information within your applications and opt for the use of identity tokens as much as possible. Implementing a dedicated identity provider service will therefore be beneficial from a solution architecture and security perspective.