OAuth2 authorization patterns and microservices
One of the topics that have led to the most contention on the projects I have been in when doing microservice architecture is the use of OAuth2 for authorization.
The challenges with OAuth2 is well known and has been described very colourfully by one of OAuth’s ex-authors, Eran Hammer, in his blog post, “OAuth 2.0 and the Road to Hell”.
To sum it up. Eran Hammer says it best:
To be clear, OAuth 2.0 at the hand of a developer with a deep understanding of web security will likely result in a secure implementation. However, at the hands of most developers — as has been the experience from the past two years — 2.0 is likely to produce insecure implementations.
And that is my experience as well. What has really baffled me though is the lack of knowledge and experience that even senior developers and architects have on the subject. Even books that I have read concerning microservice architecture have examples where OAuth2 is used in a way that, at best, can be described as creative writing. If you have read “Microservice Patterns” by “Chris Richardson” then this blog post is necessary for you just to clear up any misunderstandings you might have around the use of OAuth2 in microservice architecture. Take the following drawing which is based on Fig. 10.4 in Chris Richardson’s book.
Firstly, there is nothing wrong, technically, with doing something like this. It’s fully possible to do it. The question is, should you do it?
The example that Chris Richardson is using involves using what is called a “Password grant type”. The concept is that the user gives his username and password to a client application that uses his/her credentials to obtain a so-called access token. The access token can be used by the client application to gain access to a server on behalf of the user. The first issue with this grant type is that it involves the client asking the user for his/her password which is only secure as long as the client application exists in the same security zone as the Authorization server and is what we call a “confidential client”. In technical terms, that means that you need the client application to be a backend client-server application that makes use of mTLS between the client application and the API Gateway. Without those security mechanisms this, OAuth2 pattern, isn’t secure from an information security perspective. The second issue is that it is conceptually wrong. The “Password grant type” was never meant to be used like this. When the “Password grant type” is done correctly, the client will make a direct request to the Authorization server to obtain an access token, then make a second request, with the access token, to the API Gateway. The API Gateway will, as a proxy, forward the request with the access token to the microservice. Why is that? Well, it’s to make sure that you authorize the client application’s use of the resource server on behalf of the user. What is happening in the example above is that you authorize the API Gateway for using the microservice. That just doesn’t make any sense. Read my post on «The separation of concerns between API Gateway and microservice» to understand why. From a security point of you, you might as well use Basic access authentication and use network security policies for service-to-service communication. Most Paas and Caas providers have very simple ways of configuring this.
So if you can’t use the “Password grant type”, what can you use and when?
There are two grant types that you can have a look at Authorization code grant and Client credentials grant. Which one you use depends on the context and the requirements of your customer.
Use Authorization code grant if you are providing an API to a client application given that the customer has a single sign-on solution he wants to use. If you are dealing with multiple organizations, make sure they all use the same type of identity provider. Doing an OAuth2 integration were your customers use different types of identity providers can quickly turn out to become a project in itself.
Use Client credentials grant if you are doing service to service communication or if you are dealing with multiple organizations and reaching a consensus among them, in regards to agreeing on a common solution for providing identity and authorization, is far fetched considering the time and resources that are available to you. You can always migrate from a “Client credentials grant” to an “Authorization code grant” later on so my advice is to start setting up a “Client credentials grant” first. It has some consequences though. F.ex the resource server will be completely unaware that the client application has something called a user. The “Client credentials grant” only care about client applications and don’t care what rights the user has given to the client application. This means that the resource server has to trust that the client application has been given proper consent for accessing the resources on the resource server. Still, since “Authorization code grant” alone won’t solve all challenges related to information security by itself, that is just fine.
Answering how you can use OAuth2 in a way that is secure from an information security perspective, will require a separate article or perhaps a series of articles. Perhaps I will come back to that in my next post.
