10

We're planning a new architecture which will utlize a backend of many different microservices that will need to talk with each other as well as field requests from systems not part of the service. In the latter part I'm not talking about external customers, I'm just talking about systems inside our network, but that aren't part of this microservice architecture.

What is the best way to handle authentication/authorization for those services talking with each other? I typically see Oauth as the solution for Microservices, but that tends to be when talking about external customers utilizing the service. Does the same go for microservices talking to each other?

Improve this question
2
  • 1
    Can you update your question with information about the security goals you have for said microservices? What consumes these microservices (browsers, legacy apps you can't change, legacy apps you can change, etc)?
    – Jeff Stice-Hall
    Jan 14, 2016 at 0:26
  • 2
    The specific question that should be addressed is on whose behalf the microservices are communicating with one another. The answer is usually either of a) the originally authorized user whose request initiated the flurry of microservice communication, and whose identity and, potentially, authorized actions has to be conveyed in service calls, or b) the microservices themselves, which are configured with some credential that has to be verified by callees.
    – Jonah Benton
    Aug 8, 2016 at 2:55

2 Answers 2

Reset to default
4

OAuth 2 client credentials grant is designed for communications between services. Authentication for client credentials grant typically involves passing a shared secret, instead of a login/password. The shared secret is used to meet the RFC requirement of a "confidential client" for client credentials grant.

If you don't already have an authentication server in mind, I suggest taking a look at Keycloak, at least for a proof of concept - it's an open source offering from RedHat. It utilizes Open ID Connect (OIDC), which is an extension of OAuth 2 (adds an ID layer). Keycloak's server admin documentation on service accounts for details.

Improve this answer
0

I have been working on a similar case. I implemented OAuth2 following RFC-6749

As I wanted to have an Authorization Microservice, this one would only handle Auth-related operation and works for outside and inside the network.

The APIs in this service are generic enough to handle all needed for OAuth2. I recomend you to follow the flow in the section "1.2. Protocol Flow" for the RFC-6749 and that should help you to design your services in such way that responsibilities are unique for each service, which is what you really want to achieve when working with micro-services.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .