July 24, 2020

User authentication should be delegated

User authentication should be delegated

Authentication in web and mobile apps is complex and will never be simple. Because verifying a remote user algorithms. Although it's complex, you can't avoid it. But there is a way to delegate authenticating your users to 3rd party. Let's see if it is worth it!

It is safer than any in-house built solution

A chance that in-house built authentication solution will work better than SAAS is extremely low. Even a ready to go open source tool hosted on your side will not be that good. In no way it can be compared to a paid plan of a company that have been selling security solutions for years. There are just too many variables and conditions to keep in mind. If you still decide to build your own authentication process than it is not going to be cheap. In the end of the day the development and maintenance cost will outweigh delegating authentication to 3rd party.

Along with being more expensive, an in-house solution will not be safer. Because hiring top talents in security and encryption will definitely be out of budget of any project. Apparently there is no reason in spending all the money just on the user authentication mechanisms. Moreover, there is rule of thumb that is true not just for authentication. It requires delegating everything possible to 3rd parties, and spending most of the team’s efforts on product’s specific business logic. Following this rule allows delivering robust MVP quick and with a decent quality.

Who owns users data in this case?

This is quite an important question. Normally a 3rd party authentication service would require the identification and role information about your users. Most of the services provide a DB for the purpose, but also allow connecting your own DB for storing users authentication data. So, you have a choice — either go a simple route and just use a ready to go solution, or spend some time, set up a DB on your side and own the whole data.

Authentication flow on example of Auth0, https://auth0.com/docs/architecture-scenarios/web-app-sso/part-1
Authentication flow on example of Auth0, https://auth0.com/docs/architecture-scenarios/web-app-sso/part-1

If you are paranoid enough (in a the best possible meaning of this word) you would prefer the second route. Because data is a modern gold, it’s better to keep it under a lock. But if the rules in your company are not that strict you can save some time by leaving the data in the DB provided by 3rd party authentication service. What you will share with them is a very basic information that is required for authenticating a user, like email or role. Your users profile data will stay in your DB, referencing 3rd party users data through DB field. So, that after authenticating you can tie the user with his profile data in your DB.

How to start

Integration guide is obviously out of the scope of this article. But the links below will give a very good insight into the features and services offered by companies that sell authentication and security solutions.

If you finally decided to delegate authentication to 3rd party, then I would advice reading carefully first. Spend some time to find what really fits your needs and brings a smooth experience to your users.

Firebase Authentication

https://firebase.google.com/docs/auth

Firebase Authentication is one of the most popular solution among developers. Although it provides a very basic set of features and tightly coupled with other Firebase features.

Auth0

https://auth0.com

Auth0 delivers a full users management and authentication solution. It is highly customizable and provides a comprehensive API.

Okta

https://www.okta.com

Okta can be described as a password manager. Unlike Auth0, it does not have any user management features.

Artem Rudenko
Artem Rudenko
Software engineer, founder of ottofeller.com

Let's build a thing together!