Is My Application's Authentication and Authorization Secure and Scalable?

Nowadays, most application requires authentication and authorization due to increased threat levels, and not only do they need to be secured, but also scalable due to increased traffic volume. It's not that the application doesn't have authentication and authorization in place, but the point is, does it provide security, scalability, and more features around this area? Authentication and authorization are a domain in themselves, and most developers/architects start by using a homegrown mechanism, which is not only less secure most of the time because of a lack of domain expertise, but also lots of time spent in non-core activity, and because of that, the product road-map gets a hit, and value addition in the product becomes slow.  

This blog will talk in detail about the common mistakes made in this area and how we can avoid or overcome them if we are already stuck.

Evolution of the Application

When a new business idea comes to create a new product/service, full focus is on faster value addition and reaching the market. Non-core requirement also comes in basic form, like an application that requires user authentication by simply providing the username and password. Over the period of time, based on feedback from the market, things get added slowly around authentication and authorization, and once the product/service becomes mature, then you realize that adding more and more around authentication and authorization becomes not only complex but time taking as well like multi-factor authentication, password policies, single sign on, external idp support, compliance requirement. 

Apart from that, sometimes there are different related products in the business unit/organisation, and due to teamwork in silos, the authentication and authorization mechanism behaves differently, and when a customer uses multiple products in the solution, it gives a bad impression, as doing the same thing in a different way in two different applications from the same business unit/organization. 

Last, these days monolithic applications are being transformed into microservices, and stateless authentication and authorization become the need of the hour from a scalability perspective, and it also enables developers/architects to have a dedicated service for identity and access management.  

What Are the Challenges?

Key challenges when authentication and authorization are reinvented are:

• Complexity: As mentioned before, authentication and authorization is a domain itself and over the period of time it becomes complex to maintain because it never gets dedicated attention from the stakeholders and primary focus is on business value addition in the product, because of this, decisions are taken from time perspective not long run value perspective which leads to rigid workflows and less flexibility in the system.
• Difficult to implement: Since it's not a primary domain, it takes time to implement a feature requested by the customer or market needs.
• Lack of features: These days, ISVs are concerned about security, and they expect common features around authentication and authorization to be in place, which doesn't happen if homegrown, like single sign-on, OAuth/OIDC support, etc.
• Compliance: There are various compliance requirements, and meeting many of them is time-consuming, such as GDPR or other security-related compliance. 
• Scalability issues: Since authentication and authorization are part of the application/service, and as per microservices guidelines, each domain should have a different microservice for better scalability. 
• Roadmap acceleration: There is a hit on business value addition in the product roadmap, as most of the time is spent on non-core activities.

What Should Be the Approach?

If you are building a new application/service, then try to use an externalized authentication and authorization mechanism rather than inside the application/service. Also, don't re-invent it; rather, use either open source identity and access management solutions like Keycloak or paid offerings. There will be an initial investment, but it would be only around integrating it, and it would pay off as you can leverage many features/flexibility provided out of the box, and much better security as well.  

Choosing the Right Solution

I think one of the key decisions to be taken is whether to go for an open source or a paid offering.  It would depend on many factors like use cases requirements, budget approval, etc., but you need to consider the following things:

• Paid offering would provide better support and a better chance of influencing their roadmap.
• Open source won't require investment, but influencing the roadmap won't be easy unless you actively contribute.

Integration Guidance

When you integrate an external authentication and authorization system for JWT token verification, there are two high-level approaches:

1. Centralized architecture: In this case, authentication and authorization verification activity happens at the gateway level, and after that, the request is not authenticated at the individual microservice level.
2. Distributed architecture: In this case, authentication and authorization happen at the microservice level, basically as a sidecar container, i.e., outside the application but inside the same pod.
3. Hybrid architecture: You may go for a hybrid mechanism where a certain part is verified at the gateway level and a certain part is verified at the microservice level. 

Tips

1. Don't keep authentication and authorization-related work inside the application. You may use Kong at the gateway level for a centralized architecture and the OAuth2 proxy as a sidecar in case of a distributed architecture.
2. Don't mix access to a resource with access to an instance of a resource. Access to the resource is part of authorisation, and access to an instance of the resource should be part of the application.