One of the possible approaches for microservice security might be this: we mimic the same behavior as that of the auth layer in a monolith. This could be depicted as follows:
In this approach, we distributed the auth layer and provided it to all the microservices. Since each one is a different application, it will need its own auth mechanism. This inherently means that the user credential store is also different for every microservice. This raises so many questions, such as how do we keep the auth in sync across all services? How can we validate inter-service communication, or do we skip it? We do not have satisfactory answers to these questions. Hence, this approach does not make sense and just increases complexity. With this approach, we cannot even be sure whether it will work in the real world.
There is one more factor we need to take into account for modern applications. In the microservice world, we need to support native mobile apps and other non-standard form factor devices as well as IoT applications. With the significant proliferation of native mobile applications, the microservice architecture also needs to support secure communication between those clients and microservices. This is different from the traditional web browser-based user interface. On mobile platforms, a web browser is not part of any native mobile app. This means cookie-based or session-based authentication is not possible. So microservices need to support this kind of interoperability between client applications. This was never a concern for .NET monolithic applications.
In the case of traditional authentication, the browser is responsible for sending the cookie upon each request. But we're not using the browser for a native mobile app. In fact, we're neither using ASPX pages, nor the form's authentication module. For an iOS client or Android, it's something different altogether. What's more, we are also trying to restrict unauthorized access to our API. In the preceding example, we'd be securing the client, be it an MVC app or a Windows phone app, and not the microservice. Moreover, all these mobile client devices are not part of the trust subsystem. For every request, we cannot trust that the mobile user is indeed the owner; the communication channel is not secured either. So any request coming from them cannot be trusted at all.
But apart from these problems, there's another more conceptual problem we have. Why should the application be responsible for authenticating users and authorization? Shouldn't this be separated out?
One more solution to this is using the SAML protocol, but again, this is based on SOAP and XML, so not really a good fit for microservices. The complexity of the implementation of SAML is also high.
Therefore, it is evident from the preceding discussion that we need a token-based solution. The solution for microservices' auth comes in the form of OpenID Connect and OAuth 2.0. OpenID Connect is the standard for authentication and OAuth 2.0 is the specification for the authorization. However, this authorization is delegated by nature.
We will see this in detail in further sections. But before that, let's take a detour and look at JSON Web Tokens and see why they are significant with respect to microservice security.