Authentication is one of the main elements of a cloud application, as it provides the ability to control access to your application. There are many out-of-the-box solutions available, and it's only natural to consider using one of them rather than reinventing the wheel.
Need to pick an authentication solution and don't know where to start? This write-up will guide you in choosing an authentication solution that will suit your needs. It will address the important things to pay attention to, such as feature set, monitoring, compliance, and pricing model. It will also walk you through the different stages of choosing a solution, from the vendor's survey to the proof of concept (POC). Let’s get started...
You can choose between in-house and out-of-the-box solutions when working on a project. While an in-house solution gives you complete control over functionality and security, its development can take considerable time and resources.
The alternative is choosing an out-of-the-box solution. With this alternative, you have a solution that you know already works well. So, here you have two options:
We will focus on an out-of-the-box licensed service, with this solution you get a set of features that are built-in:
As you can see, out-of-the-box solutions have many advantages and should be considered when designing your application.
There are a few stages you must go through when choosing a solution that meets the needs of your project:
You should start by searching for optional solutions that pass some basic criteria. Then contact the relevant vendor(s) that you found suitable, and get more information to see if the solution meets the needs of your project.
Once you have the relevant information, you can decide on a solution. Of course, you'll want to validate that the solution works for you at this stage and run a POC. Note that you might want to test more than one solution in parallel.
If at any time during the process you find that the out-of-the-box solutions don't meet your specific needs, you can always go back to the option of an in-house solution. If the POC goes well, you then arrive at the final stage – the actual procurement of the solution.
Now that we have gone through the different stages, let's start from the beginning and look more closely at each one.
One of the main decisions you'll have to make is which vendor to go with. When searching for possible vendors, making a list of requirements is helpful. Some basic criteria that you should take into consideration are:
Once you round up a list of vendors based on these criteria, you should request more information to help narrow down this list. This leads us to the next stage of contacting the vendors.
Set up a meeting with the relevant vendor(s). This stage may require multiple sessions, in which you’ll get an opportunity to see a live demo of the solution, as well as the option to verify that the solution covers all the aspects that are important to you.
Some technical aspects that you might want to address include the following:
Another thing that is important to pay attention to is the pricing model. Let's see why…
As a developer, you may think that cost is not your concern and that you are only responsible for the technical part of things. But the cost may depend on technical factors that only you understand. For example, the cost can depend on the number of users or on the required feature set - as some features might come with an additional cost or are charged according to usage.
You will want to be aware of the general cost, as this can be a deal breaker if the cost is more than what your company is willing to pay. Knowing this at an earlier stage of the project is better before you invest too much effort.
As you progress, you might already be able to narrow down the list of vendors you started with. Once you have enough confidence in one or two solutions, you want to validate them by running a POC.
The purpose of a POC is to verify that the solution works as you expect. In the POC, you can test specific scenarios relevant to your project and raise more questions. At this stage, you should have a technical contact person from the vendor who can assist you with any issues or questions. It's in the vendor's best interest to make this phase successful. Once the purchase is completed, you won't have this contact and will be directed to the support team.
There may be some limitations to the solution that you can't overcome. So you’ll need to determine if such limitations are things that you can live with.
Another aspect you get to validate in the POC is the integration with the rest of your application. You want the integration to be simple, and the solution to be as decoupled as possible from your application. This will make it easier to switch solutions in case you need to do so in the future. For example, switching to a different solution is simpler when using a standard authentication protocol such as OpenID Connect.
When you plan the POC, be sure to focus on the aspects that will give you confidence in the solution. This is important, as you don't want to invest too much time if the solution ends up not being a good fit for you.
The result of the POC can be in the form of a small demo application where you can demonstrate the different flows. It helps to list out the flows and scenarios you want to verify and demonstrate.
At the end of the POC, you will be able to demonstrate the main flows, such as:
Note that in the case of multi-tenancy, you should demo the flows in the context of a tenant.
With the demo in hand, you will be able to demonstrate the value of the solution to the stakeholders at your company. The process of choosing and validating a third-party solution is just the starting point of your project.
However, understanding the procedure and its different stages will provide you with confidence going into the process and will reduce the risk of making critical mistakes along the way.
I hope you enjoy the quest to find the best authentication solution for you!