Microservice Single Sign-On

Question

I am trying to create a project with a green field that will have several services (data service) and web applications (serving HTML). I read about microservices and they look good.

The problem that I still run into is how to implement SSO. I want the user to authenticate once and have access to all the various services and applications.

I can think of several approaches:

• Add service and identity application. Any service that protected resources will contact the identity service to verify that the credentials that it has are valid. If they will not be redirected to the user for authentication.

• Use a web standard such as OpenID, and each service processes its own identifiers. This means that the user will have to independently authorize each service / application, but after that he will be SSO.

I will be glad to hear other ideas. If a particular PaaS (such as Heroku) has a patented solution that would also be acceptable.

Answer 1

When implementing the microservice architecture at my previous work, we decided that the best approach was consistent with No. 1, adding an identification service and allowing access to it through it. In our case, this was done with tokens. If the request came with an authorization token, we could check this token using the authentication service, if this was the first call in a user session with the service. After the token was confirmed, it was saved in the session, so subsequent calls in the user session did not have to make an additional call. You can also create a scheduled task if tokens are to be updated in this session.

In this situation, we authenticated with the OAuth 2.0 endpoint, and the token was added to the HTTP header for calls to our domain. All services were redirected from this domain so that we can get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial authorization of OAuth 2.0 will reflect the application services that the user will provide for their account.

In addition to this approach, it was found that the authentication service will provide a proxy client library that will be added to the HTTP request filter chain and will handle the authorization process for this service. The service will be configured to use the proxy client library from the identity service. Since we used Dropwizard, this proxy server would become the Dropwizard module, loading the filter into the running service process. This allowed the identity service to be updated, which also had a free client-side update that would be easily consumed by dependent services until the interface changed significantly.

Our deployment architecture has been distributed through AWS Virtual Private Cloud (VPC) and our own company data centers. OAuth 2.0 authentication was located in the company's data center, and all of our applications were deployed to AWS VPC.

I hope that the approach we have taken is useful for your decision. Let me know if you have any other questions.

Answer 2

Chris Sterling explained the standard authentication practice above, and that makes sense. I just want to reflect here for some practical reasons.

We have implemented authentication services and several other microservices that rely on the auth server to authorize resources. At some point, we encountered performance problems due to too many trips to the authentication server, we also had scalability problems for the auth server as the number of microservices increased. We changed the architecture a bit to avoid too many round trips.

The Auth server will be connected only once with the credentials, and it will generate a token based on the private key. The corresponding public key will be installed on each client (microservice server), which can verify the authentication key without accessing the auth server. The key contains the generated time, as well as the client utility installed in the microservice. Despite the fact that this was not a standard implementation, we deal very well with this model, especially when all microservices are inside the house.