How to architecture Microservice & OpenID connect?

3
votes

We have three microservices: microA, microB & microC.

  • microA & microB are powering product 1.
  • microA & microC are powering product 2.

Obviously, we would need a security layer, in our case implementing an "OpenID Connect" provider fits well with the business needs. We add to the stack the OpenID provider.

The user/rights management is quite easy & natural: we associate the OpenId identifier of the user on each microservices to a subset of rights:

For example on the service microA, we store that the user OpenID XXX can do this and that. it's isolated on the microservice level. Respect the boundaries of our context. Fine.

When the user login with OpenID on product1, we grant an access token to the user + an Id token.

The situation becomes more complex when product1 expose an API that third-party use.

Now, let say that my user comes to the third-party webapp and is prompted to login & allow the third-party to get some rights on product1 API.

If I understand correctly OpenID connect, it's all about authentication over OAuth2, but how do we handle classic OAuth2 scope management then?

The best scenario I have found is:

  1. make the whole OpenID connect to have the authentication info

  2. and then make another full OAuth2 process to another Authorization server to ask the user to grant some scopes to the third party?

which means that on the third-party:

  • the user will be prompted to login on the OpenID Provider
  • then redirected and prompted to accept the scope requested

Is that correct? If yes, OAuth2 server flow is like 4 HTTP requests to the end user, so performing it twice is like executing eight requests to get the Authentication + Authorization flow done. Seems too massive.

1
microservicesopenid-connectoauth2

1 Answers

1
votes

I've already had this problem. What I would do in your case is:

  • Use this new OpenId microservice to authenticate the user and create the access-token. This access token can be a string with the permissions, user_id and the timestamp signed or you can store this info on a database.

  • Then, for every call (to product1 or product2):

    • I would force the client to send the access-token on the headers.
    • Then, when a microservice receives a call (lets say product1), I would send a signed request to the OpenId Microservice to ask if the user is allowed to perform that action.

That way, just the OpenId microservice knows how authentication works. So if in a couple of weeks you want to change how authentication works, you just have to change it on the OpenId microservice.

I dont really understand whats the problem with third-parties. They will get the token and they will be able to perform calls passingit on the Access-token header.