Why is it worth building an authentication system based on microservices?
The operation of the entire company depends on the Single Sign-On (SSO) system functioning efficiently: being unable to log in paralyzes other activities.
In order to ensure this reliability, it’s necessary to start thinking about SSO systems as living machines that must be regularly developed and adapted to current standards.
Today, effective and secure user authentication and authorization systems are builds based on microservices. SSO should not be a large, hard-to-manage monolith with access to Active Directory (AD). What are the benefits of using microservices in this area?
The never-ending race between hackers and security specialists is underway and it’s authentication systems that are left the most exposed to attacks. Therefore, they require constant updates and upgrades. New authentication standards keep constantly emerging as well, such as tokens, mobile apps or biometrics (fingerprint, face, gesture recognition).
The SSO system must be prepared for the need to introduce such changes and flexible enough to enable an efficient introduction of a new solution, when necessary. In the case of microservices, changing the standard of authorization methods does not entail the need to modify the entire app.
The SSO system must be efficient, as its operation affects user experience – if the system is efficient, the sign-on process is barely noticeable to the user. When it takes too long, it becomes a barrier to using the service.
SSO based on microservices is more efficient due to their size. It is believed that a microservice should be designed in such a way, so as to enable two developers to implement it within 2-3 weeks. Microservices should not only be small but also independent from each other on the interface, code and data model levels. Farms built in this way allow scaling the app freely in places that actually form bottlenecks.
From the company’s perspective, building microservice farms instead of monoliths allows it not to be dependent on individual specialists or an individual software vendor. It also allows reducing the required competencies in teams developing and managing such systems. It’s particularly important for such crucial systems as authentication systems.
A small gap in the system is all that an unauthorised person needs to take control over that system. If such a gap exists in the microservice infrastructure, only one microservice responsible for a fraction of the system’s operation will be taken over, while the remaining microservices may be unaffected. It’s a different matter with a monolith, where a hacker immediately gains access to the entire system and can do incomparably bigger damage.
The takeover of a system like the SSO would have catastrophic consequences. Being able to successfully log in to other company systems would quickly result in subsequent attacks and the takeover of a large extent of infrastructure as well as the company’s confidential data.
4. Faster problem resolution
Each of us has those moments where we are unable to sign in to the app or we must request a password reset due to an error in the authentication system. Often, the maintenance team spends long hours searching for the source of the error. An organised microservice farm allows for faster analysis and problem resolution. A fix usually affects a single function, i.e. a single microservice – there is no need to modify the entire farm. A monolith, on the other hand, is built and implemented as a whole, often with new errors.
Due to the structure of monolithic solutions, they are prone to the occurrence of the so-called butterfly effect. Just like the flutter of a butterfly’s wings can cause a tornado on the other hemisphere, changing a single parameter in a monolith can paralyze the entire network. The analysis of relationships within the extensive system that has been built for years requires long days spent studying documentation (which is often missing) and searching for employees with knowledge on the particular subject.
That is why microservices not only allows to identify the problem faster but also improve the mental comfort of team members making the decision and implementing a sign-on method change.
5. Faster introduction of changes
The service farm can be managed in real time by using Continuous Deployment tools, such as Ansible. Doing so enables us to introduce changes without waiting for the next big release. All that is necessary is to slowly move users to the new solution, or even a new microservice, on a continuous basis while constantly monitoring the situation. Systems designed in this way – in the Continuous Delivery and Deployment paradigm – make it possible to fully utilize the positive aspects of the DevOps approach. Small teams can implement and maintain their microservices simultaneously, which is not possible in the case of larger systems.
Monoliths are difficult to scale, expensive to maintain and are not conducive for the introduction of changes. In addition, it takes a long time for a new person to become acquainted with these systems, which negatively affects its problem-free maintenance and development – this is particularly true for such a key system as SSO. That is why microservices are chosen over monoliths in more and more projects. This solution is used by such companies as Amazon, Spotify and Walmart.