What Oauth2 grant type to use in a distributed application without any third party client?

Question

After reading for the last two days about Oauth2 protocol I still need some help to figure out what's the best grant to use for our system where the Authorization Service is deployed by us.

The app uses Spring Cloud, Spring Boot and Spring Security. It has a service discovery that uses Eureka and all users' requests go through an API gateway to reach the different microservices in an internal network. All these microservices, included the gateway, use the Zuul proxy. The Authorization Service will be another microservice storing the users in its own database. There is a frontend that at the moment is deployed in the gateway and is developed in Angular 4. There isn't any external apps that make requests to our system and there will be a bunch of users with a small set of possible roles that will make use of it and that will have to log in using a username and password.

In this situation, should we go for the Authentication Code grant or the Password grant would be ok? Or maybe not Oauth2 at all? All the examples I've seen and read about that use the Authentication Code grant require the user to allow the client to get access to the resource after log in. In our case, the client will be the gateway so the user shouldn't have to grant it anything. The Password grant seems to remove this situation as the user's credentials serve to tell the Authorization Service to provide a token. Am I missing something?

Apart from that, examples of Authorization Services include Facebook or Google. When using these, once the user grants the client application access to the resource after log in, subsequent requests don't show this screen and they only need to log in with their credentials. Where is this access granted information stored? How does Facebook know that, once the user has granted access to a resource to an application, next time he logs in he doesn't need to do it again?

Answer 1

In my understanding one of the basic purposes of the password grant is to provide a seamless migration path to OAuth2 for applications which store and collect user names and passwords. And there are plenty of those.

Also as written in this nice article:

Since this obviously requires the application to collect the user's password, it must only be used by apps created by the service itself. For example, the native Twitter app could use this grant type to log in on mobile or desktop apps.

In your case using OAuth2 and the password grant will still make some sense to me. That is mostly because there is lots of ready to use OAuth2 infrastructure (I mean the Spring OAuth2 here) in your tech stack. This infrastructure fits seamlessly in a microservice architecture and this will be the easiest and fastest way to wire all things together. But ideally web apps should use the Authentication Code grant and you should redirect the users to a special place where they authenticate (e.g. the Zuul gateway may redirect them to a page delivered by the AS). This is a bit more elaborate though and you may go for the password grant especially if you do not plan to connect other apps.

As for your second question - FB, Google, LinkedIn - they remember the authorized apps. For example in Facebook - navigate to Settings - Apps and see which apps are authorized to access your data:

In LinkedIn - navigate to Account - Parnters and Third parties - Permitted Services. E.g. this setup gives access to user data to HackerRank:

If as a user you delete these apps you will be asked to authorize them once again.